[MPlayer-dev-eng] [PATCH] biPlanes must always be 1 in avi files (bug #146)

[Reimar Döffinger]

Hi,
> >>this patch makes sure that biPlanes is always 1 when writing an AVI, as
> >>according to Microsoft that's how it must be (see bugzilla for more
> >>information).
> >>I intend to apply soon.
> >
> >i'm object it.
> >first, check a bunch of wild files, they all have 0 there.
> >the planes=1 is only true for the uncompressed rgb files.
> >for yuv files and codecs it's 0.
> 
> To be honest, I don't see either 'there are broken files out in the 
> wild' or 'virtualdub is broken' as valid arguments that MEncoder should 
> also create broken files (where broken == "in violation of the M$ spec" 
> - I accept other definitions of broken are possible).

No, but M$ has no encoding program of its own. And "you can expect that
files created by VirtualDub work with every player, so better do it like
them" is a good argument IMHO. Especially windows programs are often
created so that they "work somehow" and don't care about any specs.
Fact is, changing something always has a risk of breaking it, the
question is: is it worth that risk? And in this case to me the answer seems to
be no.

[...]
> I'm inclined to agree that forcing the AVI muxer to write 1, even if 
> that's incorrect, is wrong; however, Reimar has argued that the MOV 
> demuxer is also the wrong place to fix this, so I'm not sure what else 
> to do.

Well, the mov demuxer is the right place if it knows the right value
here - which I assumed it doesn't ...

> Being honest here, the only reason we noticed the problem was because 
> we'd written an in-house AVI demuxer with reference to the above spec, 
> which was giving warnings on files created by a MOV->AVI conversion with 
> mencoder. So yes, our AVI demuxer has been changed to ignore the 
> biPlanes field, and the issue is largely academic. Nevertheless, it's 
> pretty clear to me that mencoder is currently writing files in violation 
> of the AVI spec, which is why I opened the bug. The fact that most 
> players will deal with the problem is mere good fortune.

Well, if many files behave like this it is not mere fortune but more
"the power of the masses". I have to agree that it is unfortunate that
rarely anyone keeps to the specs, but I doubt this is enough reason to
change it - although it is the fault of the spec, too as it defines no
real use for that field, so there seems to be no player that needs it to
be set correctly (e.g. if WMP would complain about it people would keep
to the spec I'm sure)...

Greetings,
Reimar Döffinger