2006/6/20, Rich Felker <dalias@aerifal.cx>:
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.
It's not user job to create format_id, it is codec maintainer person. Users changing fourcc is part of the problem.
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.
I don't have problem with world domination. I'm sick of this mythical table nonsense. There is ALWAYS a table. It could be distributed - each codec/module/demuxer knows fourcc it can play and how to map them (ffmpeg?) It could be centralized - one table that contains all codecs. It is like codecs.conf in mplayer that atm is 56k big in source (text) form. This is the biggest known table mapping of all possible fourcc to all possible codecs. (it's 14kb gzip-ed). A player that support more than one format - avi ,wmv, mov/qt. mkv does need some kind of table for interoperability, adding few new entries is not huge issue. Should I remind you that current proposal is mixture of avi and qt ? This means that if player supports only one of these we still need special mapping table, no matter how compatible codecs we've chosen. So tables are unavoidable. And even doubling the size of the biggest know would not make more than 32kb....
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", ...
I'm happy we haven't created nut using this method.
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.
Why don't you give it a shot? A new codec_id standard cannot come out of thin air, somebody must invent it, implement it and use it. Nut have the potential to make a difference. If you had put at least half of the effort you made for backward_ptr in developing new format_id system, NUT would have been compleated already.
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.
((2^32) - number_of_legetime_fourcc)*4
other ideas welcome, but i really hope we can put this issue aside asap and get on with release..
I know one thing. If I neglect something, it will come to bite me at later point. NUT is well polished format. Every aspect have been flamed, hammered, tuned and tempered. I don't want to neglect the probably most important at user point of view aspect because you are hurrying for the release.