Non-starting video makes for constant CPU usage after autoplay has been disabled




2 years ago
2 years ago


(Reporter: mirh, Unassigned)




Firefox Tracking Flags

(Not tracked)




(1 attachment)

2.22 KB, text/plain
Assuming I shouldn't instead open a bug report because the video isn't playing in the first place (with media.autoplay.enabled=false).. 
I get constant 20-30% cpu usage, even though content never starts -

Moreover, once I have installed profiler Firefox seems to hang every now and then while browsing the website, but I couldn't reliably reproduce this.
Component: Untriaged → Audio/Video: Playback
Product: Firefox → Core
Can you give the link that demonstrates the issue?
Flags: needinfo?(mirh)
It's in the details.
Flags: needinfo?(mirh)
I can't repro the issue on Linux.

Can you
1. set media.autoplay.enabled to true
2. press 'pause' after playback starts for a few seconds
3. observe the CPU usage?

Flags: needinfo?(mirh)
I'm on Windows by the way. 
Anyway, CPU usage quite rapidly disappears once I pause it in this scenario
Flags: needinfo?(mirh)
I cannot repro this issue on Windows Nightly, Beta, and Release. 

@mirh, can you still repro it on your side? 
If it is reproducible, could you please record the performance of "MediaPDecoder" and "MediaPlayback" threads? Also, could you please install the "about:media" add-on and report the information?

Flags: needinfo?(mirh)
Posted file about:media
Flags: needinfo?(mirh)
:mirh, thanks for recording the new profile, and I am sorry for my late response. 

I have a look into it today and here is an update.

1. Media related threads are not working at all. All 4 playback threads and 4 decoder threads are pending. From about:media, there's no decoder at all. 

2. The main thread of the content process, which loads the, is somewhat busing. However, we're not able to figure out what is it focusing on because the address-function-name-mapping fails on the provided profile (

A question, are you using Nightly? If not, could you try to reproduce it again on Nightly?
I was using latest nightly available on that day, yes.
Then, I have no idea why the address-function-name-mapping doesn't work......

:Blake, looks like the constant CPU usage does not come from media code (see comment 7). 
Could you please transfer this bug to a more generic component?
Flags: needinfo?(bwu)
Can someone from your team help us to narrow down which component is more suspicious?
Flags: needinfo?(bwu) → needinfo?(kchen)
The profile shows that the content process (1 of 2) keeps repainting, probably layout a more suitable component. But I can't reproduce this on my Windows 10 with Nightly 56.0a1 20170621102301, better make sure this is reproducible before diving in.
Flags: needinfo?(kchen)
This is a P1 bug without an assignee. 

P1 are bugs which are being worked on for the current release cycle/iteration/sprint. 

If the bug is not assigned by Monday, 28 August, the bug's priority will be reset to '--'.
Keywords: stale-bug
Mass change P1->P2 to align with new Mozilla triage process
Priority: P1 → P2
Ok, then.. 58b4 still kind of exhibit the problem (though 10-20 constant cpu usage now). 
Latest nightly on the other hand is more like 2-3%, which albeit pretty close 0.. I dunno, means something could still be done? Or perhaps that should be expected with the player doing something when attempting to start. 

So I thought to just lower severity of bug for now. 

Also, in the meantime, bug 1382574 seems about fixing the "doesn't play in the first place" issue.
Severity: normal → minor
You need to log in before you can comment on or make changes to this bug.