[Asterisk-video] recent app_h324m.c commit - AMR frame size patches
Sergio Garcia Murillo
sergio.garcia at fontventa.com
Thu Jul 17 14:55:24 CDT 2008
I agree, thank you very much Klaus. Patch commited.
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-video/attachments/20080717/ac07f0c8/attachment.htm
More information about the asterisk-video
mailing list