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
