[Asterisk-video] if2 bit stuffing in app_h324m

[Ramtin Amin]

that is correct
to have an idea, go have a look here: http://xa.bi/files/amrconvert
 



> Date: Mon, 30 Jul 2007 15:37:46 +0200> From: klaus.mailinglists at pernau.at> To: asterisk-video at lists.digium.com> Subject: Re: [Asterisk-video] if2 bit stuffing in app_h324m> > 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> > _______________________________________________> --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
_________________________________________________________________
Besoin d'un e-mail ? Créez gratuitement un compte Windows Live Hotmail, plus sûr, plus simple et plus complet !
http://www.windowslive.fr/hotmail/default.asp
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-video/attachments/20070730/5ba14d63/attachment-0001.htm