Further note, this feature's shipping will entail switching two blink RuntimeEnabled features from experimental to stable simultaneously:
- MediaSourceInWorkers - MediaSourceInWorkersUsingHandle A CL [1] is already prepared to do this switch once this intent is approved. The plan is, once that CL has landed and baked in trunk, to request and merge it to the branch for M105. [1] https://chromium-review.googlesource.com/c/chromium/src/+/3781750 On Wed, Jul 27, 2022 at 12:06 PM Matthew Wolenetz <wolen...@chromium.org> wrote: > Contact emailswolen...@chromium.org > > Explainer > https://github.com/wicg/media-source/blob/mse-in-workers-using-handle/mse-in-workers-using-handle-explainer.md > > Specificationhttps://www.w3.org/TR/media-source-2 > > Design docs > > https://github.com/wicg/media-source/blob/mse-in-workers-using-handle/mse-in-workers-using-handle-explainer.md > https://goto.google.com/mse-in-workers > > Summary > > Enable Media Source Extensions (MSE) API usage from DedicatedWorker > contexts to enable improved performance of buffering media for playback by > an HTMLMediaElement on the main Window context. By creating a MediaSource > object on a DedicatedWorker context, an application may then obtain a > MediaSourceHandle from it and transfer that handle to the main thread for > use in attaching to an HTMLMediaElement. The context that created the > MediaSource object may then use it to buffer media. > > > Blink componentBlink>Media > <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EMedia> > > Search tagsMSE <https://chromestatus.com/features#tags:MSE>, MediaSource > <https://chromestatus.com/features#tags:MediaSource>, > MediaSourceExtensions > <https://chromestatus.com/features#tags:MediaSourceExtensions> > > TAG reviewhttps://github.com/w3ctag/design-reviews/issues/656 > > TAG review statusIssues addressed > > Link to origin trial feedback summary > https://github.com/w3c/media-source/issues/175#issuecomment-1045018594 > > Risks > > > Interoperability and Compatibility > > Main interoperability risk is that other browsers may not implement it. > Compatibility risk is mitigated by unchanged same-thread MSE API support > and proactive feature-detectability of MSE-in-Workers with a new > canConstructInDedicatedWorker attribute on the MediaSource interface. > > > *Gecko*: Positive ( > https://github.com/mozilla/standards-positions/issues/547) > > *WebKit*: No signal ( > https://lists.webkit.org/pipermail/webkit-dev/2021-June/031916.html) > @jernoble has been involved in feature specification discussions in the > Media Workgroup and has provided generally positive feedback. > > *Web developers*: Strongly positive ( > https://github.com/w3c/media-source/issues/175#issuecomment-1045018594) > Twitch reported "large positive impact on our topline metrics such as > buffering and time to video. We'd love for all browsers to adopt > MSE-in-Workers." More (positive) details have been shared and are currently > pending them posting them at a public location. > > *Other signals*: > > Ergonomics > > DedicatedWorker, WorkerGlobalScope and postMessage/onmessage availability > is integral to using this feature. > > > Activation > > The primary risk is the potential difficulty in refactoring existing MSE > web applications to (conditionally, depending on browser support) perform > buffering in a different execution context from the Window context that > hosts the DOM and the media element. The benefit of potentially improved > buffering performance by offloading the MSE API usage to a worker context > provides motivation to overcome this challenge. > > > Security > > Unpredictability of racing context destruction of either the main thread > hosting the media element (and owning the underlying MSE media demuxer and > player) or the dedicated worker thread hosting the interface to the MSE > demuxer when using MSE from a worker context motivated careful design of a > refcounted, outside-of-Oilpan, attachment abstraction to ensure safety of > operations using locks and having a lifetime that exceeds those execution > contexts. Preventing use-after-free and similar was a primary complexity of > implementation and a focus area of added tests. > > > WebView application risks > > Does this intent deprecate or change behavior of existing APIs, such that > it has potentially high risk for Android WebView-based applications? > > Not potentially high risk. > > > Debuggability > > Feature consists of exposing existing interfaces also on a > DedicatedWorker, and addition of a WebIDL method for proactively detecting > support for this feature, and are covered by basic tooling. > > > Will this feature be supported on all six Blink platforms (Windows, Mac, > Linux, Chrome OS, Android, and Android WebView)?Yes > > MSE and DedicatedWorker already exist on all six Blink platforms. This > feature lets MSE work from DedicatedWorker contexts. > > > Is this feature fully tested by web-platform-tests > <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> > ?Yes > > DevTrial instructions > https://github.com/w3c/media-source/issues/175#issuecomment-721395481 > > Flag nameMediaSourceInWorkers > > Requires code in //chrome?False > > Tracking bughttps://crbug.com/878133 > > MeasurementPrior to M105 (when worker MediaSource was attachable only by > object URL): Blink.UseCounter.Features.CreateObjectURLMediaSourceFromWorker > As of 105.0.5180.0 (when attachment of worker MediaSource was changed to be > done using transferable MediaSourceHandle): > Blink.UseCounter.Features.MediaSourceGetHandle > > Non-OSS dependencies > > Does the feature depend on any code or APIs outside the Chromium open > source repository and its open-source dependencies to function? > No. > > Sample links > https://tinyurl.com/mse-in-workers-demo > > Estimated milestones > OriginTrial desktop last 103 > OriginTrial desktop first 95 > OriginTrial Android last 103 > OriginTrial Android first 95*NOTE: Requested desktop and Android ship > milestone: 105 (The 'edit estimated milestones' link from chromestatus > didn't result in such ability to edit, so I'm adding this request > explicitly here.)* > *The feature is spec complete as of this request with corresponding > implementation and tests complete as of 105.0.5180.0. OT ends in 103 (and > Twitch has reported strongly positive results of their use of it during > OT.)* > > Anticipated spec changes > > None currently for this feature. > > Link to entry on the Chrome Platform Status > https://chromestatus.com/feature/5177263249162240 > > Links to previous Intent discussionsIntent to prototype: > https://groups.google.com/u/1/a/chromium.org/g/blink-dev/c/CNRywDqgKjY/m/F0nnA4tTAwAJ > Intent to Experiment: > https://groups.google.com/a/chromium.org/g/blink-dev/c/XZMyanniH9E > Intent to Extend Experiment: > https://groups.google.com/u/1/a/chromium.org/g/blink-dev/c/WETrrUYLrTM > > > This intent message was generated by Chrome Platform Status > <https://chromestatus.com/>. > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAADho6N8OYp-zQafT2pnAkWz%2BH2rujxgKgLBa9tsO5zJ3ZB%2BDQ%40mail.gmail.com.
