Choppy video playback with GNOME Shell, Unity, Gnome-fallback with compiz, but not with Unity 2D and Gnome-fallback without compiz on two machines (1. Laptop with ATI Radeon X200M, 2. Desktop system with ATI Radeon HD6450). Media players doesn't report dropped frames, CPU usage is well below 100%. Tested with a 720p x264 video at about ~6000kbps. See https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/961124. Tried Fedora 16 and the problem is the same.
Same under KWin too.
Can you elaborate what 'choppy' means exactly? And how you estimated around 20 fps?
Also, please attach the Xorg.0.log file and the output of dmesg and glxinfo to this report.
Created attachment 59141 [details] dmesg
Created attachment 59142 [details] Xorg
Created attachment 59143 [details] dmesg
Created attachment 59144 [details] glxinfo
It's looks like the the video is skipping some frames (2 or 3) every second, so the picture is stuttering and in rare cases there's also some tearing. I also noticed that if I run glxgears (Vsync on) I can see stuttering there too, but not that often (every 5-10 sec).
Correction: it's not true, that it skips the frames every second, sometimes the video playback is smooth for 3 sec. Looks like a syncing issue.
Is that with fullscreen and/or windowed video playback? Which version of gnome-shell are you running? Have you configured compiz and kwin to unredirect fullscreen windows?
Both full screen and windowed, but if I shrink the media player's window size to about 400 x 280 the video is smooth. Also if I try to play an SD Xvid (632x486) video it's smooth even on fullscreen. This indicates that the problem depends on video resolution. I tried turning on the unredirect fullscreen windows option, but it didn't help. I have Gnome Shell 3.3.92 and 3.2 (in Fedora).
I mean not video resolution, the playback resolution.
Sorry, it depends on both, because a 600x400 video plays back smoothly on fullscreen (1280x800), but a 1280x720 video doesn't. The interesting thing is that the 1280x720 video is running smoothly at 600x400.
Also if the video is running smoothly, there's no tearing.
May I guess something? Cause mplayer isn't complaining about dropped frames the best explanation is that instead of a constant stream of frames: ---*---*---*---*---*---*---*---*---*--- ... We get something like this: ---***---------****------------*---*--- ... That is usually caused by to long pipelines, e.g. the 3D rendering causes to long stalls, witch lead to burst of frames with the playback... I'm also guessing that you are using Xv + "classic" mplayer, could you try the VDPAU implementation with mplayer2 instead? The result won't be better, but you get at least a good error message of what is going wrong here.
If I run glxgears simultaneously with the video playback even though the video is stuttering badly I get 56-60 fps on glxgears (my monitor works at 60Hz). I'm already using Mplayer2, but with XV - Textured Video. If I try VDPAU I get this message: "Failed to open VDPAU backend libvdpau_r300.so: cannot open shared object file: No such file or directory".
But I guess, that's the problem. The glxgears FPS should be at 60 all the time. If I run glxgears during an SD video, it starts stuttering and tearing.
Correction: Running glxgears during an SD video introduces some tearing, but no stuttering.
Does Option "SwapbuffersWait" "off" make the stuttering better (or worse)? Note that it'll probably increase tearing for non-fullscreen apps.
Xorg.0.log: [ 14.912] (II) RADEON(0): KMS Color Tiling: enabled [ 14.913] (II) RADEON(0): KMS Pageflipping: enabled [ 14.913] (II) RADEON(0): SwapBuffers wait for vsync: disabled Nothing changed, the stuttering remained the same.
I get tear-free video playback with disabled metacity compositing and enabled EXAVSync in the xorg.conf file under Unity 2D and Gnome fallback. Disabling compositing alone doesn't solve the tearing problem, it only works with enabled EXAVSync.
(In reply to comment #21) > Disabling compositing alone doesn't solve the tearing problem, it only works > with enabled EXAVSync. For some reason, Ubuntu seem to have patched their metacity to enable automatic (server side) compositing even when client side compositing is disabled in the metacity configuration. Does EXAVSync help also when compositing is explicitly enabled in metacity?
"Does EXAVSync help also when compositing is explicitly enabled in metacity?" Yes.
This one turned out to be a configuration problem with metacity. I think we can close it now.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.