[NUT-devel] Fourcc spec

[Oded Shimon]

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.

- ods15