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