Posted: Thu Jul 17, 2008 9:36 pm Post subject: [Asterisk-video] recent app_h324m.c commit - AMR frame size
Sergio Garcia Murillo wrote:
Quote:
I agree, thank you very much Klaus. Patch commited.
Can you please test your scenario again if it still works?
thanks
klaus
Quote:
BR
Sergio
Klaus Darilion escribió:
> Hi Sergio!
>
> I think if we define blocksize as in the previous mail, the code for
> if2->AMR conversion is wrong and should be:
>
> /*If amr+TOC needs a byte more than if2 */
> if(stuf < 4)
> {
> /* Set last byte */
> data[bs] = data[bs - 1] << 4;
> /*Increase size of frame*/
> send->datalen++;
>
> /* For each byte */
> for(j=bs-1; j>0; j--)
> data[j] = data[j] >> 4 | data[j-1] << 4;
> }
> else
> {
> /* For each byte */
> for(j=bs; j>0; j--)
> data[j] = data[j] >> 4 | data[j-1] << 4;
> }
>
>
> instead of
>
> /*If amr has a byte more than if2 */
> if(stuf < 4)
> {
> /* Set last byte */
> data[bs] = data[bs - 1] << 4;
> /*Increase size of frame*/
> send->datalen++;
> }
>
> /* For each byte */
> for(j=bs-1; j>0; j--)
> data[j] = data[j] >> 4 | data[j-1] << 4;
>
>
> regards
> klaus
>
> Klaus Darilion schrieb:
>
>> Again the same old story :-) Whe should have documented that. It is up
>> to use how we define the term "blocksize". It can be either the size of
>> the frame received from libh324m (in if2 format) or the size of the AMR
>> frame used in ast_frame (octed aligned RFC 3267 mode).
>>
>> I think the code now handles "blocksize" as the octed-aligned AMR frame
>> size. Currently the blocksize is mixed (before it was if2). What about
>> this wording:
>>
>>
>>
>>
>>
>> These are the different AMR modes (Table 1 from RFC 3267)
>>
>> Class A total speech
>> Index Mode bits bits
>> ----------------------------------------
>> 0 AMR 4.75 42 95
>> 1 AMR 5.15 49 103
>> 2 AMR 5.9 55 118
>> 3 AMR 6.7 58 134
>> 4 AMR 7.4 61 148
>> 5 AMR 7.95 75 159
>> 6 AMR 10.2 65 204
>> 7 AMR 12.2 81 244
>> 8 AMR SID 39 39
>>
>> Table 1. The number of class A bits for the AMR codec.
>>
>> Asterisk's internal AMR format:
>> ===============================
>>
>> Asterisk internally use the "octed-aligned" RTP format in ast_frame.
>> (see section 4.4 in RFC 3267)
>> This allows to have multiple AMR frames in one Asterisk frame. This
>> means, the payload of an ast_frame wich contains N AMR frames consists
>> of (se also section 4.4.5.1 of RFC 3267):
>>
>> 1. 1 byte CMR (codec mode request)
>> 2. N byte TOC (the TOC contains the AMR mode of the respecitve frame
>> and one bit which tells us if it is the last TOC or if there are
>> some more)
>> 3. blocksize(AMR frame 0) + ..... + blocksize(AMR frame N)
>>
>> We define the blocksize of an AMR frame os the number of bytes needed
>> to contain an AMR frame in the respective mode. Thus, it is the number
>> of total speech bits divided by 8 and rounded upwards.
>> E.g. an AMR frame in mode 5 has 159 bits. To store this frame we need
>> 20 bytes. Thus, the blocksize of an AMR frame in mode 5 is 20 bytes.
>>
>> H324M AMR format:
>> =================
>> In H324M, the AMR frames received from are in if2 format from libh324m.
>> (see Annex A in TS 26.101). This means that there are 4 bits for the AMR
>> mode followed by the speech bits. E.g. an AMR frame in mode 5 in if format
>> needs 159+4 => 21 bytes.
>> There is always only one AMR frame in an if2 packet.
>>
>> Extended Table 1:
>> ==================
>>
>> Class A total speech block if2 frame
>> Index Mode bits bits size size
>> -------------------------------------------------------------
>> 0 AMR 4.75 42 95 12 13
>> 1 AMR 5.15 49 103 13 14
>> 2 AMR 5.9 55 118 15 16
>> 3 AMR 6.7 58 134 17 18
>> 4 AMR 7.4 61 148 19 19
>> 5 AMR 7.95 75 159 20 21
>> 6 AMR 10.2 65 204 26 26
>> 7 AMR 12.2 81 244 31 31
>> 8 AMR SID 39 39 5 6
>>
>>
>>
>>
>>
>> regards
>> klaus
>>
>> Sergio Garcia Murillo schrieb:
>>
>>> Hi Klaus,
>>>
>>> I used an advanced method called try & error ;)
>>>
>>> The original values were taken from the mpeg4ip packetization code, the
>>> latest changes in the values from the low
>>> bit rates ones are due to an error reproducing a mp4 file created with
>>> ffmpeg at those bit rates and adjusted them til
>>> everything worked again.
>>>
>>> If everyone find any mode not working just let me know and I'll try to
>>> fix it. Or if anyone knows how to calculate the
>>> correct ones then please tell me.
>>>
>>> Best regards
>>> Sergio
>>>
>>> Klaus Darilion escribió:
>>>
>>>> Hi Sergio!
>>>>
>>>> I wonder how you calculate the block size - I can not reproduce it.
>>>>
>>>> Is it just dividing the bits of table 1 in RFC 3267 by 8 and rounding or
>>>> is there some more magic?
>>>>
>>>> thanks
>>>> klaus
>>>>
>>>> _______________________________________________
>>>> --Bandwidth and Colocation Provided by http://www.api-digital.com--
>>>>
>>>> asterisk-video mailing list
>>>> To UNSUBSCRIBE or update options visit:
>>>> http://lists.digium.com/mailman/listinfo/asterisk-video
>>>>
>>>>
>>> _______________________________________________
>>> --Bandwidth and Colocation Provided by http://www.api-digital.com--
>>>
>>> asterisk-video mailing list
>>> To UNSUBSCRIBE or update options visit:
>>> http://lists.digium.com/mailman/listinfo/asterisk-video
>>>
>> _______________________________________________
>> --Bandwidth and Colocation Provided by http://www.api-digital.com--
>>
>> asterisk-video mailing list
>> To UNSUBSCRIBE or update options visit:
>> http://lists.digium.com/mailman/listinfo/asterisk-video
>>
>
> _______________________________________________
> --Bandwidth and Colocation Provided by http://www.api-digital.com--
>
> asterisk-video mailing list
> To UNSUBSCRIBE or update options visit:
> http://lists.digium.com/mailman/listinfo/asterisk-video
>
You can post new topics in this forum You can reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum