[speex-dev] API suggestions

[Jean-Marc Valin]

> It is unusual to require a different sequence of API calls
> depending on whether the signal is Mono or Stereo.
> This is especially evident in the decoder where you would
> register a callback for the SPEEX_INBAND_STEREO message.
> The need for explicitly calling the speex_en/decode_stereo()
> function in addition to speex_en/decode() is cumbersome.
> All these tasks could be done by the API automatically,
> once it knows that it is dealing with a Stereo source.

I'll need to think about that one. Stereo support is really some "extra"
information that the decoder can decide to use or ignore.

> *** Filling the "bit bucket".
> 
> An additional function similar to speex_bits_read_from()
> would come in handy. This should append the bytes passed
> into it to the bytes already in the buffer instead of
> replacing the buffer contents.
> 
> The intended use would be for streaming sources that bring
> in data in small portions (smaller than an encoded frame).
> This way the speex_bits could be used as a buffer.
> 
> Suggested name: speex_bits_append_from(). Or alternatively
> a flag passed into speex_bits_read_from() signalling whether
> to append or to replace.

If I understand what you said correctly, there is such a call:
speex_bits_read_whole_bytes, which adds a couple byte to the SpeexBits
struct while removing the ones that have already been read.

> *** Querying the codec if there's enough data for a full frame
>     decode and verifying the bitstream
> 
> It appears there is no way to tell in advance if the decoder
> has enough information in the speex_bits buffer to decode a full
> frame of audio. Sure, after a decode attempt one could see if
> speex_bits_remaining() returns a negative value, but this POST
> DECODE check would not allow to retry decoding gracefully.
> 
> A function like speex_verify_decode(st, &speex_bits) could
> perform two functions:
> - verify the syntax of the bitstream
> - verify that the input data has sufficient length for decoding
>   a frame
> - but NOT actually perform any decoding

The problem is that this is not possible. The reason is that if you cut
just before some optional extra information, you can't know if it's
there or not.

> This function would be required for progressively decoding a
> VBR bitstream that contains no side information (page sizes).
> Without it, I could not (easily) implement VBR decoding in my
> ACM codec. And storing frame sizes between frames is a waste
> of bits in a .WAV container ;)

I don't think it's a good idea to simply concatenate all the frames
together. For example, it makes it impossible to recover from corrupted
streams and seeking becomes complicated. I would suggest doing something
similar to what Ogg does. 

        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/20030606/1700c513/signature.pgp