[Asterisk-video] if2 bit stuffing in app_h324m

[Klaus Darilion]

Hi Francesco!

Francesco Emmi wrote:
> 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).

Ok. Can you please help me to understand the bit encodings?

I think I understand the RFC 4867 format - e.g: mode 7 uses 244 bits. 
Network order with most significant byte/bit first. Thus

AMR bit 0  ->  buf[0] | (1 << 7)
AMR bit 1  ->  buf[0] | (1 << 6)
AMR bit 2  ->  buf[0] | (1 << 5)
AMR bit 3  ->  buf[0] | (1 << 4)
AMR bit 4  ->  buf[0] | (1 << 3)
AMR bit 5  ->  buf[0] | (1 << 2)
AMR bit 6  ->  buf[0] | (1 << 1)
AMR bit 7  ->  buf[0] | (1 << 0)
AMR bit 8  ->  buf[1] | (1 << 7)
AMR bit 9  ->  buf[1] | (1 << 6)
...

AMR bit 242  ->  buf[30] | (1 << 5)
AMR bit 243  ->  buf[30] | (1 << 4)

Is this correct?

Then, if this is transformed to if2 - I would think it should be following:

AMR mode bit 0  ->  buf[0] | (1 << 7)
AMR mode bit 1  ->  buf[0] | (1 << 6)
AMR mode bit 2  ->  buf[0] | (1 << 5)
AMR mode bit 3  ->  buf[0] | (1 << 4)

AMR bit 0  ->  buf[0] | (1 << 3)
AMR bit 1  ->  buf[0] | (1 << 2)
AMR bit 2  ->  buf[0] | (1 << 1)
AMR bit 3  ->  buf[0] | (1 << 0)
AMR bit 4  ->  buf[1] | (1 << 7)
AMR bit 5  ->  buf[1] | (1 << 6)
AMR bit 6  ->  buf[1] | (1 << 5)
AMR bit 7  ->  buf[1] | (1 << 4)
AMR bit 8  ->  buf[1] | (1 << 3)
AMR bit 9  ->  buf[1] | (1 << 2)
...

AMR bit 242  ->  buf[30] | (1 << 1)
AMR bit 243  ->  buf[30] | (1 << 0)


Is this correct?


>> 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.

Can you please post your version of app_h324m.c (or the corresponding 
patch) at the mailing list.

> Anyway, without this, mp4save will save an mp4 with amr in IF2 format, 
> and AFAIK this is not correct...

Yes. I've managed to save AMR in IF2 format to an mp4 file, and playing 
it back - but now I know that I'm wrong and I have to transform to 
RFC4867 format.

regards
klaus