Hi each stream has one global header in nut, matroska and avi too have exactly one global header APIs like the ones from mplayer and ffmpeg and directshow AFAIK are also designed based on a single global header but a very small number of codecs are designed so that they have several global headers but no standarized way (that i know of) of converting them to a single header, the "ogg codecs" fall in this category several solutions exist: 1. store several headers at nut level 2. leave it unspecified 3. specify how these multi packet codecs should be stored be it in nut.txt or in a seperate file if we do specify how these codecs should be stored then we can either A. invent our own system (this is for all practical proposes is identical to storing them at nut level) B. borrow the system from another container format leaving it unspecified will lead to a mess of different systems used by different muxers storing them at nut level will need them to be converted to a single packet format during demuxing and to a multi packet format during nut muxing in most cases borrowing another system and using that throughout an application will lead to the least converting around -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB In the past you could go to a library and read, borrow or copy any book Today you'd get arrested for mere telling someone where the library is
On Mon, Jul 17, 2006 at 11:43:30PM +0200, Michael Niedermayer wrote:
Hi
each stream has one global header in nut, matroska and avi too have exactly one global header APIs like the ones from mplayer and ffmpeg and directshow AFAIK are also designed based on a single global header
call the above text (*)...
but a very small number of codecs are designed so that they have several global headers but no standarized way (that i know of) of converting them to a single header, the "ogg codecs" fall in this category
several solutions exist: 1. store several headers at nut level 2. leave it unspecified 3. specify how these multi packet codecs should be stored be it in nut.txt or in a seperate file
if we do specify how these codecs should be stored then we can either A. invent our own system (this is for all practical proposes is identical to storing them at nut level) B. borrow the system from another container format
leaving it unspecified will lead to a mess of different systems used by different muxers
agree, this is not an option.
storing them at nut level will need them to be converted to a single packet format during demuxing and to a multi packet format during nut muxing in most cases
due to (*), all this does it create a huge deal of complexity at the muxer level for the sake of a few broken codecs. better to identify them as broken and provide supplemental specs for how to pack the extradata. this is what was discussed before, anyway. i've said it many times before, my fundamental law of hacks and workarounds is that whenever you're integrating a broken component (in this case the strange codecs) into an otherwise clean system, you always isolate the hacks to support the broken component as close as possible to the broken component.
borrowing another system and using that throughout an application will lead to the least converting around
and it will also encourage the adoption of standards that will facilitate storing these broken codecs in any container, as opposed to just solving the problem for nut alone. haali seems willing to work with us on this, and having his support would be great for getting nut into widespread use. rich
Rich Felker wrote:
and it will also encourage the adoption of standards that will facilitate storing these broken codecs in any container, as opposed to just solving the problem for nut alone. haali seems willing to work with us on this, and having his support would be great for getting nut into widespread use.
while we are at it, I'd strip the comment packet completely from vorbis and theora and expect the application to provide a dummy one if the decode desperately wants one. lu -- Luca Barbato Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero
On Tue, Jul 18, 2006 at 03:57:37AM +0200, Luca Barbato wrote:
Rich Felker wrote:
and it will also encourage the adoption of standards that will facilitate storing these broken codecs in any container, as opposed to just solving the problem for nut alone. haali seems willing to work with us on this, and having his support would be great for getting nut into widespread use.
while we are at it, I'd strip the comment packet completely from vorbis and theora and expect the application to provide a dummy one if the decode desperately wants one.
the "standard" format is already specified, and moreover, the comment might even be used to store version information that the decoder would use to recover from buggy encoders. however, it would be nice to add a clause in the vorbis header packing spec indicating that players should ignore any metadata from the vorbis comment packet. rich
participants (3)
-
Luca Barbato -
Michael Niedermayer -
Rich Felker