Opened 19 years ago

Closed 19 years ago

Last modified 19 years ago

#146 closed defect (wontfix)

Invalid AVI file when converting mov->avi

Reported by: richardv@… Owned by: moritz@…
Priority: normal Component: demuxer
Version: 1.0pre6 Severity: normal
Keywords: Cc:
Blocked By: Blocking:
Reproduced by developer: no Analyzed by developer: no

Description

According to
http://msdn.microsoft.com/archive/en-us/directx9_c/directx/htm/bitmapinfoheaderstructure.asp
the biPlanes field in a BITMAPINFOHEADER structure should be set to 1. However,
when mencoder converts from mov to avi with -ovc copy, this field is set to
zero, and this causes problems with some fussy players.

Attachments (2)

mov_planes.patch (693 bytes ) - added by richardv@… 19 years ago.
Proposed fix
biPlanes.diff (789 bytes ) - added by reimar 19 years ago.
Always write biPlanes = 1 in the avi muxer

Download all attachments as: .zip

Change History (9)

by richardv@…, 19 years ago

Attachment: mov_planes.patch added

Proposed fix

comment:1 by richardv@…, 19 years ago

comment:2 by reimar, 19 years ago

I'm not sure this is the right place to fix - the demuxer does not know how many
planes the video consists of and MPlayer uses internally values != 1. It should
better be set in the avi muxer.

by reimar, 19 years ago

Attachment: biPlanes.diff added

Always write biPlanes = 1 in the avi muxer

comment:3 by reimar, 19 years ago

attachments.isobsolete: 01

Please test if this one works

comment:4 by richardv@…, 19 years ago

Sorry about the delay... yep, that seems to work fine. Thank you.

I'm intrigued though - what are planes used for, and how does the rest of
mplayer cope with the mov demuxer giving biPlanes==0?

In any case, surely it should be set to the correct value before it gets to the
avi muxer: it's not the muxer's job to cope with brokenness further up?

comment:5 by reimar, 19 years ago

(In reply to comment #4)

I'm intrigued though - what are planes used for, and how does the rest of
mplayer cope with the mov demuxer giving biPlanes==0?

It is used internally as a description of the image AFAICT, and MPlayer uses
e.g. 3 planes sometimes. Not sure if it is really used somewhere, but 0 is
suppose to mean unknown, and should probably set correctly by the decoder if the
demuxer doesn't know it.

In any case, surely it should be set to the correct value before it gets to the
avi muxer: it's not the muxer's job to cope with brokenness further up?

No, as a values != 1 is no necessarily a bug "further up" - it only is when it
gets into the avi this way IMHO.

comment:6 by reimar, 19 years ago

There have been objections to this changes, as e.g. VirtualDub and many other
programs set it to 0, too.
With which players does this cause problems? Probably they should be fixed as
they wont be able to play many "normal" files.

comment:7 by richardv@…, 19 years ago

Resolution: wontfix
Status: newclosed

I think we decided on mplayer-dev-eng to not fix this, on the basis of "If it
ain't broke..."

Note: See TracTickets for help on using tickets.