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

[Michael Niedermayer]

Hi

On Tue, Jul 18, 2006 at 01:37:53PM -0400, Rich Felker wrote:
> On Tue, Jul 18, 2006 at 10:52:37AM +0100, Måns Rullgård wrote:
> > >> I'll state my main point again.  Allowing multiple extradata blocks in
> > >> nut will allow any codec to be used with nut, *without* any need for
> > >> agreements outside the codec specs.  Apps that use some common format
> > >
> > > No it will not. All Xiph has to do is make their new
> > > latest-and-greatest container have a hierarchical filesystem of header
> > > blocks, or a relational database of header blocks, or whatever other
> > > bloated crap they can come up with, and then we cannot store that
> > > without hacks!
> > 
> > They're not doing it now, and we have no reason to believe they ever will,
> > so let's worry about that if it ever happens.
> 
> No. "Let's worry about that if it ever happens" is the philosophy of a
> bad container. 

the alternative was mov, the container which supports everything the designers
could think off, "sadly" the designers thoughts didnt became reality, and what
did become reality wasnt supported (b frames for example)
not to mention no mov demuxer or muxer supports even just half of the spec
AFIAK


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

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

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

[...]
-- 
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