Firefox/Shutdown Decoders: Difference between revisions

Firefox/Shutdown Decoders (view source)

Revision as of 04:09, 22 August 2016

484 bytes added , 22 August 2016

no edit summary

Kakukogou

75

edits

@@ Line 1: / Line 1: @@
 =Overview=
-Suspending Video Decoders for Firefox is a feature that can reduce CPU & memory usage when a video runs in browser 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.
-In the prototype (Phase 0), we tried to shutdown video decoder while a video element is invisible. The mechanism can save the CPU & Memory usage but it's hard for Firefox to resume video after user goes back to previous web page which contains videos since video decoders has lost necessary information. Currently (Phase 1), we devoted ourselves to implementing this feature on '''1) video without audio track''' and '''2) low resolution video (480 P)''', and we added a new mechanism. The new mechanism is going to switch to another video decoder (we called blank decoder) while video element is invisible and continuously send white screen (empty data) to video player. In our target release (Phase 2), our goal is to enable this feature on all videos.
-The following is a step-by-step description of shutdown decoder working flow.
+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.
-# In the beginning of the decode framework, streaming or media file is going to be sent to demuxer if Firefox detects a media element.
-# 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 will be sent to audio and video decoder separately.
+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 data decoding period, audio decoder will works as normal because user may be listening to the music. But, Firefox uses a blank video decoder to replace current video decoder If Firefox detects a invisible video element.
+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 is sent to audio and video decoder separately.
+# In data decoding period, audio decoder keeps working as normal because 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.
 [[File:Fx_Shutdown_Decoder_Architecture.png|800px|frameless]]