[NUT-devel] codec id nonsense, please end it

[Rich Felker]

we were on the verge of finishing nut entirely when this whole
flamewar started and i'd like to see it end. while i agree with ivan's
sentiment that we do not want the huge mess of random nonsensical
fourcc's creeping into nut, i'm also quite confident that ivan's
proposal will not solve the problems he claims it will. as long as a
"new style" codec id is required (and if it's not required it's
useless and stupid like matroska's dual system) then whenever users
want to use a codec that's not in the official list they'll just copy
a random fourcc or other string to use as the codec identifier.

on the other hand, the disadvantages of making a new codec id system
are significant. most importantly, it requires every player that wants
to support nut to either switch to using the new codec id system
(nut-centric) and map all old fourcc's from other containers to the
new system, or to map all nut codec ids to fourccs. both of these
procedures require pointless large conversion tables.

while the fourcc situation historically is ugly, the proposal i've
been mostly agreeing with (i don't call it mine because iirc it was
put together from the ideas of many people) seems the best to remedy
the situation. like all legitimate standardization processes in which
the party making the standard is providing rules whose influence
extend outside their scope, our process for standardizing codec ids
should:

1. abstract common characteristics of historical implementations

2. eliminate characteristics which are vendor-specific and/or provide
   duplicate or ambiguous functionality

3. only as a last resort, fill in new definitions where steps 1 and 2
   have left any gaps.

in our case, this means looking at existing fourcc values and other
fourcc-compatible codec identifiers used in avi, quicktime, nsv, etc.
and choosing among them the ones which are sane (human-readable and
vendor-neutral). this resulted in a list like "mp4v", "mp3 ", "h264",
"mpg1", ...

the benefit of using existing fourcc's is significant because any
multi-format player can lookup a working decoder for a stream with its
existing fourcc->decoder tables rather than requiring a whole new set
of tables. while designing a new codec id system could be useful, it
is beyond the scope of a container format simply because of big-O
considerations. if each universal (any-codec) container has its own
nonsense codec id system, then the size of the tables grows as
O(num_containers*num_codecs) instead of just O(num_codecs).

i do not object at all to commenting in the nut spec that, in the
event of a new future codec id standard that's well-designed, a future
nut version may support using the new id system instead of fourcc.
however, making a new codec id system and getting all containers to
adopt it is WAAAY to ambitious of a project right now and WAAAAY
outside the scope of what nut is trying to do.

as for ivan's concern that lamers will just use crap fourccs (like
DIVX, XVID, X264, ...) instead of the correct/standardized ones, there
are lots of other things lamers can do too, and nutlint and/or the
reference demuxer should warn about or discourage their stupidity.
actually i would like to see a list of "illegal fourccs" in the
reference muxer so it knows all the classic vendor-specific/ambiguous
fourccs and rejects them as permenantly invalid. this would be a
fairly small table, just 4 bytes per fourcc.

other ideas welcome, but i really hope we can put this issue aside
asap and get on with release..

rich