[Asterisk-video] recent app_h324m.c commit - AMR frame size patches
Klaus Darilion
klaus.mailinglists at pernau.at
Thu Jul 17 17:30:41 CDT 2008
Sergio Garcia Murillo wrote:
> I agree, thank you very much Klaus. Patch commited.
Can you please test your scenario again if it still works?
thanks
klaus
>
> 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
>>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> --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
More information about the asterisk-video
mailing list