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

Rich Felker dalias at aerifal.cx
Tue Jun 20 23:38:22 CEST 2006

On Tue, Jun 20, 2006 at 10:10:30PM +0200, Luca Barbato wrote:
> Rich Felker wrote:
> [postpone discussion later, just complete version 1 now, fourcc is the
> simplest solution.]
> Ok, looks sane that way, BUT
> [O(), tables, complexity, nobody will use our codecs]
> No, having a codec table for nut isn't any different than what we have
> already (see ogg, qt/mov, avi, mkv).

Yes it is. The only formats that need their own special tables right
now are the ones with small restricted sets of codecs and new specs
for each additional codec they support, i.e. ogg and mkv. Everything
else uses a common list of fourcc-compatible identifiers.

> So I'd like to have what iive
> proposed for the next nut revision and that means that the fourcc field
> should be changed now as codec_id and it should stay vb.

Of course all fields will stay variable-length even if the semantic
requirements demand a specific size. This has NEVER been questioned.

> The next revision will add the options about encoder/producer and so on.

This useless info can go in the info packet.

> I know that doesn't sound fine, but
> - somebody will bitch about complexity and bloat while it doesn't matter
> at all and a month is needed to convince them to move from their
> position (from past experience)

More than that.

> - avi fourcc and mov aren't that nice about tags as the proposed long
> term solution.

Yes they are. The more small/restricted the set of identifiers is, the
less likely people are to make stupid "equivalent" names. Consider for
example iso language codes versus ogg language crap. "eng" is very
simple and standard and no one will make variants on it. "English"
could easily become "english", "eng", "English(US)", "English with
some foreign words", "ENGLISH", "eNgLiSh", etc.


More information about the NUT-devel mailing list