Mobile/Firefox for Android/shutdown decoder: Difference between revisions
No edit summary |
|||
| Line 8: | Line 8: | ||
The trade-off is that, while the suspended-video-element is switched back to be visible again, we should resume its original video decoder. | The trade-off 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. | 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. | ||
== Working flow == | == Working flow == | ||
| Line 31: | Line 22: | ||
=Target Milestone= | =Target Milestone= | ||
Firefox55 | |||
=Engineer Owner= | =Engineer Owner= | ||
| Line 43: | Line 30: | ||
Ioana Chiorean <ioana.chiorean@softvision.ro><br> | Ioana Chiorean <ioana.chiorean@softvision.ro><br> | ||
Sorina Florean [:sorina] <sorina.florean@softvision.ro> | Sorina Florean [:sorina] <sorina.florean@softvision.ro> | ||
= MVP Scope-Bug Tracking = | = MVP Scope-Bug Tracking = | ||
Revision as of 04:01, 17 March 2017
Overview
Background
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.
Trade-off
The trade-off 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.
Working flow
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]
Target Milestone
Firefox55
Engineer Owner
Tzuhao Kuo [:kaku]
QA Contact
Ioana Chiorean <ioana.chiorean@softvision.ro>
Sorina Florean [:sorina] <sorina.florean@softvision.ro>
MVP Scope-Bug Tracking
- bug 1293963 -[Meta] Suspend-video-decoder: phase-1 shipping
17 Total; 1 Open (5.88%); 13 Resolved (76.47%); 3 Verified (17.65%);
12 Total; 1 Open (8.33%); 10 Resolved (83.33%); 1 Verified (8.33%);
UX Spec https://mozilla.invisionapp.com/share/K48PCVSEM
UX Spec
- UX Spec : UX Spec
others
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.