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