On Sat, Oct 28, 2006 at 02:05:10PM +0100, Måns Rullgård wrote:
Oded Shimon <ods15@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