Opened 15 years ago

Closed 14 years ago

Last modified 14 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: Analyzed by developer:

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@… 15 years ago.
Proposed fix
biPlanes.diff (789 bytes) - added by reimar 15 years ago.
Always write biPlanes = 1 in the avi muxer

Download all attachments as: .zip

Change History (9)

Changed 15 years ago by richardv@…

Proposed fix

comment:1 Changed 15 years ago by richardv@…

comment:2 Changed 15 years ago by reimar

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.

Changed 15 years ago by reimar

Always write biPlanes = 1 in the avi muxer

comment:3 Changed 15 years ago by reimar

  • attachments.isobsolete changed from 0 to 1

Please test if this one works

comment:4 Changed 15 years ago by richardv@…

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 Changed 15 years ago by reimar

(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 Changed 15 years ago by reimar

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 Changed 14 years ago by richardv@…

  • Resolution set to wontfix
  • Status changed from new to closed

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.