[Asterisk-video] recent app_h324m.c commit - AMR frame size patches
Klaus Darilion
klaus.mailinglists at pernau.at
Fri Jul 11 06:19:56 CDT 2008
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
More information about the asterisk-video
mailing list