[MPlayer-users] VDPAU errors, flickering black video display on aspect change in MPEG2 TS

[wm4]

On Sun, 8 Dec 2013 16:33:39 +0100
Reimar Döffinger <Reimar.Doeffinger at gmx.de> wrote:

> On Sun, Dec 08, 2013 at 04:22:48PM +0100, wm4 wrote:
> > What might be slightly inefficient with my code is that it doesn't try
> > to create a h264 decoder with less than maximum reference frames, since
> > that isn't possible with the new vdpau libavcodec API.
> 
> Actually, huh? MPlayer uses the new API, and it can do it...

Only if it's compiled against ffmpeg, as far as I can see.

> > > The only thing related to threading is that the VPDAU decoder will
> > > see the aspect change many frames before the aspect actually changes
> > > in terms of displayed video, and this desync would cause us issues
> > > if we'd try to do a full decoder reinit on aspect change.
> > 
> > I don't see this with MT enabled either...
> 
> I don't see how you could not see it.
> The VDPAU decode function is called during slice decode, which with
> n threads multithreading will happen n frames before a frame with the
> new aspect is actually returned.

Right.

> If you're using FFmpeg multithreading I see no way you couldn't see
> that the frames with the new aspect are decoded long before you can
> in any way see the new aspect from your application.

My application separates decoder and VO init, though. The decoder is
initialized in the get_buffer callback (which also pretty much
guarantees that libavcodec's use is synchronized with the decoder). So
that's probably why it doesn't there. Now the question is, why doesn't
it happen on Mesa with mplayer? That could still hint on a bug in
either Mesa's or nvidia's drivers.