Ogg encapsulation

Hi everyone,

We'll soon be finalizing the spec for encapsulation of MNG files in an 
Ogg bitstream. If you're not familiar, Ogg is a stream oriented 
multimedia container that supports multiplexing of different time-linear 
data streams with error detection and seeking signposts. It's most 
famous at this point as the native format of the Vorbis audio codec.
You can read more about it on the official website [1] or in rfc 3533 [2].

This is an obvious way to add an audio soundtrack to a MNG animation, 
by multiplexing it with Vorbis audio (or another format). We also plan 
to use MNG for graphic overlays with our Theora video codec, à la DVD 
subtitles.

I'd like to solicit review and opinions, basically, about what we're 
trying to do, since I've been developing this mostly single-handedly.

The design so far is outlined in http://wiki.xiph.org/OggMNG

In particular, I've been rethinking an earlier decision about including 
the chunk length and checksum fields. These are redundant in an Ogg 
encapsulation, but libmng expects these fields to be filled in. If 
the bitstream omits them, it's not difficult to re-generate and feed 
them piecemeal to the decoder using the high-level buffer copy 
interface. However, this means the Ogg decoder must re-compute the 
chunk's checksum just so the MNG decoder can compute it again and 
compare. Both computations are unnecessary because the container does 
its own checksum and will have already reported any corruption. That's 
twice over data we shouldn't have to touch at all.

Is there any plumbing in libmng that could be exposed to let us hand in 
chunks with the header already parsed? Limitations of libmng's api 
design are a poor decision criteria for our spec, but the overhead of 
the two fields is so small it's almost an aesthetic decision. I'd like 
not to include them, but practical simplicity has weight too and I've 
argued myself to an impasse. :-)

Opinions welcome,
 -r

[1] http://xiph.org/ogg/doc/
[2] http://www.ietf.org/rfc/rfc3533.txt

--
Send the message body "help" to [email protected]