Closed Bug 1235875 Opened 8 years ago Closed 8 years ago

No H.264 Hardware acceleration on MacBook Pro 15 inch Mid 2014 version during YouTube HTML5 playback

Categories

(Core :: Audio/Video: Playback, defect, P2)

Product:
Core
Component:
Audio/Video: Playback
Version:
43 Branch
Platform:
x86_64
macOS
Type:
defect

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1212323

People

(Reporter: windward400-1, Unassigned)

Details

Attachments

(3 files)

Firefox Telemetry.txt
4.37 KB, text/plain
Details
Youtube Perf Profile.json.zip
871.22 KB, application/zip
Details
Firefox Debug Log 2016 01 07.txt
273.50 KB, text/plain
Details
Attached file Firefox Telemetry.txt — 
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:43.0) Gecko/20100101 Firefox/43.0
Build ID: 20151223140742

Steps to reproduce:

Refreshed Firefox 43.0.3, run in safe mode, and about:support shows no H.264 hardware acceleration.

This is on Mid-2014 MacBook Pro which DOES offer HW acceleration for H.264.


Actual results:

When playing HTML5 YouTube videos: No H.264 HW decoding support, disgustingly high battery usage, CPU runs very hot, and CPU fan is always on.


Expected results:

Running the same HTML5 video in Safari results in 6x less CPU utilization, much longer battery life, and CPU stays cool to touch, CPU fan doesn't come on.
Severity: normal → major
OS: Unspecified → Mac OS X
Priority: -- → P1
Hardware: Unspecified → x86_64
about:support shows no H.264 hardware acceleration on OS X regardless of the actual status. See bug 1235912.
Component: Untriaged → Audio/Video: Playback
Product: Firefox → Core
As Jeff wrote, about:support doesn't show the right information. 

H264 HW acceleration is always used on YouTube unless the OS decides not to (this is not something we control, the VideoToolbox framework does that: which is also what Safari is using). The only exception to this is if the user disabled hw acceleration in the preferences. 

I would close this bug as invalid, on the suspicion that the incorrect information in about:support lead to incorrect conclusions.
When you right click on the playback window and select Stats for Nerds: what does it show?
Severity: major → normal
Priority: P1 → --
(In reply to Jean-Yves Avenard [:jya] from comment #4)
> When you right click on the playback window and select Stats for Nerds: what
> does it show?

Hi Jean, thank you for the reply.  Here are stats for nerds:
Volume:
100%
Stream Host:
r2---sn-vgqs7nls
Stream Type:
https
CPN:
e0tBuHfRP8trEba4
Mime Type:
video/mp4; codecs="avc1.4d4015"
DASH:
yes (134/140)
Connection Speed:
2596 Kbps
Dropped Frames:
0/445


The CPU utilization difference between Safari and Firefox is massive, so seems like VideoToolBox picks software decoding in Firefox.
You left off the resolutions from that screen. There are two showing.
And please provide here the output of about:support
(In reply to Jean-Yves Avenard [:jya] from comment #6)
> You left off the resolutions from that screen. There are two showing.

Hi Jean, the resolution was 1920x1080.  I am pasting another stats for nerds from fullscreen video:
Video ID:
LbiIu_EzuWk
Dimensions:
1920 x 1080 * 2
Resolution:
1920 x 1080@24
Volume:
100%
Stream Host:
r10---sn-5uaeznz7
Stream Type:
https
CPN:
Va0JOgHc74P_wtPN
Mime Type:
video/mp4; codecs="avc1.640028"
DASH:
yes (137/140)
Connection Speed:
14334 Kbps
Dropped Frames:
0/502



I have attached raw output from about:support along with the initial bug report in "Firefox Telemetry.txt" file.
If you can provide a profile of the Firefox process using Instruments while a video is playing that should let us confirm whether software decoding is being used or there's a bottleneck someplace else.
Flags: needinfo?(windward400-1)
(In reply to Jeff Muizelaar [:jrmuizel] from comment #9)
> If you can provide a profile of the Firefox process using Instruments while
> a video is playing that should let us confirm whether software decoding is
> being used or there's a bottleneck someplace else.

Hi Jeff, if you send me instructions on how to profile using instruments, I am happy to send it in.  In the meantime, I made a performance profile using Developer Tools using following steps:
1) Open YouTube channel page 
2) Start performance profile recording
3) Click video
4) Let the 1080p mp4 video play fullscreen for 10 seconds
5) Stop performance profile 

