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

[Måns Rullgård]

Rich Felker <dalias at 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 at inprovide.com