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