Ralph Giles
2008-Feb-27 17:30 UTC
[ogg-dev] Fwd: [Schrodinger-devel] Updating the Ogg mapping for Dirac
Cross-posting from schrodinger-devel. Please follow up there, since the implementors aren't on ogg-dev. -r Begin forwarded message: From: Ralph Giles <giles@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[1] 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 revisions. 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 video. 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 that. 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 this. 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! -r [1] http://wiki.xiph.org/OggDirac>
Seemingly Similar Threads
- Re: Updating the Ogg mapping for Dirac
- How Ogg mappings translate into the codecs parameter in Ogg media types
- [Schrodinger-devel] ogg dirac granulepos in oggz tools
- [Schrodinger-devel] ogg dirac granulepos in oggz tools
- [Schrodinger-devel] ogg dirac granulepos in oggz tools