[NUT-devel] NUT documentation

[Rich Felker]

On Sat, Oct 28, 2006 at 02:05:10PM +0100, Måns Rullgård wrote:
> Oded Shimon <ods15 at ods15.dyndns.org> writes:
> 
> > On Sat, Oct 28, 2006 at 01:12:12PM +0100, Måns Rullgård wrote:
> >> So given a NUT file, how do you know which codec is used if there is
> >> no official list of codec IDs?
> >
> > I dunno, how do you accomplish this right now with AVI? As far as support 
> > goes, I'd say AVI is doing pretty well.. Even on set-op players...
> 
> I thought we all agreed that AVI was a mess.

Being a mess and being broken are two entirely different things. AVI
is a mess just like Wikipedia is a mess, because anyone can contribute
whatever {codecs|articles} they want. The analogy continues in that
both tend to, over time, stabilize on something less messy. On the
other hand, MKV and MPG are _BROKEN_ because you cannot use arbitrary
codecs in them (aside from the even-more-broken dshow-in-mkv idiocy or
user-defined streams in MPG that have no standard interpretation aside
from a small number of codecs like AC3).

> > Now, believe it or not, coming up with a new system against the AVI mess, 
> > makes the situation WORSE, not better, because players would have to 
> > maintain multiple lists instead of one in order to support several 
> > formats.
> 
> Players already need one list per format.  Did you ever notice that

No they don't. As there are generally(*) no conflicts between the
numbers used in different formats, a single list with multiple names
for each codec in cases where they vary is sufficient.

(*)The few broken formats that do use conflicting names, like
0x00000001 or such, generally only support a tiny number of codecs, or
else the player can just remap the few conflicting names in the
demuxer for the particular format to their standard names. One big
list plus a few tiny patch-ups for broken formats is much better than
O(n) lists!!

> mov.c has its own list?  Perhaps in an ideal world, each codec would
> have a unique identifier used across all formats.  That is not the
> world we're living in, and unless we can manage to change that, which
> seems very unlikely, we simply have to deal with what we have.
> Closing your eyes does not make the problem go away.

The only way to make that reality is to adopt the already-agreed-upon
names, not to invent some idiotic new standard!! ARRG I AM NOT GOING
TO GO THROUGH THIS FUCKING DISCUSSION AGAIN! I AM PISSED ENOUGH ABOUT
IT ALREADY!!!

> > As for the actual list to put in the spec, for all I care you can grab the 
> > list from riff.c and use that.
> 
> The fact that you don't seem to care at all about an important part of
> the spec is what worries me.

An actual list does not belong in the spec. On the other hand, here's
what we _could_ do, and maybe you would be happy:

1. AVI/MOV video/audio codec names are used, with the most
   representative, least implementation-specific one being preferred.
2. For a list of common codecs, we document a preferred name. Any
   player that supports one of these codecs MUST (to be NUT compliant)
   support it when the preferred name is used. Obviously if someone
   goes and uses a stupid name like "DIVX" for mpeg4, the player might
   or might not support it, but it must support the name in the list.

This way there is no large list to maintain, but we can guarantee
compatibility for major standardized codecs. Moreover this "MUST"
requirement will encourage file authors to use the standard name
(since they know any NUT player will play it) rather than some stupid
vendor-specific name like DIVX.

If other NUT developers are interested in this and willing to maintain
such a small list, I have no problem with the above system. But I will
have nothing to do with any proposal that calls for a full codec
registry, which reeks of NIH-syndrome!

Rich