I've rehashed the model for the libogg2 convience library, seperating it
into
two libraries in the effort to allow 3rd party media frameworks to more directly
utilize the functions provided by OggFile, while still providing VorbisFile-like
convience for the most common uses of Ogg encoders/decoders.
In this new model, liboggstream provides the functionality of "codec
plugins",
inputting and outputting Ogg packets (because Ogg packets are a convient,
general form to handle granule-stamped encoded and decoded multimedia data). It
will, as per configuration, launch a seperate application when an unknown codec
is encountered (which may, in turn, contact a service at Xiph.org to find a
plugin for that codec, download it, and retry the stream).
liboggfile will provide basically the same functionality as libvorbisfile with
the addition of encoding support using liboggstream. It'll be the (de)muxer
with seeking on decode with callbacks used for both input and output, basic file
and buffer callback functions will be provided with the library of course.
This means that gStreamer, Helix, the new KDE multimedia framework, etc can use
Ogg codec plugins directly, without having to either re-implement them or wrap
them with cleverly-written callbacks, wether or not they're encoded in an
Ogg
bitstream, some 3rd party encapsulation (ie, Quicktime), or transfered over RTP.
The concept for this started with my own need to break the task down into easier
to implement chunks, and this model emerged as a favorable one from that, noting
the past call to cooperate with one media framework or another.
Comments welcome/encouraged.
--
The recognition of individual possibility,
to allow each to be what she and he can be,
rests inherently upon the availability of knowledge;
The perpetuation of ignorance is the beginning of slavery.
from "Die Gedanken Sind Frei": Free Software and the Struggle for Free
Thought
by Eben Moglen, General council of the Free Software Foundation
