Rich Felker <dalias@aerifal.cx> writes:
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.
There is *nothing* universal about so-called fourccs. They just happen to be used by AVI, and AVI is unfortunately the most wide-spread format. Quicktime also uses 32-bit codes, but they are *different* from those used in AVI for many codecs. It is most obvious for audio, where quicktime uses four printable chars, as for video, while AVI uses a 16-bit number. Any player capable of playing more than one file format will need tables to convert from whatever the input files use to something internal, whether or not the internal codes are equal to those used by one format or another.
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).
That is *already* the case.
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.
To that end, it makes sense making the field syntactically variable-sized. If a player wants to treat 4-byte identifiers as a number, it may do so now. If a later standard uses longer identifiers, such players will have to change, but they will need updating anyway if the codec identifications change. -- Måns Rullgård mru@inprovide.com