Hello, On Mon, May 24, 2010 at 01:01:45PM +0300, Uoti Urpala wrote: > On Mon, 2010-05-24 at 00:26 +0400, Stanislav Maslovski wrote: [skipped] > > [ 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. First of all, thanks for a quick reply! My card has 256 MB of video RAM. > 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. Currently, this is the only file with which I can notice this problem. But I doubt that the source of the problem is simply the low amount of video RAM, for the reasons that I give belov. [skipped] > > 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. My random guess is that maybe under some conditions such a situation appears that the video surfaces (or some other related resources in X or in the nvidia driver) are allocated but not freed later. This could explain why this video can be played normally on the first run but cannot be on the second. But read also below... > > 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. Thanks for this note, I could actually find this option myself in the man page... Nevertheless, I tried this option and found a surprising result: while I cannot play that video now with a simple command like this mplayer -vo vdpau .... I can play it normally with no problems at all with this command: mplayer -vo vdpau:output_surfaces=N where N can be any value in the range 2 <= N <= 9! The manpage says that the default is 3, and if I set N explicitly to 3 I do not observe any problems, the video plays perfectly! With N > 9 I can see lots of memory related errors in the log, and also the video stutters, but interestingly enough the distortions in the picture look quite different. With, let me say, "my bug" in action, the playback looks much alike a playback of a damaged video file (with typical MPEG-4 artifacts), while with an explicit output_surfaces option with N > 9 the frames just flicker back and forth, and there is no artifacts in them (to be precise, sometimes in the beginning of a playback I see unfinished video frames but they disappear in a half a second after which the picture just flicker). > 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 I do not have any. I am on a very simplistic setup with a light-weight WM (IceWM) and without any DE. > worth testing (and preferably also disabling the composite X extension, This option is also currently disabled. BTW, I played with this setting some time ago, and I noticed that this my bug could be observed in both cases: with the composite extension enabled and also without it. -- Stanislav
