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 - https://perfht.ml/2pPjCcG 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.
Can you give the link that demonstrates the issue?
It's in the details.
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? Thanks!
I'm on Windows by the way. Anyway, CPU usage quite rapidly disappears once I pause it in this scenario
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? Thanks.
: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 https://video.vice.com/, 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 (https://perfht.ml/2qTcXOe). 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?
Kanru, Can someone from your team help us to narrow down which component is more suspicious?
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.
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 '--'.
Mass change P1->P2 to align with new Mozilla triage process