LGTM to continue experimenting till M103. Note that this will bring the OT to 9 releases, so it'd be good to wrap up experimentation by this extension's end.
On Wednesday, February 16, 2022 at 11:03:08 PM UTC+1 Matthew Wolenetz wrote: > Hello blink-dev, > > We'd like to ask for an extension to our Origin Trial, from M99 to M103. > > There are two reasons extension is necessary: > > 1) A breaking error discovered in the middle of the trial (see > https://crbug.com/1268614) caused participation to drop before the 2021 > holiday period. While the fix landed by early 2022 and at least one > participant has reported excellent improvement in metrics in their > experiment since then, further stabilization is desired. > > 2) An API change for this feature (using srcObject for MSE-in-Workers > attachments instead of baking in objectURL attachment further) was agreed > with the media workgroup last September [1] following the previous > objectURL-based attachment design getting more recent feedback [2], and I'm > working on getting that into both the feature spec and Chromium's > experimental implementation currently for rapid experimentation during the > extended trial. > > [1] https://www.w3.org/2021/09/14-mediawg-minutes.html > [2] https://github.com/mozilla/standards-positions/issues/547 > > > Please find the Chrome status template, below: > > > 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://github.com/w3c/media-source/pull/282 > > 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 create an > ObjectURL for it and postMessage that URL 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 > > 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: No signal ( > https://github.com/mozilla/standards-positions/issues/547) > > WebKit: No signal ( > https://lists.webkit.org/pipermail/webkit-dev/2021-June/031916.html) > > Web developers: No signals > > 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. > > > Goals for experimentation > > * Obtain developer feedback on API ergonomics and implementation > stability. * Increase confidence in benefits of feature (exposing and > enabling MSE usage from DedicatedWorker contexts) to support its > standardization. > > > Reason this experiment is being extended > > There are two reasons extension is necessary: 1) A breaking error > discovered in the middle of the trial (see https://crbug.com/1268614) > caused participation to drop before the 2021 holiday period. While the fix > landed by early 2022 and at least one participant has reported excellent > improvement in metrics in their experiment since then, further > stabilization is desired. 2) An API change for this feature (using > srcObject for MSE-in-Workers attachments instead of baking in objectURL > attachment further) was agreed with the media workgroup last September [1] > following the previous objectURL-based attachment design getting more > recent feedback [2], and I'm working on getting that into both the feature > spec and Chromium's experimental implementation currently for rapid > experimentation during the extended trial. [1] > https://www.w3.org/2021/09/14-mediawg-minutes.html [2] > https://github.com/mozilla/standards-positions/issues/547 > > > Ongoing technical constraints > > > > 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/+/master/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 > > Estimated milestones > OriginTrial desktop last 99 > OriginTrial desktop first 95 > OriginTrial android last 99 > OriginTrial android first 95 > > 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 > > > 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/1fa996c8-9b24-463b-8791-19b9a9b50314n%40chromium.org.
