On 28/02/2008, Ralph Giles <giles@xiph.org> wrote:> 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?
Sure: I'm thinking about Ogg demuxers and seeking implementations.
These need to know the framerate in order to be able to interpret the
granulepos in terms of time. If they did not have to extract that from
the sequence header, but could just read it directly out of le32
fields in the bos page, there would be less room for error.
Of course it's feasible to just publish some standalone routines and
copy them around between projects, but it would simplify
implementations if that was not necessary. One example scenario is
file(1), which uses a very simple language for reading data to
describe file contents. For example, /usr/share/file/magic contains
the following for reading info from an Ogg Vorbis file:
>>>>39 ubyte 1 mono,
>>>>39 ubyte 2 stereo,
>>>>39 ubyte >2 %u channels,
>>>>40 lelong x %lu Hz
It'd be nice to be able to get similar info for an Ogg Dirac file.
> 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!
My preference would be for a bos page which the following are easily parseable:
Ogg/Dirac mapping version (versioning for this mapping, not for Dirac codec)
Framerate
Granuleshift (unless invariant in this ogg mapping)
These ideas are partly based on FLAC's Ogg mapping:
http://flac.sourceforge.net/ogg_mapping.html
An "extra headers field" (like in FLAC and Speex) could be useful for
forwards-compatibility, eg. if there could be a vorbiscomments packet
in future.
cheers,
Conrad.
>
>
> -r
>
> [1] http://wiki.xiph.org/OggDirac
>
>