[ogg-dev] Fwd: [Schrodinger-devel] Updating the Ogg mapping for
giles at xiph.org
Wed Feb 27 17:30:13 PST 2008
Cross-posting from schrodinger-devel. Please follow up there, since
the implementors aren't on ogg-dev.
Begin forwarded message:
From: Ralph Giles <giles at xiph.org>
Date: February 27, 2008 5:26:07 PM PST (CA)
Subject: [Schrodinger-devel] Updating the Ogg mapping for Dirac
Several years ago I did a draft mapping for encapsulating Dirac in
an Ogg stream, based on an early draft of the spec. At the FOMS
conference last month, Anuradha pointed out that it was out of date,
several of its dependencies having changed between the 0.9 and 2.1
Specifically, the KW-DIRAC stream identifier we were using was
removed from the native stream, and the reserved bits in the sequence
offset were dropped, so the granulepos shift should be 32 bits, not
30, to avoid imposing an additional restriction on Ogg embedded Dirac
I updated the draft, but didn't talk to David about it until this
week, after he had released 1.0.0 of his schroedinger implementation.
This is where it gets interesting.
I'd proposed changing the granule shift, and then just dropping the
KW-DIRAC stream identifier and using the sequence header packet as
the Ogg bos packet directly. It does what bos packets are meant to
do. The new stream idea magic is shorter (BBCD\0) but still ought to
be ok. My original intent was that concatenating all the Ogg packets
would result in a valid native Dirac stream, and this would restore
Conrad had suggested instead extending the now Ogg-specific initial
data to include the framerate (and possibly also frame size) since
these are somewhat tedious to parse out of the sequence header. It
turns out that gstreamer (the test framework everyone's been using
with schroedinger) was already implementing that. Around a year and a
half ago, it began adding the KW-DIRAC stream identifier manually,
since the encoder wasn't producing it any more, followed by the
framerate stored as a rational pair of 32 bit big endian integers,
and using *that* as the bos packet. The demuxer would then strip and
discard this before passing the remaining data to the decoder.
David and I talked about this today and we agreed gstreamer should be
changed to just use the Dirac sequence header as the Ogg bos packet.
He said we would write some stand alone routines people could use for
extracting data from the sequence header. Since an Ogg muxer already
has to be able to extract this to build a skeleton stream, I don't
see how having it stuck in the stream is worth an extra thing to get
wrong. Conrad, can you clarify your argument here?
If we do want a custom header, using a Dirac AUX packet would be
safer than prepending something, but having such a packet first is
currently invalid; the Dirac spec would have to be changed to allow
In any case, David said he'd like to get this resolved in the next 48
hours or so, before doing a 1.0.1 bugfix release. So if you have
input, now's the time!
More information about the ogg-dev