GNOME Bugzilla – Bug 783850
Totem uses dramatically higher CPU than any other video player
Last modified: 2017-07-27 09:08:57 UTC
Totem uses dramatically higher CPU than any other video player. Example 1: software playback under Gnome Shell Wayland: totem: 120% (but drops to 80% in Unity7) mplayer: 40% vlc: 40% [all are using ffmpeg for decoding] Example 2: hardware-accelerated playback under Gnome Shell Xorg: totem: 11% gst-play-1.0: 3% [both are using gstreamer-vaapi for decoding] Since the decoding libraries are theoretically the same it sounds like totem's performance problems might be in its rendering path.
You're comparing an application which uses clutter-gst with ones that don't. Wayland/gnome-shell isn't accelerated for GL video playback yet.
Thanks for clarifying that. I had theorised those were the two issues but not yet got around to proving it. Still, regardless of the technical details, this bug should remain open till fixed. It wouldn't matter so much if desktops didn't use Totem by default, but they do. So we should aim to make it more efficient given we can see it should be at least 2-3 times better than it is today.
There's nothing actionable in this bug, and there are plenty of other bugs opened against clutter-gst, GStreamer, gst-vaapi and others about performance enhancements.
Again, thanks for pointing that out. I'm not familiar with the source code. When dealing with user-visible bugs however, one should expect users to initially log the bug against the app they're using without knowing the underlying component that is to blame.
(In reply to Daniel van Vugt from comment #4) > Again, thanks for pointing that out. I'm not familiar with the source code. > > When dealing with user-visible bugs however, one should expect users to > initially log the bug against the app they're using without knowing the > underlying component that is to blame. I expected somebody with an @canonical.com address to be technical, perhaps incorrectly. I can't provide tech support in bugzilla though, just bug tracking. And as a bug to track, this bug isn't useful.
Technical, yes. But I don't have time to investigate and fix bugs at the same rate at which I discover them. It appears we've hit the typical problem with primitive bug trackers like bugzilla, that you can't track one bug across multiple components with different statuses. Fortunately launchpad doesn't have that shortcoming so I'll handle it from there, and log more detailed component bugs in future.
It appears there really is a totem-specific performance issue that does not exist in clutter-gst (under gst-launch-1.0). I have now completed a proof of concept patch for gstreamer-vaapi that makes clutter-gst (under gst-launch-1.0) super smooth and low CPU, but totem still uses 5x the CPU of gst-launch-1.0+clutter-gst: https://bugs.launchpad.net/ubuntu/+source/clutter-gst-3.0/+bug/1701463/comments/3