I've filed a new request-for-position using the new WebKit process for this today. The previous request was: https://lists.webkit.org/pipermail/webkit-dev/2021-June/031916.html The new one is: https://github.com/WebKit/standards-positions/issues/40
I've also updated chromestatus' WebKit signals citation to use the new request. On Wed, Jul 27, 2022 at 12:32 PM Matthew Wolenetz <[email protected]> wrote: > 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 <[email protected]> > wrote: > >> Contact [email protected] >> >> 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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAADho6Pk%3DaHKm%2BthfAqjizv5g_BAFL%2BJtCHYzX0MMP8LhaDmsg%40mail.gmail.com.
