|Summary:||www/firefox: High CPU usage when playing HTML5 video when audio/alsa-plugins is built with BUFSZ_P2=off|
|Product:||Ports & Packages||Reporter:||Henry Hu <henry.hu.sh>|
|Component:||Individual Port(s)||Assignee:||freebsd-gecko mailing list <gecko>|
|Severity:||Affects Only Me||CC:||aksyom, jbeich, mi, thiago, w.schwarzenfeld|
Description Henry Hu 2015-10-13 02:03:35 UTC
With default firefox 41.0.1,1 and alsa-plugins 1.0.29, firefox has high cpu usage when playing html5 video. With an i7-3612QM, firefox uses >130% CPU when playing 720p youtube video. If I enable BUFSZ_P2 for audio/alsa-plugins, CPU usage reduces to ~50%. If I switch to other backends for alsa(like pulse), CPU usage also reduces. Please set the default value of BUFSZ_P2 to "ON" for alsa-plugins, or fix alsa's oss backend.
Comment 1 Jan Beich 2015-10-13 14:25:38 UTC
BUFSZ_P2 is a compatibility hack for audio/alsa-plugins/files/alsa-plugins.patch. When enabled it causes assertion-crash in aplay(1) from audio/alsa-utils. Only gecko@ ports appear to be fragile with ariff's improvements for alsa-plugins-oss which mi tried to fix in bug 196051. As a workaround try to comment out EXTRA_PATCHES line in alsa-plugins port to bring experience closer to OSS on Linux. Current defaults are balanced due to lack of package flavor support or option requirements in dependencies. Better approach is to enable PULSEAUDIO by default (already in configure.in) until OSS is polished enough to land upstream: media/libcubeb used for mainly HTML5 audio playback and media/webrtc/trunk/webrtc/modules/audio_device for device enumeration, capture & playback in WebRTC. files/1021761 already contains partial support, so when you build Firefox against PULSEAUDIO but don't launch the server it'd fallback to OSS backend, same for ALSA if later uninstalled - see cubeb_init().
Comment 2 Henry Hu 2015-10-25 19:23:22 UTC
I tried to comment out the patch, and + OSS still works, CPU usage is low - When a HTML5 video is paused, it can't be resumed But if you do a seek, it will resume at the seek position So for now I'll live with the BUFSZ_P2.
Comment 3 Arto Pekkanen 2015-12-25 16:20:54 UTC
(In reply to Jan Beich from comment #1) I am another user of www/firefox who can verify that the stock alsa-plugins without BUFSZ_P2 causes www/firefox to use more than 100% CPU when playing videos. Anyway, the total effect of not having this bug fixed is that now FreeBSD users do not have a properly working, modern, full-featured browser. The reason for my claim is that the other full-featured browser would be www/chromium, but it is also buggy and unstable, since tabs often crash. There's also a bounty for fixing www/chromium, which I am trying to help fix as a non-professional, but nothing has been done to fix it thus far (see: https://github.com/gliaskos/freebsd-chromium/issues/40). As a sidenote: I am trying to get a core dump from crashing tabs in chromium, but have not been successful yet (because I am not a professional software developer). Because of the total effect this bug has on the few desktop users of FreeBSD, I would suggest creating a clone of alsa-plugins, let's call it alsa-plugins-gecko, in which the BUFSZ_P2 is forced on by default, and having www/firefox link against alsa-plugins-gecko until a proper solution is found. Creating a BUFZS_P2 clone of alsa-plugins would have no negative side effects, since only gecko ports would link against it. Later, when the actual issue has been resolved and when it can be proven that www/firefox works well with the stock alsa-plugins, this temporary workaround can be reverted. If we leave this issue as it is, me and other users of www/firefox are forced to do all kinds of extra work to get firefox working. PS. My solution was to simply compile and install alsa-plugins with BUFSZ_P2 option, which causes negative side effects in other apps. I will try compiling www/firefox with PULSEAUDIO and see how well that works. But I would prefer not having to depend on PULSEAUDIO, I consider it a cancer to be avoided.
Comment 4 commit-hook 2016-03-02 22:49:11 UTC
A commit references this bug: Author: jbeich Date: Wed Mar 2 22:48:45 UTC 2016 New revision: 409976 URL: https://svnweb.freebsd.org/changeset/ports/409976 Log: audio/alsa-plugins: partially revert r380063 Restore BUFSZ_P2=on by default as a temporarily fix for excessive CPU usage in Firefox. r378529 wasn't enough to make BUFSZ_P2=off transition smooth. PR: 203732 Reported by: Henry Hu, Arto Pekkanen, many more indirectly MFH: 2015Q1 Changes: head/UPDATING head/audio/alsa-plugins/Makefile
Comment 5 commit-hook 2016-03-03 00:08:34 UTC
A commit references this bug: Author: jbeich Date: Thu Mar 3 00:08:23 UTC 2016 New revision: 409992 URL: https://svnweb.freebsd.org/changeset/ports/409992 Log: MFH: r409976 audio/alsa-plugins: partially revert r380063 Restore BUFSZ_P2=on by default as a temporarily fix for excessive CPU usage in Firefox. r378529 wasn't enough to make BUFSZ_P2=off transition smooth. PR: 203732 Reported by: Henry Hu, Arto Pekkanen, many more indirectly Approved by: ports-secteam (feld) Changes: _U branches/2016Q1/ branches/2016Q1/UPDATING branches/2016Q1/audio/alsa-plugins/Makefile
Comment 6 Arto Pekkanen 2016-03-03 19:31:22 UTC
(In reply to commit-hook from comment #4) Cool. I'll upgrade my system soon and test Firefox.
Comment 7 Arto Pekkanen 2016-03-04 14:40:46 UTC
(In reply to commit-hook from comment #4) I have now updated all packages, including alsa-plugins. Firefox uses Pulseaudio as audio output. Firefox uses ~150% CPU (cpu usage via top, raw momentary cpu %, not weighted) when playing the following video from Youtube on 720p: https://www.youtube.com/watch?v=Eho8HDtkCiU My laptop has 2.6 Ghz i5 processor and Intel HD4000 GPU, so I think my hardware should definitely be on par with the task of playing the above video on 720p, and the CPU usage should not got above 100% ... I will try compiling/installing Firefox without Pulseaudio, and see if I get any better results.
Comment 8 Arto Pekkanen 2016-03-04 15:38:35 UTC
(In reply to commit-hook from comment #4) Okay, now played the above Youtube test video with Firefox without Pulseaudio. CPU usage (top, raw cpu %) went down a bit, from 150% to around 100%, but CPU usage is still high. I've also discovered the problem is not only in the audio, problem also with video. You see, when I play video via Firefox, X.org uses around 50% CPU. This means that there is a LOT of data copying going on between Firefox and X.org. Honestly, the only way I could get X.org use more than a few percent of CPU during video playback with any media player is to use the obsolete X11 -backend (which apparently copies data and does other horrible things).
Comment 9 Jan Beich 2016-03-04 19:06:10 UTC
(In reply to Arto Pekkanen from comment #8) > ... when I play video via Firefox, X.org uses around 50% CPU. This means that there is a LOT of data copying going on between Firefox and X.org. What window resolution, video resolution, whether fullscreen or not? Better open a new bug and try various rendering toggles: - run a compositing manager (e.g., x11-wm/compton) - x11 driver (i915 vs. generic kms vs. vesa) or its options - gfx.xrender.enabled -> false - gfx.canvas.azure.backends -> skia - gfx.content.azure.backends -> skia (maybe buggy) - layers.offmainthreadcomposition.enabled -> false - layers.acceleration.force-enabled -> true (uses OpenGL) - BUNDLED_CAIRO -> off - GTK2 vs. GTK3 Firefox doesn't offload video decoding/scaling via VAAPI/XVideo unlike mpv/mplayer yet. However, OpenGL layers are scaled on hardware if available.
Comment 10 Arto Pekkanen 2016-03-04 21:39:24 UTC
(In reply to Jan Beich from comment #9) I will try what you suggested. I've not used a compositor, because the SNA acceleration in Xorg configuration provides a working VSync (whereas the other acceleration methods would incur tearing in video playback)- But I could try using compton, see if it helps. If Firefox uses OpenGL (via Cairo) during video playback, I am really curious why it makes X.org use 50% CPU ... very strange indeed.
Comment 11 Henry Hu 2016-03-04 22:31:02 UTC
(In reply to Arto Pekkanen from comment #10) Check this bug report: https://bugzilla.mozilla.org/show_bug.cgi?id=970308 A developer mentioned "My answer was in reference to Linux not having hardware acceleration at this stage" And "There is no hardware acceleration on Linux at this stage. See bug 1210726. (and fwiw, at this stage no web browsers provide hardware accelerated video decoding)." https://bugzilla.mozilla.org/show_bug.cgi?id=1210726 It seems like that decoding with hardware is easier to support/is working, but rendering is harder.
Comment 12 Arto Pekkanen 2016-03-05 00:15:15 UTC
(In reply to Jan Beich from comment #9) Hey I figured out why X.org uses so much CPU %. It is because of the XRender extension. If I disable XRender, then Firefox would use more CPU whilst X.org would use less. Apparently XRender is used to do basic compositioning at X-server end, and in my situation turning it off solved some of the excessive CPU usage.
Comment 13 Henry Hu 2016-03-05 00:44:24 UTC
(In reply to Arto Pekkanen from comment #12) You can go to about:config and turn gfx.xrender.enabled to off to see if it makes a difference. There are some plans to turn it off by default.
Comment 14 Jan Beich 2016-03-07 20:26:47 UTC
(In reply to Arto Pekkanen from comment #12) > If I disable XRender, then Firefox would use more CPU whilst X.org would use less. XRender can be disabled just for web content but not compositing: layers.use-image-offscreen-surfaces -> true (hidden pref). However, upstream disabled for both in Firefox 47. https://bugzilla.mozilla.org/show_bug.cgi?id=1180942#c17 https://bugzilla.mozilla.org/show_bug.cgi?id=1241832#c6
Comment 15 w.schwarzenfeld 2018-01-13 04:54:01 UTC
We hab version at 57.0.2. Is this still relevant?
Comment 16 Henry Hu 2018-01-13 05:00:10 UTC
(In reply to w.schwarzenfeld from comment #15) The original problem mentioned in the title is fixed. However, firefox still uses too much CPU in my opinion (~70% for the mentioned video). If I play the same video using mpv, it uses single digit percent. So this bug may still be relevant. On the other hand, this seems to be an upstream problem.
Comment 17 w.schwarzenfeld 2018-01-13 05:05:08 UTC
Thanks for quick reply.