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

wm4 nfxjfg at googlemail.com
Sun Dec 8 16:22:48 CET 2013


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

> On Sun, Dec 08, 2013 at 03:49:12PM +0100, wm4 wrote:
> > On Sun, 8 Dec 2013 14:52:43 +0100
> > Reimar Döffinger <Reimar.Doeffinger at gmx.de> wrote:
> > 
> > > My best explanation is that this is a NVidia driver bug, there is no
> > > reason the decoder should care about aspect changes.
> > 
> > Of what nature would this bug be? I can see no problems on mpeg2 vdpau
> > decoding with nvidia drivers on non-mplayer. Is it triggered by
> > libavcodec threading? (I think I heard something about threading.)
> 
> The driver claims that there is a size mismatch even though no size
> anywhere changed, only aspect.
> More specifically, reinitializing the decoder _with exactly identical
> settings_ fixes a VDP_STATUS_INVALID_SIZE error, which doesn't make any
> sense.
> You probably see no issues anywhere because everyone else uses the same
> overkill approach of doing a complete reinitialization for no good
> reason on an aspect change.

Well, personally I reinitialize the decoder _only_ if the actual size
changes. So I see no bug here.

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.

> 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 do not consider that relevant though, since as said doing a full
> reinit is idiotic and wasteful anyway.



More information about the MPlayer-users mailing list