[MPlayer-users] mplayer-git: problems with vdpau playback
Stanislav Maslovski
stanislav.maslovski at gmail.com
Tue May 25 10:27:10 CEST 2010
On Tue, May 25, 2010 at 06:01:38AM +0300, Uoti Urpala wrote:
> > 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.
Oh, I see. That is the explanation: when I tested it last night I did
not realize that when I gave a suboption to -vo vdpau I also had to
explicitly state -vc ffh264vdpau on the command line (normally those
codec definitions are taken from the section [vo.vdpau] in my config
file). Without an explicit -vc option mplayer had been using the
ffmpeg's software decoder and of course I could not notice any
problems. Obviously, the video memory usage in those (false) tests was
also lower and that is why I could raise N up to 9 with no problems...
I have just tested it againg and saw that when -vc ffh264vdpau is
given on the command line,the option -vo vdpau:output_surfaces=3 has a
consistent behavior with just -vo vdpau (I see the same playback
problem). And with -vo vdpau:output_surfaces=2 the video can be played
normally. So, the conclusion is that it is really a memory related
issue.
--
Stanislav
More information about the MPlayer-users
mailing list