[NUT-devel] Re: r19110 - trunk/DOCS/tech/nut.txt

[Rich Felker]

On Tue, Jul 18, 2006 at 10:54:04PM +0200, Michael Niedermayer wrote:
> > Surely _something_ that does not fit the "N consecutive
> > packets" model will eventually happen in some codec. The question is a
> 
> this depends strongly on why multiple header packet but no standarized
> "serialization" codecs exist
> do they exist because the designers where unaware of the prblems this
> would cause or did they design it that way with the intention to make
> usage of their codec difficult in containers other then their own
> if later then yes no matter what you add, such people will do something
> to make storage hard

it's my belief that as the interest in storing codecs in arbitrary
containers increases, everyone will realize that single binary block
is the natural/"portable" way of storing headers. if this happens,
then the only reason they would come up with more complicated
arrangements would be to thwart interoperability.

> now i dont know why xiph designed things like that, but i do know that
> they are _now_ aware of the issues (many people ask on their mailinglists
> about vorbis in non-ogg) and they dont specify how to turn the 3 packets
> into 1 ...

hmm. if they're "aware" of the issue now, do you think they'd be
amenable to publishing a xiph-sanctioned spec for how to store vorbis
in non-ogg containers. preferably using either the existing mkv format
or the pure concatenation which you demonstrated is possible. (these
two formats only differ by the existence of a few bytes of junk at the
beginning of the former.

> so IMHO, if a codec uses multiple packets because the designers
> wherent aware of the issues this has with most containers and APIs then
> they will probably not mind adding a few lines to their spec to specify
> how to store these headers in a one-header API/container, and thouse
> who design codecs with multiple header packets to make storeage in
> "unwanted" containers hard will always find a way to reach that goal

agree!

> so IMHO supporting multiple header packets at nut level might solve
> vorbis & theora but its usefullness with future codecs is uncertain

imnsho it creates a lot more opportunity for ambiguity about how the
headers should be stored than its worth. if we added something like
this, suddenly there would be questions about how h.264, etc. should
be stored. avoiding such ambiguities which lead to countless different
combinations that an implementation must support seems to be a very
important goal.

rich