This issue acutlly 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](https://searchfox.org/mozilla-central/rev/8d722de75886d6bffc116772a1db8854e34ee6a7/layout/generic/Visibility.h#24-29), 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](https://www.jabra.com.de/bluetooth-headsets/jabra-elite-85t##100-99190000-60), 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 decode some of not-in-tree video. 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 the problem scale.
Bug 1682261 Comment 8 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
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](https://searchfox.org/mozilla-central/rev/8d722de75886d6bffc116772a1db8854e34ee6a7/layout/generic/Visibility.h#24-29), 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](https://www.jabra.com.de/bluetooth-headsets/jabra-elite-85t##100-99190000-60), 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 decode some of not-in-tree video. 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 the problem scale.
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](https://searchfox.org/mozilla-central/rev/8d722de75886d6bffc116772a1db8854e34ee6a7/layout/generic/Visibility.h#24-29), 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](https://www.jabra.com.de/bluetooth-headsets/jabra-elite-85t##100-99190000-60), 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 decode some of not-in-tree video. 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.
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](https://searchfox.org/mozilla-central/rev/8d722de75886d6bffc116772a1db8854e34ee6a7/layout/generic/Visibility.h#24-29), 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](https://www.jabra.com.de/bluetooth-headsets/jabra-elite-85t##100-99190000-60), 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.