[Asterisk-video] if2 bit stuffing in app_h324m

[Francesco Emmi]

Klaus Darilion wrote:
> Thanks - got it.
> 
> But I'm still not sure about the Bitreverse during if2 stuffing.
> 
> There is Bitreverse() libh324m during H324MSessionRead and 
> H324MSessionWrite. Thus, those should be transparent to h324m_gw.
>

Yes, you are right. But consider that ReverseBit here has not a "octet 
sex" meaning. It is used just because simplifies code for transcoding 
from MIME to IF2 (Better you look ETSI TS 126 101...it's very clear and 
you'll understand soon why the use of reverseBit).


> But: There is Bitreverse() when creating the h324 frames - but there is 
> no Bitreverse() when creating the ast_frame. Further, when creating the 
> ast_frame, the mode is derived from the first byte, but then the AMR 
> frame is just copied without if2 decoding (shifting everything for 4 bits).
> 

Ok. According to me you are right. Code in my machine has been patched 
also to convert from IF2 to MIME in ast_create_frame (so a Bitreverse 
also here). I had no time to discuss this feature with Sergio, and then 
to commit patch. But I think this is the correct way.
Anyway, without this, mp4save will save an mp4 with amr in IF2 format, 
and AFAIK this is not correct...


Greetings
Francesco

> thanks
> klaus
> 
> Francesco Emmi wrote:
>> Hi Klaus,
>>
>> An AMR file can be formatted in 2 different ways.
>>
>> The first is according to the MIME file storage format used e.g. by the 
>> MMS service. The specification of this format can be found in RFC 3267 
>> "Real-Time Transport Protocol(RTP) Payload Format and File Storage 
>> Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate 
>> Wideband (AMR-WB) Audio Codecs". File starts with magic number #!AMR and 
>> a typical frame in mode 7 is like this:
>>
>> 3c 08 5a 5f 8c 44 50 44 4c cd 45 2f 25 75 43 13 80 00 01 19 e0 8a 22 10 
>> 00 00 de 51 3e 87 3d 80
>>
>> First byte is used to indicate the amr mode, and 244 core frame bits are 
>> fitted into 31 octets. Last 4 bits are zero padding bits. Total amount 
>> of bytes is 32
>>
>> In a mp4 container, amr is saved in this way.
>>
>> Second formatting way is IF2 (ETSI TS 26.101) and this is used by h324m 
>> terminals.
>> This is the same frame as before in IF2:
>>
>> 07 a1 a5 1f 23 a2 20 22 33 2b 4a 4f ea 2a 8c 1c 00 00 88 79 10 45 84 00 
>>   00 b0 a7 c8 17 ce 1b
>>
>> In this frame only 4 bits are dedicated for indicating amr mode.
>> Bit stuffing is referred to the core frame bit size. So, in mode 7, core 
>> frame size is 244. When formatting in If2 you have 244 core bits + 4 
>> bits to indicate amr mode for a total of 248 bits which fit exactly in 
>> 31 octets (bit stuffing then is 0).
>> On the contrary when formatting in MIME format you have 1 octet for amr 
>> mode and 244 bits to be fitted in 31 octets for a total of 32 octets and 
>> 4 bits as zero padding
>>
>>
>>
>> Klaus Darilion wrote:
>>> Hi Sergio!
>>>
>>> I do not understand what for is the bit stuffing in 
>>> create_h324m_frame(). I thought if2 is used in h324m and also in RTP and 
>>> .mp4 files. Thus, the ast_frames are also if2 encoded - aren't they?
>>>
>> IF2 is used by h324m terminals, e.g. a mobile phone and h324mlib, but 
>> not in RTP and mp4 files that use MIME format. So when app_h324m 
>> receives an AMR frame from an mp4 file (for example coming from 
>> mp4_read) it has to convert it from MIME format to IF2 format.
>>
>> So, as the 2 formats may have different frame size (for a given mode), 
>> using array bitstuffing in create_h324m_frame() is simple a way to help 
>> correctly convert from a format to the other.
>>
>> Francesco
>>
>> ps. I hope to have answered to your doubts. If not, please let me know. 
>> I'll try to be clearer...
>>
>>
>>
>>> regards
>>> 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
> 


-- 
____________________________________________
Francesco Emmi
A-Tono
Largo Paisiello 5 - 95124 Catania
Tel.: (+39) 095 7365312
http: www.a-tono.com

Information in this email is confidential and may be privileged.
It is intended for the addresses only. If you have received it in error,
please notify the sender immediately and delete it from your system.
You should not otherwise copy it, retransmit it or use or disclose its
content to anyone.
Thank you for your co-operation.