Closed Bug 1060406 Opened 10 years ago Closed 10 years ago

Decoding WebM (VP8 or VP9) uses twice more CPU than Totem on some hardware, probably because of lack of hardware acceleration for Firefox composition

Categories

(Core :: Audio/Video, defect)

Product:
Core
Component:
Audio/Video
Version:
31 Branch
Platform:
x86_64
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 594876

People

(Reporter: mossroy, Unassigned)

Details

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:31.0) Gecko/20100101 Firefox/31.0 (Beta/Release)
Build ID: 20140715214327

Steps to reproduce:

On a computer without hardware VPX video acceleration :
- Play a WebM video in Firefox (VP8 or VP9 codec) and see how the CPU is used
- Play the same video with Totem on Ubuntu (12.04 or 14.04) and see how the CPU is used
(tested with http://media.xiph.org/mango/tears_of_steel_1080p.webm)


Actual results:

Firefox uses around twice more CPU than Totem


Expected results:

I would have hoped that the CPU consumption would be in the same range.
It prevents some videos to be played in Firefox, when they can be played with Totem
It also probably has bad consequences on battery usage for mobile devices (Firefox OS, Firefox on Android)
NB : I have this same behavior with Ubuntu 31 from Ubuntu repositories, and with Ubuntu 31 downloaded from Mozilla
I confirm, especially when decoding vp9 in YouTube, the only solution that i could think of so far for old hardware is running a new process for every new video tab so that it doesn't share resources with an already busy process! and this of course with e10s
I get around 75% CPU usage on Totem and Firefox with e10s enabled on nightly. There is an updated version of libvpx integrated in bug 1063356 which may improve the decoding time. You can't draw meaningful conclusions about other platforms based on desktop Linux results.

My guess is that there is a compositing cost on your hardware backend. The graphics section of my about:support is:

Adapter Description		NVIDIA Corporation -- Quadro 2000M/PCIe/SSE2
Device ID			Quadro 2000M/PCIe/SSE2
Driver Version			4.4.0 NVIDIA 331.38
GPU Accelerated Windows		0/1 Basic (OMTC)
Vendor ID			NVIDIA Corporation
WebGL Renderer			NVIDIA Corporation -- Quadro 2000M/PCIe/SSE2
windowLayerManagerRemote	true
AzureCanvasBackend		cairo
AzureContentBackend		cairo
AzureFallbackCanvasBackend	none
AzureSkiaAccelerated		0
Thanks Anthony for your feedback.
I reproduce this behavior on two different computers (a desktop and a laptop). Both under Ubuntu 14.04.1 (amd64 version). Both use an Intel graphics card, with the kernel built-in open-source drivers.

Graphics section of "about:support" for the desktop one :
Description de la carte: Intel Open Source Technology Center -- Mesa DRI Intel(R) Ivybridge Desktop
Fenêtres avec accélération graphique: 0/4 Basic
ID du périphérique: Mesa DRI Intel(R) Ivybridge Desktop
ID du vendeur: Intel Open Source Technology Center
Rendu WebGL: Intel Open Source Technology Center -- Mesa DRI Intel(R) Ivybridge Desktop
Version du pilote: 3.0 Mesa 10.1.3
windowLayerManagerRemote: false
AzureCanvasBackend: cairo
AzureContentBackend: cairo
AzureFallbackCanvasBackend: none
AzureSkiaAccelerated: 0

And for the laptop :
Description de la carte: Intel Open Source Technology Center -- Mesa DRI Intel(R) IGD
Fenêtres avec accélération graphique: 0/1 Basic Bloqué pour votre carte graphique à cause de problèmes non résolus du pilote.
ID du périphérique: Mesa DRI Intel(R) IGD
ID du vendeur: Intel Open Source Technology Center
Rendu WebGL: Bloqué pour votre carte graphique à cause de problèmes non résolus du pilote.
Version du pilote: 1.4 Mesa 10.1.3
windowLayerManagerRemote: false
AzureCanvasBackend: cairo
AzureContentBackend: cairo
AzureFallbackCanvasBackend: none
AzureSkiaAccelerated: 0

I tested with the ubuntu package of firefox 31, but also with firefox 31 downloaded from mozilla, and with the nightly version on the desktop, with all addons disabled : same behavior (around twice more CPU used by Firefox than by Totem).

A compositing overhead might be the reason, as I'm currently using Unity desktop manager. But it's really the process "firefox" that eats twice more CPU than the process "totem". I suppose the compositing would eat some CPU on another process (like compiz), but I might be wrong?
Should I test with another desktop manager? (with a live CD of another distrib, for example)

In any case, I agree with you that this should not draw any conclusion for other platforms. I generalized the issue a bit too fast ;-)
Regarding bug 1063356, it's good that some improvements are on their way. But I really would like to understand why I see a performance gap between firefox and totem, and you don't.

