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

Reimar Döffinger Reimar.Doeffinger at gmx.de
Sun Dec 8 17:04:52 CET 2013


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

Also, from my side I am wondering why you don't see the issue.
I mean I can see how you might not have any issues reinitializing
the decoder on aspect change, but you said you aren't doing that,
so I would think you should still see the issue.
Or did you mean you only skip reinitializing the VO on aspect change,
but do create a new VDPAU decoder?
That might be somewhat less wasteful, but it still should not be
necessary.


More information about the MPlayer-users mailing list