[vorbis-dev] Metadata followup
Monty
xiphmont at xiph.org
Fri Apr 28 19:25:22 PDT 2000
> Can you please elaborate? Is this functionality complete?
The functionality for mixing streams made of arbitrary packets is complete
yes; this is the reason some of the libvorbis api calls begin with ogg_ as
opposed to vorbis_
A 'packet' is just a buffer of a given length (it need not even be octets, the
bit order within the octets is defined and can be generalized), but I don't
think we need to get into that ;-)
> The only
> mention to metadata in the codebase that I can find is in codec.h:
>
> /* ogg_packet is used to encapsulate the data and metadata belonging
> to a single raw Ogg/Vorbis packet *************************************/
My comments are, perhaps, written too much from the viewpoint of vorbis. A
packet is *any* chunk of data of any length. You get to define what's in 'em.
> Looking at ogg_packet its not clear to me what I need to do here. Do you
> use some other nomenclature in the codebase?
It's an unstructured bitwise blob. The bitstreams provide checksumming and
framing. you know that out == in, and beginning and end are what they were
when the packet went in. That's all.
The Ogg code for generic streaming right now is all about low level
functionality; you still need to manually feed the pages in the proper order
into the ogg_sync_XXXX abstraction...
On the decode side....
the ogg_sync_ functions track the physical bitstream and frame/seperate pages.
Pages are returned one-by-one. Seperate streams are multiplexed at this level,
and each stream has a unique 'serial number'. When pulling a page out, you get
the stream serial number of the page too. Right now it's up to you to
determine stream type based on initial headers and serial numbers; this could
be automated.
One sets un an ogg_stream 'object' for each stream type [serial number]; one
feeds pages of a stream type into the associated ogg_stream functions. These
functions break out your packets. Beyond that, the packet is raw data wholly
owned by the stream type and you can make it all up from there.
In Vorbis's case, the first packet (and the first page; page 1 contains only
this first packet so that it is small. When multiplexing things, a header
packet for each stream type has to come first) is an initial header declaring
Vorbisness and a few attributes. packet 2 is always the text comment fields,
and packet 3 is the codebooks.
Monty
--- >8 ----
List archives: http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
More information about the Vorbis-dev
mailing list