Confirmed users
811
edits
Firefox/Shutdown Decoders: Difference between revisions
→Team
Joshwalker (talk | contribs) |
Joshwalker (talk | contribs) (→Team) |
||
| Line 117: | Line 117: | ||
QA: SoftVision and William | QA: SoftVision and William | ||
=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. | |||
''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()] | |||