GNOME Bugzilla – Bug 732015
High cpu consumption on youtube h264 videos
Last modified: 2017-03-14 12:48:25 UTC
Since I get vaapi plugins to work by default with Totem, I've noticed a few cases where the rendering is wrong. Totem's process also appear to consume 5/6 times more cpu than software decode. Here are a couple of examples from Youtube : https://www.youtube.com/watch?v=1jBWfQ6C1qY https://www.youtube.com/watch?v=ARgiPJobKnE (Can be downloaded with youtube-dl)
Created attachment 278906 [details] Totem capture of broken rendering
My bad, the rendering problems were entirely my fault for not updating the textures size with upload gl meta... The significant cpu consumption is still a problem.
CPU consumption seems to be higher on this kind of profile : h264 (Constrained Baseline) (avc1 / 0x31637661), yuv420p, 480x360 [SAR 1:1 DAR 4:3], 400 kb/s, 29.97 fps, 29.97 tbr, 30k tbn, 59.94 tbc (default) and a lot lower on something like this : h264 (High) (avc1 / 0x31637661), yuv420p, 1280x720, 1707 kb/s, 23.98 fps, 23.98 tbr, 48k tbn, 47.95 tbc (default)
Moving to Product:GStreamer, Component:gstreamer-vaapi
Thanks for taking the time to report this. I have just tested both streams: gst-play-1.0 $(youtube-dl -f 18 -g https://www.youtube.com/watch?v=1jBWfQ6C1qY) --videosink=clutterautovideosink ~6.6% CPU (vaapi/haswell) ~7% CPU (software) gst-play-1.0 $(youtube-dl -f 18 -g https://www.youtube.com/watch?v=ARgiPJobKnE) --videosink=clutterautovideosink ~5.3% CPU (vaapi/haswell) ~5.3% CPU (software) In both cases GLTextureUpload meta is negotiated when vaapi is used and in both cases the CPU usage is similar, since both streams have small resolutions (360p and 240p). I guess that this issue has been solved in recent versions of gstreamer-vaapi. Please feel free to reopen this bug report if the problem still occurs with a recent version of GNOME, or feel free to report this bug in the bug tracking system of your Linux distribution if your distribution still supports the version that you are using.