[NUT-devel] Fourcc spec

[Oded Shimon]

On Fri, Dec 22, 2006 at 01:28:25PM +0100, Michael Niedermayer wrote:
> On Fri, Dec 22, 2006 at 12:56:26PM +0200, Oded Shimon wrote:
> > The general NUT habit so far was to ignore existing implementation 
> > limitations...
> 
> its easy to find arguments against any solution, but unless you compare
> 2 possible solutions this is meaningless
> 
> question is not if solution X has a flaw, question is which solution
> has the fewest flaws

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


- ods15