I am attaching the "YouTube Perf profile.json" file above with the bug report.
Flags: needinfo?(windward400-1)
YouTube performance profile created using built in profiler for Web Developer tools
If you download and run a debug build from here:
http://archive.mozilla.org/pub/firefox/tinderbox-builds/mozilla-release-macosx64-debug/1451943690/firefox-43.0.3.en-US.mac64.dmg

Then run it as follow:
1- Open the dmg so it gets mounted.
2- Open a terminal (in the finder press Command-Shit-U and select Terminal.app)
3- At the prompt, type: NSPR_LOG_MODULES=PlatformDecoderModule:5 /Volumes/Nightly/NightlyDebug.app/Contents/MacOS/firefox-bin
4- Open a YouTube video, or any h264 videos.

In the terminal console, you will have a lot of output, search for lines containing something like:
87109632[1fa79d420]: Creating AppleVTDecoder for 640x480 h.264 video
87109632[1fa79d420]: AppleVTDecoder: using hardware accelerated decoding

or:
87109632[1fa79d420]: AppleVTDecoder: not using hardware accelerated decoding

If your system doesn't support hardware acceleration (very few recent macs, AFAIK, only the late-2013 mac pro doesn't), you'll see something like:
87109632[1fa79d420]: AppleVTDecoder: system doesn't support hardware acceleration
(In reply to Jean-Yves Avenard [:jya] from comment #12)
> If you download and run a debug build from here:
> http://archive.mozilla.org/pub/firefox/tinderbox-builds/mozilla-release-
> macosx64-debug/1451943690/firefox-43.0.3.en-US.mac64.dmg

Thank you for the instructions Jean.  I have followed the steps you outlined and fired up Firefox nightly in private mode to open a YouTube video.  I captured the full debug log and attaching it here for your reference.

Looks like AppleVTDecoder is using Hardware decoding.  However, CPU utilization remains a huge issue.  For this playback test Firefox CPU utilization was at 35%-40% throughout the fullscreen 1080p playback, while Safari fullscreen CPU utilization was 6% for the same video.  

Do you see anything off in the debug log?

Thanks!
Firefox is burning 600% more CPU compared to Safari for all YouTube videos.  Do any of the devs see anything wonky in the attached debug log?
PS: I just tried running the debug nightly in private + safe mode, which makes the video choppy with massive dropped frames but CPU utilization still remains high at 35%.  So add-ons do not seem to be the culprit here.
(In reply to Windward from comment #13)
> (In reply to Jean-Yves Avenard [:jya] from comment #12)
> > If you download and run a debug build from here:
> > http://archive.mozilla.org/pub/firefox/tinderbox-builds/mozilla-release-
> > macosx64-debug/1451943690/firefox-43.0.3.en-US.mac64.dmg
> 
> Thank you for the instructions Jean.  I have followed the steps you outlined
> and fired up Firefox nightly in private mode to open a YouTube video.  I
> captured the full debug log and attaching it here for your reference.
> 
> Looks like AppleVTDecoder is using Hardware decoding.  However, CPU
> utilization remains a huge issue.  For this playback test Firefox CPU
> utilization was at 35%-40% throughout the fullscreen 1080p playback, while
> Safari fullscreen CPU utilization was 6% for the same video.  

A debug build will always *significantly* more CPU than a release build. 
The purpose was really to see if there was anything related to your config that somehow HW decoding wasn't available.

But that's not the case, you do have HW decoding enabled.

35-40% in a debug build playing video isn't anything abnormal. You can divide that by 3 or 4 easily to compare with a release and optimised build.

What you could be seeing however is bug 1231564.
(In reply to Windward from comment #15)
> PS: I just tried running the debug nightly in private + safe mode, which
> makes the video choppy with massive dropped frames but CPU utilization still
> remains high at 35%.  So add-ons do not seem to be the culprit here.

You mentioned 600% before, and now 35.

If you enable debugging log, being very verbose, you will see high CPU usage.

I recommend that you redirect the log to a file:
add "NSPR_LOG_FILE=~/fflog.txt" before NSPR_LOG_MODULES
(In reply to Jean-Yves Avenard [:jya] from comment #17)
> (In reply to Windward from comment #15)
> > PS: I just tried running the debug nightly in private + safe mode, which
> > makes the video choppy with massive dropped frames but CPU utilization still
> > remains high at 35%.  So add-ons do not seem to be the culprit here.
> 
> You mentioned 600% before, and now 35.
> 
> If you enable debugging log, being very verbose, you will see high CPU usage.
> 
> I recommend that you redirect the log to a file:
> add "NSPR_LOG_FILE=~/fflog.txt" before NSPR_LOG_MODULES


Hi Jean,

Sorry for the confusion.  To clarify, 600% is the difference between Firefox vs Safari CPU utilization (35% vs 4%) when running fullscreen videos.   

For my normal use, I run the release build 43.0.3 and I still see the same CPU utilization and rapid degradation of battery life compared to Safari.  I really want to use Firefox but this huge discrepancy in efficiency is really making it hard for me.
Is there anyway I can generate a performance log to help the devs in diagnosing the cause of inefficiency?
There is no doubt that Safari is more efficient energy wise. But we're working really hard to iron out those differences.
They do have an edge over us being that they control their hardware and inner APIs, so they know what to do.
Their VideoToolbox framework has almost zero documentation, we had to implement everything simply by looking at the headers found in the framework folder (found in /Library); there's no official documentation of any kind.

Despite all that and our limited resources (compare to Apple or Google), we are performing better than Chrome. That got to count for something :)

In the mean time, try a nightly build, you may find that it's performing better.
(In reply to Windward from comment #19)
> Is there anyway I can generate a performance log to help the devs in
> diagnosing the cause of inefficiency?

yes, download XCode from the App Store and use the Instruments to record a profiler session.
In Xcode, in the top left corner select Open Developer Tool -> Instruments select "Time Profiler". From there attach the process. Start youtube  when the video is done, save and post that here.
Priority: -- → P2
Another Mac User. Mid 2012 MacBook Pro Retina here. OS 10.10.5 I have the same problem.
I'm running FF 46.0.1. about:support says hardware-decoding not enabled. 
Nightly and Dev say otherwise but display the same behaviour cpu-usage wise.
Status: UNCONFIRMED → RESOLVED
Closed: 8 years ago
Resolution: --- → DUPLICATE
(In reply to Jean-Yves Avenard [:jya] from comment #24)
> 
> *** This bug has been marked as a duplicate of bug 1212323 ***

Nope. This is no duplicate. The problem with FF not viewing the HW-Decoding enabled option correctly and FF not using it correctly are two different problems. It is shown correctly in Nightly but even Nightly is still using way to much CPU.
then open a new bug.. because HW acceleration is used; and this bug is about HW not being used
And BTW, if you right click in YouTube and select "Stats for nerds" you'll find that it's using VP9 which is software only.
(In reply to Jean-Yves Avenard [:jya] from comment #27)
> And BTW, if you right click in YouTube and select "Stats for nerds" you'll
> find that it's using VP9 which is software only.

okay. then I'll open a new bug. But VP9 is NOT used. I've taken care of that. (h264ify Extension and media.mediasources.webm = false in about:config)
What does "stats for nerds show"? Setting media.mediasource.webm.enabled to false is no guarantee that you won't be served vp9.

In 48 and later, if your machine is fast enough to decode vp9; it may receive vp9; and all recent macs are fast enough.
(In reply to Jean-Yves Avenard [:jya] from comment #29)
> What does "stats for nerds show"? Setting media.mediasource.webm.enabled to
> false is no guarantee that you won't be served vp9.
> 
> In 48 and later, if your machine is fast enough to decode vp9; it may
> receive vp9; and all recent macs are fast enough.

It does say mp4.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: