Speex dev - Aug 2004 - auto-detection of frame boundary

I tried feeding in the 3 encoded frame in ONE BLOCK, and calling speex_decode()
3 times in a roll. Only the 1st frames came out perfectly.  For the other 2, I
got "corrupt" frame warning.

I was supposed to get 38 bytes consumed each frame (narrow-band, VBR off). I
tried speex_bits_remaining() to peek on the # of bits consumed, and got variable
(clearly wrong)#s returned.

But if I used length-prefix, and having it read in each frame separately before
calling speex_decode() on each, the frames came out OK.  So the frames were
encoded OK, and only the way I called on the decoding side had problems.

The question is: do I need to let the decoder read in each frame separately and
speex_decode() on each?    Note, for VBR, I have to transfer frame size for EACH
frame, which is not as desirable.

Thank you,

Tongbiao

<p>-----Original Message-----
From: Jean-Marc Valin [mailto:jean-marc.valin@hermes.usherb.ca] 
Sent: Monday, May 12, 2003 11:02 AM
To: speex
Cc: Tongbiao Li
Subject: Re: [speex-dev] auto-detection of frame boundary
> Hereÿs the situation: 3 frames are being transferred back to back over
> RTP.  The total payload is known (thus the TOTAL frame size).  Weÿd
> like to decode all 3. 
> 
> According to IETF RTP Profile (appendix C, of Jean-Marcÿs Speex Codec
> Manual, verison 1.0),  ´itÿs only necessary to consider the sequence
> of bits as output by the Speex encoder, and present the same sequence
> to the decoder¡, I kind of got the impression that length-prefix PER
> FRAME is not necessary, as long as speex_decode() is called 3 times.
>
> Is this true ?
That's right, if you call speex_encode 3 times, you can call
speex_decode 3 times. Note that you need to let Speex do the
concatenation of the frames. If you try to concatenate the bytes
yourself, you risk problems because sometimes the frames don't end a
byte boundary.

        Jean-Marc


-- 
Jean-Marc Valin, M.Sc.A.
LABORIUS (http://www.gel.usherb.ca/laborius)
Université de Sherbrooke, Québec, Canada

--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to
'speex-dev-request@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.

Le lun 12/05/2003 à 14:27, Tongbiao Li a écrit :
> I tried feeding in the 3 encoded frame in ONE BLOCK, and calling
speex_decode() 3 times in a roll. Only the 1st frames came out perfectly.  For
the other 2, I got "corrupt" frame warning.
> 
> I was supposed to get 38 bytes consumed each frame (narrow-band, VBR off).
I tried speex_bits_remaining() to peek on the # of bits consumed, and got
variable (clearly wrong)#s returned.
> 
> But if I used length-prefix, and having it read in each frame separately
before calling speex_decode() on each, the frames came out OK.  So the frames
were encoded OK, and only the way I called on the decoding side had problems.
> 
> The question is: do I need to let the decoder read in each frame separately
and speex_decode() on each?    Note, for VBR, I have to transfer frame size for
EACH frame, which is not as desirable.
It probably means that something's wrong with your code. It should look
like:

SpeexBits bits;
...
speex_encode(enc, frame1, &bits);
speex_encode(enc, frame2, &bits);
speex_encode(enc, frame3, &bits);

//decode

peex_decode(dec, &bits, frame1);
speex_decode(dec, &bits, frame2);
speex_decode(dec, &bits, frame3);

See speexenc.c and speexdec.c for more details (--nframes option).

        Jean-Marc


-- 
Jean-Marc Valin, M.Sc.A.
LABORIUS (http://www.gel.usherb.ca/laborius)
Université de Sherbrooke, Québec, Canada

<p>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: Ceci est une partie de message numériquement signée
Url :
http://lists.xiph.org/pipermail/speex-dev/attachments/20030512/a0de500f/signature.pgp