After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 708145 - Stuttering video playback on Intel graphics
Stuttering video playback on Intel graphics
Status: RESOLVED DUPLICATE of bug 726048
Product: totem
Classification: Core
Component: Movie player
3.10.x
Other Linux
: Normal major
: ---
Assigned To: General Totem maintainer(s)
General Totem maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2013-09-16 09:52 UTC by Charles Lahaine
Modified: 2014-09-06 06:47 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Charles Lahaine 2013-09-16 09:52:14 UTC
When playing video in fullscreen on Totem 3.8.2, the video is slow, stutters and choppy. This bug started in v3.2.x and has lasted across subsequent versions.

I'm currently using Sabayon 13.08 with kernel 3.10.9 and Gnome 3.8.3 on a M-6804m Gateway laptop. My graphics card is:

Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller [8086:2a02] (rev 03)

The same bug has already been reported here:

https://bugzilla.redhat.com/show_bug.cgi?id=753022

Let me know if you need more information.

Regards,
Charles
Comment 1 Bastien Nocera 2013-09-16 10:34:36 UTC
You'll want to check that this isn't a problem with GStreamer itself.

Try:
gst-launch-1.0 playbin uri=file://path/to/file videosink=cluttersink
Comment 2 Charles Lahaine 2013-09-19 08:33:09 UTC
I tested that command on a MKV file and it worked OK. I tried Totem with the same file and video looked choppy and stuttering.
Comment 3 Charles Lahaine 2013-09-30 03:51:00 UTC
It's funny. After recent updates, playback in Totem is fine again. Looks smooth indeed.

I'm using Sabayon 13.10 with the following packages:

gnome-desktop-3.8.4
totem-3.8.2-r1
gstreamer-1.0.10
mesa-9.2.0
xf86-video-intel-2.99.901
linux-sabayon-3.11.1

No more choppiness or sttuter, so I'm closing this bug report.
Comment 4 Charles Lahaine 2013-10-03 06:34:21 UTC
I reopened this bug because I'm getting a lot of tearing in Totem even with

CLUTTER_PAINT=disable-clipped-redraws:disable-culling

I set up that environment variable to get rid of tearing to no avail. Playback looked smooth though. Only way I found to get rid of tearing was to use

Option "TearFree" "true"

in /etc/X11/xorg.conf.d/20-intel.conf, but then again video looked choppy.

The behavior is as follows:
* If I set CLUTTER_PAINT then no sttuter but a lot of tearing.
* If I enable "Tear Free" in driver then no tearing but a lot of sttuter.
* If I do both things then no sttuter and no tearing but a lot of CPU usage.

Either way, I cannot get a satisfying experience with Totem. :(
Comment 5 Charles Lahaine 2013-10-10 12:17:32 UTC
FYI enabling "Tear Free" option causes laggy desktop animations but it's the only way I can get rid of tearing in Totem as CLUTTER_PAINT variable has no effect on such issue. Also choppiness is noticeable on full screen.

On the other hand, MPlayer works perfectly fine with no sttuter, no choppiness and no tearing problems whatsoever. MPlayer plays smoothly all the files I've tested so far, no need to apply any workarounds.

So I can confirm tearing affects Totem only and it's a recent issue. Regarding sttutering and choppy playback, these issues have been present for years in Totem. In fact, I found Totem (or GStreamer) to be very buggy and it hasn't played nice for me as far as I can remember.

Please let know if you need some more information, guys.

Regards,
Charles
Comment 6 Charles Lahaine 2013-11-05 07:48:33 UTC
I tried Totem in a fully updated Fedora 19 system, video playback looks choppy and stuttering too. I can fix it by setting environment variable

CLUTTER_PAINT=disable-clipped-redraws:disable-culling

but that renders the desktop glitchy, e.g. when taking snapshots.

Forget about tearing in Sabayon, it seems to be caused by Intel driver's SNA acceleration method.

Nevertheless, Totem in Fedora exhibits tear effect at the top of the screen only when plugging machine to a external monitor via HDMI.

Just to verfiy, mplayer works fine in all cases. Maybe it has a little bit of tearing when enabling SNA, but it's much less noticeable than with Totem.
Comment 7 Charles Lahaine 2013-11-29 09:16:16 UTC
I'm already on GNOME 3.10.1 and the chopiness, stuttering and tearing continues in Totem 3.10.1. Playback works just fine in Xnoise, which is based on GStreamer, like in almost any other player using Xv overlay. I'm giving up on totem. Really, what a piece of crap totem is.

P.S. Somewhere I had read clutter-gst was the culprit since this issues started as of Totem 3.2, when it started using clutter.
Comment 8 Charles Lahaine 2013-11-29 09:42:57 UTC
I'm not the only one with this problems during all these years. Take a look in this address:

http://www.hadess.net/2011/04/totem-in-gnome-30-plans-for-32.html

and read the last comment:

"I am having issues with playing fullscreen in totem 3.2 on an Intel card. The video seems jerky and slightly out of sync with the audio only on fullscreen but is fine when in window mode. I downgraded to totem 3.0 and the problem went away. Running fallback mode also fixed the issue. So I suspect that it is the change from Xv to clutter that is causing this problem. Any chance of an option to run totem 3.2 using Xv?"
Comment 9 Bastien Nocera 2014-03-13 16:24:05 UTC
Marking as a duplicate of bug 726048, which has some details about tearing:
https://bugzilla.gnome.org/show_bug.cgi?id=726048#c10
and
https://bugzilla.gnome.org/show_bug.cgi?id=711028#c9

Using the libva plugin and driver should help reduce CPU usage, and the bug in question will point you to the necessary patches to get everything working tear-free.

The "CLUTTER_PAINT=disable-clipped-redraws:disable-culling" envvar probably just made it redraw the whole screen/video at once, instead of just the parts that changed, which would explain the slowness.

*** This bug has been marked as a duplicate of bug 726048 ***
Comment 10 Charles Lahaine 2014-09-06 06:47:33 UTC
Thank you for your answer. Well, reading those bug reports has clarified a lot of things, althoug I am not very experienced in applying patches. Is there any chances those patches will get applied before the arrvial of Wayland?