Do you see other tests that I could run to figure out?
Status: UNCONFIRMED → NEW
Ever confirmed: true
I just tested with xubuntu 14.04.1 (with or without display compositing enabled) and lubuntu 14.04.1, on the desktop PC.

Same result : around twice the CPU consumption for Firefox than any GStreamer-based player (Totem or Parole), or avplay, mplayer or xine.

So I don't think that this comes from a compositing overhead.

Could it come from an optimization (like using some CPU/GPU instructions or not) that would be enabled in gstreamer/libav/etc, but not in Firefox (at least on my hardware)?

I found in https://hg.mozilla.org/mozilla-central/file/6a63bcb6e0d3/media/libvpx/moz.build that there are at least a few of them (sse2, ssse3, sse4.1, avx2).
I can confirm this bug under Windows using Videolan:

1. get Videolan from http://www.videolan.org

2. playback a WebM video (at best 720p or higher) with Videolan and Firefox

result: Firefox produces about double the CPU-load than Videolan does

Sadly the Adobe Flash Player also produces around double the CPU-load than Videolan does, so using Flash instead for video playback is no solution. Since I am using an older AMD64 single core this results in 1080p videos stuttering heavily during playback in Firefox.

As a temporary fix you can use a video download helper addon and playback web videos outside of Firefox using Videolan but I would really appreciate it if Firefox itself would be able to playback them as efficient as Videolan does.
I would also like to add that I am not using any kind of GPU-acceleration (neither in Videolan nor in Firefox). Maybe this made the difference in Anthony Jones test.
The issue isn't compiz. We decode the video in software which appears to happen at roughly the same speed between Totem and Firefox (for me, at least). However internally in Firefox we composite the video with all the other imagery contained in the Firefox window. I understand (I don't work in graphics) that this is being done using the CPU on Linux at this point.
(In reply to Anthony Jones (:kentuckyfriedtakahe, :k17e) from comment #9)
> However internally in Firefox we composite the video with all the
> other imagery contained in the Firefox window. I understand (I don't work in
> graphics) that this is being done using the CPU on Linux at this point.

So the problem is not the actual decoding process but the Firefox window itself that is adding the additional ~100% CPU load to the process? (This would also explain why Flash is equally slow.)
(In reply to Cresto from comment #10)
> So the problem is not the actual decoding process but the Firefox window
> itself that is adding the additional ~100% CPU load to the process? (This
> would also explain why Flash is equally slow.)

I am not so keen about this theory anymore. Videolan also installs a Firefox Plugin (called "VLC Web Plugin 2.1.3.0") which allows you to playback MP4 videos directly inside of Firefox.

Now I renamed my WebM video file from ".webm" to ".mp4" and this way tricked Firefox into playing it back using the VLC Plugin and - tada - only half the CPU usage while the file is still played back inside the Firefox window.

I also noticed the problem gets worse with Firefox if you switch into full screen video mode (the VLC plugin on the other side doesn't care if you are using full screen mode or not).
(In reply to Cresto from comment #11)
> Now I renamed my WebM video file from ".webm" to ".mp4" and this way tricked
> Firefox into playing it back using the VLC Plugin and - tada - only half the
> CPU usage while the file is still played back inside the Firefox window.

PS: Another way to playback WebM files inside Firefox using the VLC plugin is to go to "about:config" and then set "media.webm.enabled" to "false" before opening the file with Firefox.

Sadly this is only working with offline files since websites like youtube now won't serve you any WebM videos at all.
Forgot to mention: if you want to use the MP4 renaming trick to playback WebM files with the VLC plugin you have to set "media.windows-media-foundation.enabled" to "false" first.
(In reply to Cresto from comment #11)
> Now I renamed my WebM video file from ".webm" to ".mp4" and this way tricked
> Firefox into playing it back using the VLC Plugin and - tada - only half the
> CPU usage while the file is still played back inside the Firefox window.

Easy explanation: Decoding happens in another process than Firefox. Maybe also compositing the video: I think that the rectangle the plugin controls is also graphically separated from Firefox (otherwise Flash-/Silverlight-DRM would not work at all). But a graphics guy can answer that.

> I also noticed the problem gets worse with Firefox if you switch into full
> screen video mode (the VLC plugin on the other side doesn't care if you are
> using full screen mode or not).

More pixels, more CPU. The VLC plugin could also use GPU acceleration or specialized decoder routines in the CPU which reduces the impact on CPU usage.
(In reply to Anthony Jones (:kentuckyfriedtakahe, :k17e) from comment #9)
> The issue isn't compiz. We decode the video in software which appears to
> happen at roughly the same speed between Totem and Firefox (for me, at
> least). However internally in Firefox we composite the video with all the
> other imagery contained in the Firefox window. I understand (I don't work in
> graphics) that this is being done using the CPU on Linux at this point.

Anthony, what can I do to help investigate this issue?
If I understood correctly, you think it might come from the internal compositing of Firefox? Because it might be done by CPU in some cases, instead of GPU?
(In reply to Mossroy from comment #15)
> Anthony, what can I do to help investigate this issue?

It doesn't look like a video decoding issue. I get similar results on Intel graphics mode on my Optimus but not on nVidia mode.

> If I understood correctly, you think it might come from the internal
> compositing of Firefox? Because it might be done by CPU in some cases,
> instead of GPU?

That appears to be the case. I'll let Milan comment on it further.
Flags: needinfo?(milan)
Any change if you set layers.acceleration.force-enabled to true?
Flags: needinfo?(milan)
(In reply to Milan Sreckovic [:milan] (PTO 10/16-10/17) from comment #17)
> Any change if you set layers.acceleration.force-enabled to true?

At first not, but after I restarted Firefox the effect kicked in and the CPU-load was indeed reduced significantly (almost the same as VLC)! So, thanks for the info!

Although it only affected Webm videos not Flash (the bad Flash performance seems to be an Adobe problem - but luckily Flash is a dying technology).

Why is this effect not enabled by default?? (It should really be!)
(In reply to Milan Sreckovic [:milan] (PTO 10/16-10/17) from comment #17)
> Any change if you set layers.acceleration.force-enabled to true?

Unfortunately not on my computers. Even after restarting Firefox (or the computer).

Both computers have an Intel integrated graphics card, and run Ubuntu 14.04 (64-bit version).
Cresto, could you please post here the Graphics section of your about:support?

Milan, I saw many other layers.* parameters in about:config : should I test some of them?
Is there anything else I could do to help?
(In reply to Mossroy from comment #19)
> (In reply to Milan Sreckovic [:milan] (PTO 10/16-10/17) from comment #17)
> > Any change if you set layers.acceleration.force-enabled to true?
> 
> Unfortunately not on my computers. Even after restarting Firefox (or the
> computer).
> 
> Both computers have an Intel integrated graphics card, and run Ubuntu 14.04
> (64-bit version).
> Cresto, could you please post here the Graphics section of your
> about:support?

On Lubuntu Linux (and layers.acceleration.force-enabled = true):

Adapter Description	nouveau -- Gallium 0.4 on NV47
Device ID	Gallium 0.4 on NV47
Driver Version	2.1 Mesa 10.1.0-rc1
GPU Accelerated Windows	1/1 OpenGL
Vendor ID	nouveau
WebGL Renderer	nouveau -- Gallium 0.4 on NV47
windowLayerManagerRemote	false
AzureCanvasBackend	cairo
AzureContentBackend	none
AzureFallbackCanvasBackend	none
AzureSkiaAccelerated	0

As soon as I enable "layers.acceleration.force-enabled" and restart Firefox the line "GPU Accelerated Windows" changes from "0/1 Basic" to "1/1 OpenGL" and WebM HD videos then just consume half the CPU power.

As for Windows it seems my problem only was an outdated GPU driver and "GPU Accelerated Windows" is now set to "1/1 Direct3D" there by default, solving the CPU problem of WebM. :)
It seems to me this bug is basically a variation of "[Linux] Turn on OpenGL accelerated layers by default for at least some subset of hardware":

https://bugzilla.mozilla.org/show_bug.cgi?id=594876

One of the users there also states forced acceleration is working fine for him with Ivybridge and Ubuntu 12.10.
Right; you would expect less CPU once we start using GPU for composition; without the acceleration, the composition is on CPU, so I would expect those kinds of results, and they're inline with what Anthony was guessing.  As for enabling this by default, yes, there are the dependent bugs from bug 594876, some of them crashes, so we're not quite there.
I don't manage to enable GPU accelerated windows on my computers : about:support always displays O accelerated windows.
I tried layers.acceleration.force-enabled=true with or without gfx.xrender.enabled=false. With a Firefox restart each time.
On both computers, it has no effect on about:support accelerated windows, and no effect on CPU consumption.

Is there a way to enable accelerated windows on Intel graphics cards on Linux?
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → DUPLICATE
Summary: Decoding WebM (VP8 or VP9) uses twice more CPU than Totem → Decoding WebM (VP8 or VP9) uses twice more CPU than Totem on some hardware, probably because of lack of hardware acceleration for Firefox composition
You need to log in before you can comment on or make changes to this bug.