[NUT-devel] Fourcc spec

[Oded Shimon]

On Sat, Dec 23, 2006 at 01:56:29PM +0100, Michael Niedermayer wrote:
> On Sat, Dec 23, 2006 at 01:21:07PM +0200, Oded Shimon wrote:
> > On Sat, Dec 23, 2006 at 01:15:39PM +0200, Oded Shimon wrote:
> > > OK, my best attempt:
> > > 
> > > Option 1: Keep the current situation:
> > > The spec explicitly says to use AVI fourcc's, is vague on what to do if 
> > > there is no AVI fourcc.
> > > Pros:
> > > Use the same codec tables as AVI for both muxing and demuxing
> > > Keep fourcc's of old codecs for bug workarounds
> > > Cons:
> > > Several fourcc's per codec
> > > No defined fourcc's for codecs which are not contained in AVI
> > > No defined fourcc's for any codec really
> > > 
> > > Option 2: Make an explicit list, using only existing and popular fourcc's 
> > > from AVI for codecs which exist in AVI, allowing several fourcc's per 
> > > codec. (DX50, XVID, \x55\x00, ..)
> > > Pros:
> > > Use the same codec tables as AVI for both muxing and demuxing
> > > Keep fourcc's of old codecs for bug workarounds
> > > Defined fourcc's for all codecs
> > > Cons:
> > > Several fourcc's per codec
> > > "Looks silly" (I'm personally not really against this, but I bet Rich 
> > > is...)
> > > 
> > > Option 3: Make an explicit list, similar to the list I originally proposed
> > > Pros:
> > > Defined fourcc's for all codecs
> > > Single fourcc per codec
> > > "Clean" in sane codec names
> > > Cons:
> > > Different tables for AVI and NUT (for muxing, demuxing can still use 
> > > common table)
> > > Loss of bug workarounds
> > > 
> > > 
> > > Summary:
> > > A - Defined explicit codecs forucc's
> > > B - bug workarounds ability
> > > C - single fourcc per codec
> > > D - Single table in implementation for muxer
> > > E - "Sane" codec names
> > > 
> > > Option   A  B  C  D  E
> > >      1      X     X (x) - since it is not explicit in spec, it doesn't matter as much
> > >      2   X  X     X
> > >      3   X     X     X
> > 
> > P.S. Since the lists are informative and not normative for muxers, they do 
> > not necessarily require constant updating and upkeep, so I did not 
> > consider this as an advantage or disadvantage.
> 
> if the lists are not normative that i bet every commercial company will
> use their own fourcc divx, 3ivx, ...
> why?
> 1. the company can better claim that its their own supperior technology
> 2. they dont need to bother to implement the standard correctly, its enough
>    if their decoder matches their encoder, this is what has happened with
>    codecs in avi and as its less work = less money it will happen again.
>    It didnt happen with mpeg-ps/ts just because there are too many hw
>    decoders around which cant be updated that easily all IMHO
> 
> if my hypothesis turns out to be true then 3. would loose the 
> "single fourcc per codec" and ""Sane" codec names" as in practice the
> majority of videos would not use the recommanded fourccs
> 
> so that brings us to option 4 which would require a player to only support
> a codec if the one and only standard fourcc where used, if a unknown fourcc
> is used demuxing it would be a violation of the spec ...
> 
> if that would prevent the issue iam not sure though ...

The list IS normative for demuxers, not for muxers. This was already in my 
original proposal, I forgot to re-mention it here. I did not quite 
understand your hypothesis, so I am not sure if being normative for 
demuxers fixes what you said.

Regardless, I'm leaning to 2.

- ods15