[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