Firefox/Block Playback: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
Line 10: Line 10:
* [https://goo.gl/0dylCY Meeting Minute]
* [https://goo.gl/0dylCY Meeting Minute]


=Known Issues=
''Related telemetries'':
* [https://telemetry.mozilla.org/new-pipeline/dist.html#!cumulative=0&end_date=2016-08-28&keys=All!AV%252C241-480!V%252C241-480!AV%252C481-720&max_channel_version=nightly%252F51&measure=VIDEO_SUSPEND_RECOVERY_TIME_MS&min_channel_version=null&product=Firefox&sanitize=1&sort_keys=submissions&start_date=2016-08-18&table=0&trim=1&use_submission_date=0 VIDEO_SUSPENDED_RECOVERY_TIME_MS]
''Related bugs'':
* [https://bugzil.la/1272919 Bug 1272919 - Video shows the frame that was on screen when I switched from youtube to a different tab for a fraction of a second]
===Video element as content source===
The situation is about the video element itself is used as a content source and its decoder might be suspended at the same time. This issue could be split into two cases:
* Case 1: The decoder is suspended '''AFTER''' the {cpatureStream(), drawImage(), createImageBitmap()} is called.
* Case 2: The decoder is suspended '''BEFORE''' the {cpatureStream(), drawImage(), createImageBitmap()} is called.
'''Case 1''' is relatively easy, we could mark the video element as being a content source while {cpatureStream(), drawImage(), createImageBitmap()} is invoked and then its decoder should never be suspended.
'''Case 2''' is rather complicated. The critical issue is that resuming decoder is an async operation with latency. So, while {cpatureStream(), drawImage(), createImageBitmap()} is invoked on an already-suspended-video, there must be several "blank" frames been leaked, even though we resume the decoder immediately. To completely solve this problem, we must make "resuming decoder" a blocking operation, however, it might block the main thread; otherwise, we leak the blank frames.
''Related bugs'':
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1284389 Bug 1284389 - Don't suspend video elements captured via mozCaptureStream()]
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1295921 Bug 1295921 - Don't suspend video decoder for elements as sources to drawImage() and createImageBitmap()]


=Planning=
=Planning=

Revision as of 07:05, 3 October 2016

Overview

Block Playback Video/Audio will be blocked if a new tab been opened but never bring to front.


Meta Bug

Other Resources


Planning

Goals

  • Help users to reduce device resource usage (CPU & Memory)
  • Finish tasks across videos
  • No impact on current user flow

Feature Plan

  • Phase 0: Shutdown decoders when video element is invisible
  • 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.

Success

  • Effective cross-discipline teams solving problems across platforms
  • Validation of key assumptions through telemetrics
  • video decode suspend in the hands of all our users

Schedule

Product Milestones

Engineering

Block Playback [status: Green]

Current Goals:

  • Ship disabling video decoders for ads
  • Silent, looping videos where user doesn't really care the exact point

Next Milestone:


Milestones

Optimizations

Telemetry

Mochitests

Team

Product owner:

Eng: Alastor, Daniel, Gerald, JW, Kaku,

Program Management: Blake, Josh

UX: Mark, Morpheus

QA: SoftVision and William

Communications

IRC:

Email:

VidyoRoom:

Retrieved from "https://wiki.mozilla.org/index.php?title=Firefox/Block_Playback&oldid=1149863"