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]