[MPlayer-users] recent regression in initial h264 decode/display

[Reimar Döffinger]

On Mon, Aug 12, 2013 at 09:48:27PM +0200, Reimar Döffinger wrote:
> On Mon, Aug 12, 2013 at 08:10:01PM +0100, Andy Furniss wrote:
> > Reimar Döffinger wrote:
> > >On Mon, Aug 12, 2013 at 05:44:58PM +0100, Andy Furniss wrote:
> > >>Just updated mplayer from one a few days ago and I am seeing
> > >>initial corruption playing h264.
> > >>
> > >>It clears and then plays normally, this is using s/w decode and
> > >>different -vo s make no difference.
> > >>
> > >>ffmpeg is head, but with head ffmpeg, ffplay does not have the
> > >>issue.
> > >
> > >This is far too little detail, at least a sample video or full
> > >MPlayer output is necessary.
> > 
> > Yea, I was rushing and still am TBH, just wanted to get the info out and
> > assumed you would see it with a quick test.
> > 
> > It seems all my h264 are affected some more than others and I also found
> > another regression caused by the same commit - at least I have a link to
> > this one :-)
> > 
> > ffmpeg is on d4ab1292e9ac3a13a33d5405d8538b27a56fa7fd
> > 
> > The guilty mplayer commit is -
> > 
> > r36418 | reimar | 2013-08-11 19:28:58 +0100 (Sun, 11 Aug 2013) | 2 lines
> > 
> > Make VDPAU support work again with latest FFmpeg.
> > 
> > Both issues are not present with svn up -r26417
> 
> Hm, this seems somewhat serious as this commit isn't supposed to affect
> software decoding in any way.
> 
> > ftp://ftp.tek.com/tv/test/streams/Element/MPEG-Video/625/cact_400.m2v
> 
> Will take some time to download and it's too late for me today anyway.
> I'll try to have a look tomorrow.

Crash fixed already though, but could not reproduce the other issue.