[NUT-devel] Fourcc spec

[Oded Shimon]

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