Mobile/Firefox for Android/shutdown decoder
Overview
Suspending video element's video decoder, when the video element is in background tabs or is invisible even in the foreground tab, is a Firefox feature that reduces CPU/GPU & memory usage.
The mechanism is that, when a video element is invisible, we replace its original video decoder with blank video decoder which only produces white frames with right resolution and right time information. The original video decoder is released and the black video decoder is light so that we reduce CPU/GPU & memory usage.
The drawback is that, while the suspended-video-element is switched back to be visible again, we should resume its original video decoder. The resuming operation must be asynchronous and might be time-consuming which depends on the resolution of the video file and whether it contains audio tracks or not.
In the prototype (Phase 0), we have enabled this feature on the Firefox Nightly channel for any video element. We also add telemetry to collect needed information, especially on the resuming time. Currently (Phase 1), we are going to enable this feature on the Firefox Release channel for videos that is able to be resumed quickly and the criteria is 1) videos without audio track or 2) videos with both audio and video tracks but with low resolution (480P for now). In the future (Phase 2), our goal is to enable this feature on all videos without observable latency while resuming.
The following is a step-by-step description of suspending decoder working flow.
- At the very beginning of the decoding framework, the raw media data is sent to demuxer.
- Demuxer helps to separate a combined signal, e.g., a streaming can be separated into audio data and video data by demuxer. After that, audio and video data are sent to audio and video decoder separately.
- In data decoding period, audio decoder keeps working as normal because a user may be listening to the music. But, Firefox uses a blank video decoder to replace current video decoder if the video element is invisible.
Overall Project Health
[GREEN] Phase 1: Using a blank video decoder to replace video decoder instead of shutdown decoders directly. In this phase, the mechanism is applied to 1) Low-resolution video (480P) and 2) Video film without audio track Phase 2: We're going to enhance the mechanism and make sure it can apply to all video files
Target Milestone
Firefox54 (Phase1)
Program MANA status Update
- RTL Mana Page : RTL Mana Page
Engineer Owner
Tzuhao Kuo [:kaku]
QA Contact
Ioana Chiorean <ioana.chiorean@softvision.ro>
Sorina Florean [:sorina] <sorina.florean@softvision.ro>
Status
Phases
Program Status
| Milestone | Target | Status |
|---|---|---|
| Phase 1 | 54 on Nightly | |
| Phase 2 | NOT STARTED |
- Phase 1: Using a blank video decoder to replace video decoder instead of shutdown decoders directly. In this phase, the mechanism is applied to 1) Low-resolution video (480P) and 2) Video film without audio track
- Phase 2: We're going to enhance the mechanism and make sure it can apply to all video files.
Testing
Test cases: Phase 1
MVP Phase1 Scope
- bug 1293963 -[Meta] Suspend-video-decoder: phase-1 shipping
17 Total; 1 Open (5.88%); 13 Resolved (76.47%); 3 Verified (17.65%);
Reference
Decoder resuming latency
While the suspended-video-element is switched back to be visible again, we should resume its original video decoder. The resuming operation must be asynchronous since we don't want to block the main thread and might be time-consuming which depends on the resolution of the video file and whether it contains audio tracks or not.
Currently, we have no way to boost the resuming time, however, we have telemetries for collecting the needed time of different resolutions on different platforms.