[NUT-devel] Fourcc spec

[Michael Niedermayer]

Hi

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


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I know you won't believe me, but the highest form of Human Excellence is
to question oneself and others. -- Socrates
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/nut-devel/attachments/20061223/aaf7dcca/attachment.pgp>