On Tue, 2010-05-25 at 04:48 +0400, Stanislav Maslovski wrote: > 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! This sounds really weird. I can see no explanation for such behavior except some completely "random" effect. The variable is initialized to 3 and then possibly overwritten by the user option; explicitly specifying a value matching the default should make no difference. Does specifying other unrelated vo vdpau suboptions have a similar effect? Did you really specify "-vo vdpau" as above when testing? If you didn't but just assumed the default to match that then one scenario where specifying "-vo vdpau:output_surfaces=3" would at least be expected to have _some_ effect is if you have different vo_vdpau settings in a config file (then specifying "-vo vdpau", with suboptions or not, will override them and change from those custom settings back to defaults). If specifying the default surface number really does have an effect then it sounds like there would have to be a player bug for it to have any chance to affect VDPAU; but OTOH the symptoms sound like they'd depend on NVIDIA driver state instead. One thing you could test is run "VDPAU_TRACE=1 mplayer ..." and see whether the *_surface_create operations differ. > 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). The log you posted in a later mail shows that you're not using VDPAU hardware decoding in that case but the FFmpeg software decoder. Any surface allocation errors won't cause corruption if you're not using hardware decoding. I think the error patterns aren't particularly interesting - they're what is to be expected if surface allocation fails.
