[MPlayer-users] playing dixv encoded files in windows

[D Richard Felker III]

On Mon, Oct 11, 2004 at 10:32:07PM -0700, RC wrote:
> On Mon, 11 Oct 2004 23:27:54 -0400
> D Richard Felker III <dalias at aerifal.cx> wrote:
> 
> > - does the file encoded with old mencoder cause new mplayer to crash?
> 
> No.  Works fine with:  dev-CVS-041008-12:19-3.2.2
> 
> > - does the file encoded with new mencoder cause old mplayer to crash?
> 
> Yes.  I even said as much in the first message.  I tried with pre5,
> pre4, and pre3try2, as well as CVS.
> 
> > imo the problem is not pullup but something in mplayer/mencoder.
> > knowing which one would be helpful. 
> 
> No doubt it's a problem in mencoder.  The bug is triggered 
> by IVTC as well as pullup, but not by DETC, and only happens with
> MPEG1/2 AFACT.  It did not happen when I used MPEG-4.

The problem is that mencoder wants to duplicate the very first frame
to keep a/v sync, but pullup and ivtc buffer frames so no frame has
been output yet. In principle this shouldn't be a problem...

...BUT mpeg1/2 video don't belong in avi to begin with, and mplayer
has a really nasty hack in the demuxer code to read some mpeg headers
from the first video packet if mpeg video is inside avi. Unfortunately
this code is broken and crashes in the case where the first packet is
a zero-length ("duplicate") frame.

One obvious solution is to add vf_harddup to the end of the filter
chain...but this won't work because harddup will fall back to "soft"
(zero-length frame) duplication if it hasn't seen any frames yet. I
suppose this could be fixed though.

Anyway, IMO the bug is not a bug in mencoder, rather it's a bug in the
idiotic mpeg2-in-avi playback code in mplayer. Note that no other
players support this nonstandard wrapping, or if they do (maybe ffplay
does..?) they should accept it just fine.

Rich