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

[Rich Felker]

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. Surely _something_ that does not fit the "N consecutive
packets" model will eventually happen in some codec. The question is a
matter of being clean and simple. Do we support _one_ rare and
already-ugly case for strange header data, or do we draw the line
before that and say no, headers must be in the one universal format.
(Binary data block is the minimal universal format that works for
absolutely any codec.)

> They (and others)

Which others? You have provided no examples. H.264 does not count
because they already have startcodes separating the parts.

> *do* specify multiple extradata blocks, which is something
> we can easily handle if we want to.

But we _don't_ want to. It makes things more difficult for
implementations which will always want to take the simple, sane
approach and pack everything into one binary block.

> > A codec having multiple header chunks without any in-band signalling
> > of their boundaries is a _pathology_. It is not the norm and it is not
> > something NUT should account for or that players should have to deal
> > with.
> 
> Xiph does not rule the world, and neither do we.  Pretending otherwise is a
> big mistake.
> 
> Codecs with multiple blocks of extradata are a reality.  We can either accept
> that reality, and deal with it (which is trivial), or we can all go and hide
> in your academic utopia and pretend everything is just the way we want it.

Hiding something broken is always the correct solution. It has nothing
to do with academic utopias but practical benefits. NUT is already
complex enough and having to wrap the NUT demuxer with a
header-repacker to get the headers into the sane, ALREADY STANDARDIZED
single binary block format will just make it more annoying to use!

Rich