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

[Uoti Urpala]

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.