Re: Ogg encapsulation

Glenn Randers-Pehrson <[email protected]> Wed, 31 Mar 2004 22:05:07 -0500
Newsgroups gmane.comp.graphics.mng.general
Message-ID <[email protected]>
At 06:33 PM 3/31/2004 -0800, Ralph Giles wrote:
>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.

Libmng doesn't have an option to ignore the CRC but it would be a trivial
matter to make it have one.  Libpng does have such an option.

>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. :-)

Simplest (from libmng API perspective) would be to include the fields
but just fill in zeroes for the CRC, and use a modified libmng as above
that ignores the CRC.



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