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