[MPlayer-users] mplayer-git: problems with vdpau playback

[Uoti Urpala]

On Mon, 2010-05-24 at 00:26 +0400, Stanislav Maslovski wrote:
> I am experiencing a certain -vo vdpau playback problem on my notebook
> with the following graphic card:
> 
> VGA compatible controller: nVidia Corporation G86 [GeForce 8400M GS] (rev a1)
> 
> The problem exists only in mplayer-git. This is what I observe:
> 
> When I play the file [1] with
> 
> mplayer -vo vdpau vdpau_test.mp4
> 
> for the first time after a reboot it plays normal. But on the second
> run (and the third, forth, etc.) I get these errors:

> [   vdpau] Error when calling vdp_video_surface_create: The system does not have enough resources to complete the requested operation at this time.

This error normally means that you're running out of graphics card RAM.
How much memory does your card have? From what I've seen several people
have had problems with 256 MiB cards but few with 512 MiB ones.

Is the problem specific to that file? Generally you'd expect videos with
small resolution to require less memory and large resolution to require
more memory.


> When I get these errors the video still plays but it stutters and is
> full of artifacts.

That's expected if some video surfaces could not be allocated.


>  If I restart X, I can play this file normally once
> again, but then I get the same errors on consecuitive runs.
> 
> There is no such problem with the mplayer compiled from SVN. I have
> also checked that this problem occurs with both mplayer-git compiled
> with ffmpeg-mt and with single-threaded ffmpeg.
> 
> Moreover, I have found a magical workaround for this bug. If I
> hibernate from within X after the first occurence of this bug, then
> when I return back this problem misteriously disappears! It does not
> reappear even if restart X after that.
> 
> It seems that the bug is somehow related to the X server, or to the
> nvidia driver (or maybe even to the hardware).

It doesn't necessarily count as a real bug - could be just inefficient
RAM use by the driver so that the card has barely enough free to work
even in the best case, and arbitrary small things could use up a bit
more RAM so it stops working.

>  However, because the
> mplayer from SVN does not trigger this bug, there is a probability
> that some kind of workaround in the vdpau driver is possible. That is

Well the driver could minimize RAM use; if you're right at the edge then
arbitrary small things could make the difference. However I'd expect
that to help in limited cases only - slightly smaller videos would
always play fine anyway, and more resource-hungry ones fail no matter
what.

You could test "-vo vdpau:output_surfaces=2". This allocates one less
output surface than the default which should reduce RAM use a bit. Note
however that lowering it to 2 has performance drawbacks and hurts timing
functionality so it's not recommended for normal use.

If you can do anything to reduce other video RAM use that could help. At
least disabling any compositing manager if you're using one would be
worth testing (and preferably also disabling the composite X extension,
which allows VDPAU to use overlay functionality that's generally
beneficial for frame display).