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

[Rich Felker]

On Tue, Jun 20, 2006 at 08:22:03PM +0100, Måns Rullgård wrote:
> 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.

This is incorrect. The quicktime, avi, and other id numbers do not
overlap, so no table of conversions is needed. All that's needed is a
list of 32bit ids mapping to decoders, and this list can be shared
among all formats.

If you had bothered to read the earlier threads this was already
addressed.

> > 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.

No it's not.

> > 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.

Absolutely everything in NUT is syntactically variable-sized, except
the index pointer at EOF which would just be difficult to parse if it
were. The question is not of syntax and never has been. The question
is semantics.

> 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.

Yes, with the added stipulations that, currently, identifiers are
required (semantically, not syntactically) to be 4-byte, and that
existing identifiers are reused whenever possible to avoid senselessly
bloating up the table or clashing with existing table entries from
other container formats.

Rich