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