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