Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:85.0) Gecko/20100101 Firefox/85.0 ID:20201211093444

Opening https://www.jabra.com.de/bluetooth-headsets/jabra-elite-85t##100-99190000-60 and leaving it as a background tab the CPU load for the web content process stays at around 15 - 20%.

This kinda drains the battery of the my MacBook unnecessarily. What's strange, when I try to get a Gecko profile there is nothing displayed for this particular tab. Only about:processes also lists the high CPU load. Something wrong with the profiler or why do we have that high CPU load.

https://share.firefox.dev/3a7EWmO
MediaDecoderStateMachine thread is at least a bit busy

This seems indeed to be related to the Video banner with the CSS class name video-banner__video. Aren't we stopping those videos when the tab is in background or Firefox even minimized / hidden? Paul, do you know?

We do, the threshold is set to 10 seconds by default. It must be broken, I just did a profile of more than 10s myself, and I see things happening. Bryce, do you confirm we still have the decoder suspend thing? Is this something you expect?

Same also happens when I hide Firefox with Cmd+H on MacOS. Using Safari the web content process only uses around 0.3% of CPU after some seconds.

We should indeed suspend and I think Alastor may be more familiar with the machinery than I. Alastor, could you take a look at this?

Holding my NI to remind me to check in.

I can reproduce this issue on both Ubuntu 20.04 and MacOS 10.15. We do suspend the video decoding when the tab goes to background, as Paul said, our default value for suspending video decoder after tab goes to background is 10.

I did see suspending video decoding reducing the CPU usage, the CPU usage, however, is still not as low as our expectation. If we enable blocking autoplay for both audio and video, then the CPU usage would be really low when tab is in background. But once the video on the page, which is inaudible and used as a background image, starts, then the CPU usage would go way higher than without video.

I will check what happened.

Quick update : what I observed so far is that (1) this site contains some inaudible videos which all contain a silenece audio track, so we're still keeping decoding audio and enable the audio tracks, which indeed causes extra power consumption. (2) From the log, I see some videos are suspended correctly, but some are not, not sure what happened, will continute to investigate that.

This issue actually requires more works than I thought, I will describe what happens.

Tl;dr, (1) we should improve our mechanism of suspending video decoder and (2) consider to suspend audio decoder for inaudible audio track

We would suspend the video decoding when the element becomes ApproximatelyNonVisible, which is not simply equal its actual visible state. If a video is invisible, but is close to the area of visible viewport, it would not be regarded as ApproximatelyNonVisible.

In addition, due to the change in bug1346116, not-in-tree media element won't be suspended as well.

In jabra page, once you finish loading and don't block any autoplay inaudible media, then they start running 9 video at the same time, and some of them are not in tree. Therefore, even if the tab is in the background, we would still keep decoding those not-in-tree videos.

As our mechanism for suspending video decoder is simply creating a blank decoder, but we would still run other relevant tasks in the media pipeline. Eg. running demuxing tasks, MDSM tasks, MRF tasks, video sink tasks. In order to reduce the CPU and battery usage further more, I think we can improve our mechanism by stopping doing some of those tasks as well.

Also, the videos jabra plays are all inaudible video, but they all contains an inaudible audio track, which results in creating corresponding audio stream resources and runing demuxing and decoding tasks all the times for those inaudible tracks. That is totally a waste.

Therefore, there are many different small problems we can solve part-by-part. It's not easy to solve them all at a time because of the problem scale.

Alastor, shall we make this bug a meta bug, maybe with a better description? Then we could file all the individual issues as separate bugs, and prioritize appropriately?

For video part, we can use bug1352007, which is the original meta bug for implementing shutdown video decoders, to track all following improvement.

For audio part, the possible improvement is to suspend or stop cubeb stream for inaudible audio track. I know that paul has mentioned that plan before, but I don't know what the status is and if we have a corresponding metabug.

No clear plan of action just now, but I'm going to look. We need to re-do some telemetry to do this (to understand how fast audio stream creation/init is), and unfortunately re-do how we do telemetry, but I'm on it.

From bug1721969, this site [1] also causes a performance problem on some computers if users don't block the autoplay.

[1] https://www.steamdeck.com/en/hardware

(In reply to Paul Adenot (:padenot) from comment #11)

No clear plan of action just now, but I'm going to look. We need to re-do some telemetry to do this (to understand how fast audio stream creation/init is), and unfortunately re-do how we do telemetry, but I'm on it.

Is there a plan now, or a bug this should be linked to? I think you made a lot of progress on telemetry since you wrote this comment.

Just added a related bug that's almost finished, but this wil need more than one set of fixes.

Hi Paul, the CPU load for this website looks much better now when being in a background tab. But I can still see a CPU load of about 6% for the related WebContent process. Most seems to come from various MediaSupervisor threads and around 1.4% still from the MediaDecoderState.

Maybe this question should not have gone to Paul but probably Alastor.

Are you able to take a profile so we can see what's up? Media preset please.

I hope this profile contains all what you need: https://share.firefox.dev/3NGe5PY

After 3s I switched to a different tab and left the Jabra tab in the background.

Perfect yes, we see that the suspension isn't kicking in. Maybe because it's short and looping or something? Alastor do you know?

Yes I did see that in comment7, and I found out that our shutdown-decoder mechanism is still incomplete, we haven't even finish the phase 2 since 2018 (you can see code here). We still need to find time to fix that in order to perfectly shutdown video decoding for all invisible videos.

In addition, in comment8, I also proposed that we could probably stop more tasks when we already shutdown the video decoder. Maybe we could even ask MDSM or MFT to stop requesting video data completely?