OK, this is how it works:
The encoder calls speex_encode any number of times and then calls
speex_bits_insert_terminator before sending the bits.
The decoder then keeps calling speex_decode until it returns -1, which
means that the terminator is reached.
Jean-Marc
Le mar 01/07/2003 à 20:41, Tom Grandgent a écrit :> Ok, I figured it out. :) This seems to work:
>
> 1) Call speex_bits_read_from() once, specifying the location in
> memory of the compressed data, and the total length of that data.
>
> 2) Keep calling speex_decode() until speex_bits_remaining()
> returns 0.
>
> Then you don't have to keep track of the # of frames per packet,
> or the size of each compressed frame. It's done magically by the
> codec.
>
> I now see that in section 4.5 of SpeexManual.pdf it touches on this
> briefly, and mentions a terminator code. But, it's not quite clear
> as to how this terminator code is used... especially since it refers
> to figure 4 which doesn't seem to exist. (doc bug?)
>
> Might I humbly recommend a section of documentation elaborating on
> the use of the speex_bits*() calls ...
>
> Tom
>
>
> Tom Grandgent (tgrand@canvaslink.com) wrote:
> >
> > Hi,
> >
> > I have a question about section 3.4 of the RTP payload draft:
> >
> > > Speex codecs [11] are able to detect the the bitrate from the
> > > payload and are responsible for detecting the 20 msec boundaries
> > > between each frame.
> >
> > This suggests that you can encode some frames with Speex, pass the
> > compressed bits to the decoder, and you'll get the output -
without
> > having to do external bookkeeping for compressed frame size. (I'm
> > thinking of VBR here where compressed frame size varies constantly.)
> >
> > If this is true, how does one go about leaving this responsibility to
> > the codec? It seems like I have to pass the size of the compressed
> > frame as the last parameter of speex_bits_read_from(), then call
> > speex_decode() to decode one frame at a time. This is how the sample
> > code in the manual works, and the reference manual doesn't shed
any
> > light on this.
> >
> > So basically, if I'm given an RTP packet with several back-to-back
> > VBR-compressed Speex frames, how do I decode it?
> >
> > Thanks,
> >
> > Tom
>
> --- >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.
--
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/20030701/78a9c48f/signature-0001.pgp