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

[Reimar Döffinger]

On Sun, Dec 08, 2013 at 04:41:23PM +0100, wm4 wrote:
> 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.

Well, we were talking about FFmpeg. But even if you're forced to use
the older new API it's only messier since you need to pass a context
in some other way - either via global variable or a list of global
variables that you index with a dummy "decoder" value you give to
libavcodec.

> > 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).

Hm, that might be kind of luck, I don't know if it's actually specified
if get_buffer should return the main context the application has or the
thread-specific context.
I suspect you enabled that libavcodec assumes get_buffer callbacks are
thread-safe, because otherwise I'd suspect your solution would in fact
break/have exactly the same issue.

> So
> that's probably why it doesn't there. Now the question is, why doesn't
> it happen on Mesa with mplayer?

Why should it? An aspect change is not a resolution change, there is
no sane reason for it to fail.

> That could still hint on a bug in
> either Mesa's or nvidia's drivers.

Well, I did say I am fairly confident to call this an NVidia driver bug.
Though regardless of whether it is a bug or not, MESA's behaviour seems
more convenient, I don't think it violates any requirements of the VDPAU
API and it seems to decode fine, so it's at least the better way to
handle it...