[Asterisk-video] if2 bit stuffing in app_h324m
Klaus Darilion
klaus.mailinglists at pernau.at
Mon Jul 30 09:09:25 CDT 2007
Ramtin Amin wrote:
> that is correct
really, according to http://www.connactivity.com/~eaw/amrwork/ my if2
understanding is not correct.
regards
klaus
> 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
> et bénéficiez d'un filtre antivirus gratuit ! Windows Live Hotmail
> <http://www.windowslive.fr/hotmail/default.asp>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> --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