[Asterisk-video] recent app_h324m.c commit - AMR frame size patches

[Klaus Darilion]

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