[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