[Vorbis] Ogg files versus Ogg streams
Ralph Giles
giles at xiph.org
Sat Nov 5 22:58:21 PST 2005
On Sat, Nov 05, 2005 at 03:47:27PM -0800, Robert Hui wrote:
> I'm very new to Ogg, and am learning about it in an attempt to stream it
> from a CF card through a microcontroller. This particular setup requires
> me to move parts of the file from the CF card to the microcontroller
> buffer, effectively making the file like a data stream. Also, should this
> question be directed at the Tremor group instead since that is the codec
> I'm using? It seems like a generic Vorbis question, versus something
> specific to Tremor.
This is usually a better place to ask general questions.
> My question is this: As far as ov_open_callbacks(..) is concerned, is the
> *datasource parameter expecting a pointer to part of an Ogg file
> (specifically, the beginning where I assume the Ogg identifying info is
> placed). And if this is the case, can I assume that bringing the Ogg file
> in piece-meal fashion only requires a change to the way ov_read(..) will
> handle not having enough data to decode a single Ogg page (i.e. - if the
> remaining data to be decoded is >1 Ogg page)? Note that I do not need the
> ability to seek in this file, only play back the file.
The datasource parameter is treated as opaque by the vorbisfile api,
and has nothing in particular to do with the Ogg data your callbacks
return. The idea is that you pass it a private data reference which it
in turn passes to your callback functions so you can deference and look
up whatever you need to about the stream state. It is designed so you
can pass a FILE* as the datasource and use the normal C stdio functions
as the callbacks (in fact, this is how ov_open() is implemented
internally) but as long as your callbacks return the stream as expected
you can do whatever you want.
That is, your read callback should start feeding the decoder data
starting at the beginning of the Ogg stream as it's read off the CF
storage, and feed the stream in contiguous pieces after that, but
returning less than the requested number of bytes is fine; the decoder
will just keep pulling until it has enough input to generate some
output. If you don't have any of the stream available you should block
though, since returning zero bytes indicates end-of-data or a read error
depending on whether errno is set.
See http://xiph.org/vorbis/doc/vorbisfile/callbacks.html for details on
what the decoder expects.
Hope that helps,
-r
More information about the Vorbis
mailing list