[ogg-dev] Header packet multiplicity
Conrad Parker
conrad at metadecks.org
Wed Feb 13 16:38:29 PST 2008
On 14/02/2008, ogg.k.ogg.k at googlemail.com <ogg.k.ogg.k at googlemail.com> wrote:
> Ralph wrote:
> > Conrad, does this work for the other codecs as well? I vaguely
> > remember libvorbis putting -1 on the header packets instead of 0.
>
> AFAIK, it's 0, -1 being for partial pages, from the ogg docs. -1 (or, I
> suppose all negative values, but I'm not sure) mean unset.
yeah, -1 is a special value ... iirc all the codecs have 0 on the header pages.
However for stuff like CMML (and possibly Kate) it can make sense to
have a timestamp of 0 for the first data packet, to signify that it it
active from the very beginning of the data.
That's likely why we made sure to put a nr_headers field in skeleton,
so that it's simple to keep track of which of a streams packets are
headers. At the time though we were only really dealing with vorbis,
theora, and speex; the first two have a fixed nr of headers (3) and
the last has 2+extra_headers, where extra_headers can be read from the
bos page.
So, mod_annodex, hogg chop etc. just use the extra_headers /
nr_headers info, and don't use the granulepos value to determine what
is a header or not.
To further make it clear, skeleton puts its eos page, with a 0 length
packet, in between the last header and the first data page of the
stream.
If we wanted to make some kind of recommendation or future
specification that only headers may have granulepos 0, then we could
always implement a CMML granule of 0 as (-1 + 1), ie. previous granule
(-1) and the first as a delta of +1. That starts getting a bit
crackful though.
> Though you do say packets rather than pages, and the granulepos for
> a vorbis packet will be interpolated from the page's granulepos, so I
> assume you meant page ?
yeah the granulepos is marked on a page, but it refers directly to
that of a packet. Conceptually, each packet has a granulepos; eg. when
writing with libogg, you always place a granulepos onto each packet,
even though most of those are immediately thrown away, yay.
Conrad.
More information about the ogg-dev
mailing list