Bug 203732 - www/firefox: High CPU usage when playing HTML5 video when audio/alsa-plugins is built with BUFSZ_P2=off
Summary: www/firefox: High CPU usage when playing HTML5 video when audio/alsa-plugins ...
Status: Open
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: gecko
URL:
Keywords: performance
Depends on:
Blocks:
 
Reported: 2015-10-13 02:03 UTC by Henry Hu
Modified: 2016-03-07 20:26 UTC (History)
4 users (show)

See Also:
jbeich: maintainer-feedback+


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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 freebsd_committer 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 freebsd_committer 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 freebsd_committer 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 freebsd_committer 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 freebsd_committer 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