[meta] High power consumption when using the HTML5 player on Youtube.

NEW
Unassigned

Status

()

Core
Audio/Video: Playback
4 years ago
4 months ago

People

(Reporter: rvitillo, Unassigned)

Tracking

(Depends on: 2 bugs, {power})

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [Power:meta] [platform-rel-Youtube])

Attachments

(2 attachments)

Created attachment 8374452 [details]
Power consumption on Linux

Firefox seems to consume significantly more power than Chrome and Safari when playing a video (fullscreen) with the HTML5 player on Youtube.
(Reporter)

Comment 1

4 years ago
Created attachment 8374456 [details]
Power consumption on OSX
Yikes! Client storage could avoid some copies here. I don't have a bug to track this sadly.
(Reporter)

Comment 3

4 years ago
The same thing happens on Windows. Compared to IE which does the best job in terms of energy consumption, we do about 3x more context switches from idle and consume about 2 to 3 times more CPU.
Bug 778947 seems a one bug to reduce the copy.
n-i for Milan to assign someone after March 17th
Flags: needinfo?(milan)
Anthony, could one of your guys take a look at this first?
Flags: needinfo?(ajones)
You need to consider which codec is being used in each test. VP9 is a software decoder but gets better compression so it doesn't make sense to compare it directly against H.264. You also need to ensure that we're comparing the non-adaptive playback in both cases. The graphs are not useful to draw any conclusion without documenting the experimental details.

Our tests showed that Firefox uses less CPU and less power than Internet Explorer on the Microsoft Surface when decoding H.264. While these tests were done at the end of Q2 last year, I'm surprised by your result. In a spike test with one less copy we didn't see a significant change in power consumption. We have not done a comparison between H.264 and VP9 for power consumption.

We support VP9 on all platforms. We support hardware accelerated H.264 on Windows Vista, 7 and 8. We support software H.264 decoding on Linux. Mac OSX and Windows XP do not play H.264. Internet Explorer and Safari do not support VP9.

Roberto - Can you provide details about which codecs are being used and whether you are testing with adaptive streaming?
Flags: needinfo?(ajones) → needinfo?(rvitillo)
(Reporter)

Comment 8

4 years ago
Windows:
FF: avc1.42001E
IE: avc1.4d401e

OSX:
FF: vp8.0
Chrome: vp9.0
Safari: avc1.64001F

Linux:
FF: avc1.42001E
Chrome: avc1.4d401e

In all tests I set the resolution to 720p. Do you have a suggestion on how to force non-adaptive playback on youtube? The youtube center script that allows to disable DASH doesn’t seem to work properly with the latest IE version.
Flags: needinfo?(rvitillo)
From what you have told me on Windows we're using more CPU but you haven't said we're using significantly more power. I will therefore assume that hardware decoding is working on both IE and FF so the current situation is adequate. The extra copy won't make a difference to CPU usage. Some of the changes that we're working on this year may improve the CPU usage a little.

We currently don't support hardware decoding on Linux or OSX. Hardware decoding will make the biggest difference to power consumption. This will happen later in the year. I've added 'optimising the power usage' to the 2015 backlog.
One more note from Anthony:
--------------
It would be nice to eliminate the extra copies but I don't expect it
will make a difference to the power consumption. Most of the power is
used in decoding. We tested this on the Microsoft Surface and we didn't
see a noticeable difference. If you want to repeat the experiment then
comment out the additional copy. The video won't display but it will
show you what the power would be like.
--------------
Sounds like the most traction on this bug would be from the video side to start.  Changing the component to reflect that.
Component: Graphics → Video/Audio
Flags: needinfo?(milan)
(In reply to Anthony Jones (:kentuckyfriedtakahe, :k17e) from comment #9)
> From what you have told me on Windows we're using more CPU but you haven't
> said we're using significantly more power. I will therefore assume that
> hardware decoding is working on both IE and FF so the current situation is
> adequate. The extra copy won't make a difference to CPU usage. Some of the
> changes that we're working on this year may improve the CPU usage a little.

Maybe it wasn't clear but in comment 3 I meant that besides using more power, we use also more CPU time. Leaving CPU time aside and looking only at the power consumption this is what I got: about 2x times more power for the GPU and about 3x times more power for the CPU cores and about 50% more power for the whole package wrt to IE. Measurements have been taken with Intel's Power Gadget.
Duplicate of this bug: 984885
Whiteboard: [Power]
Component: Audio/Video → Audio/Video: Playback
I did some codec testing recently on mobile [1] and found that the HW vs SW overall power consumption difference is less than 10%. An equally large or larger factor is what resolution Youtube selects, so it's very important to normalize this. Regardless, if we have a huge power discrepancy, it's likely do to something else in the stack.
Forgot link. Also I should note that I haven't been able to get sufficiently noise free results on a laptop yet, which I see the original recordings are for.

[1] https://people.xiph.org/~tdaede/power/
Given that the details can vary greatly between platforms, let's make this a meta-bug. I've marked bug 1195790 (specifically about OS X) as blocking this. Please file other blocking per-platform bugs as appropriate.
Summary: High power consumption when using the HTML5 player on Youtube. → [meta] High power consumption when using the HTML5 player on Youtube.
Whiteboard: [Power] → [Power:meta]

Updated

2 years ago
Depends on: 1195790

Updated

2 years ago
platform-rel: --- → ?

Updated

2 years ago
Whiteboard: [Power:meta] → [Power:meta] [platform-rel-Youtube]

Updated

2 years ago
Depends on: 1277120
platform-rel: ? → ---
You need to log in before you can comment on or make changes to this bug.