On Sat, Dec 23, 2006 at 01:56:29PM +0100, Michael Niedermayer wrote:
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 ...
The list IS normative for demuxers, not for muxers. This was already in my original proposal, I forgot to re-mention it here. I did not quite understand your hypothesis, so I am not sure if being normative for demuxers fixes what you said. Regardless, I'm leaning to 2. - ods15