Hi from Linuxtag! On Wed, Dec 27, 2006 at 11:54:40PM -0500, Rich Felker wrote:
On Sun, Dec 24, 2006 at 01:21:00PM +0100, Michael Niedermayer wrote:
Having a list makes no sense unless it's normative for both sides.
agree though thats a statement and not a argument the argument ("proof" by contradction) is that if the muxer can choose any fourcc for standard mpeg4 (not buggy near mpeg4 ...) then a demuxer cannot support mpeg4 in nut with 100% certainity, theres the very small possibility that mpeg4 would be stored with another new and unknown fourcc ...
Does this mean that we want a spec after all which is normative both for muxers and demuxers? This would mean, there would be a single table in the nut muxer implementation, and if muxing a codec which does not have an entry in the table is attempted, muxing would fail. - The resolution would be to contact us and the codec would be officially added to the list, and then it could be muxed, until then it would be impossible. I am not against this, as - this is a bikeshed issue... What are your opinions on this? Rich, Michael, please reply...
btw, one interresting goal of the codec id system should be: the system must be generic so that 2 users who otherwise cannot communicate can mux and demux a codec X in nut with high propability of success, without manual intervention and assuming the codec has a de-facto standard fourcc in avi
agree. some thoughts...
- we cannot stop people from inventing their own nonstandard id's for their bad implementations of (mostly) standard codecs, regardless of what id system we use.
- aside from such malicious parties, people making nut files will generally be interested in having their files be playable on as many players as possible.
- if we provide a list of officially sanctioned codec id's for standard codecs, and require any conformant player to support these id's if it supports the codec in question at all, then (1) we can officially flame anyone making a player that omits support for the standard name, and (2) people intending for their files to be widely playable will use the standard name since other names might not be supported by settop devices, etc.
- players wanting to provide maximum compatibility will also support various broken names for codecs, but this provides no significant implementation difficulty in complexity, size, or performance.
it's for these reasons that i want to stick with what oded has been saying. the only question in my mind is _which_ names should we agree upon as the standard ones????
If we do the above suggestion - spec is normative for muxers, then the answer is fairly easy - use our own new "clean" fourcc list. I would see no argument against this, as NUT would have its own completely fixed and seperate table... - ods15