Use the button, below, to get started.
Demo details are at the bottom of this page.
This demo requires a browser which supports MSE-in-Workers.
Known-working browsers:
| Demo parameters (Applied when "Start Demo" button is clicked) | |
| Media URL (to fetch completely, then append in chunks) : | |
| Media type : | |
| Chunk append size : |
|
| Busy-wait duration (milliseconds) : |
|
Demo details
This is a demo of how usage of Media Source Extensions API from a dedicated worker context can avoid "buffering jank" when the main window context is very busy, even though the media element playing the buffered media is still on that main thread.
This demo presents a side-by-side comparison of two players, one fetching and buffering to its media element solely on the main window context, and the other player relying on a dynamically created dedicated worker to fetch and buffer the same media into a MediaSource owned by that worker's context, attached to the main window context's media element via a transferred-to-main MediaSourceHandle object set on the media element's srcObject attribute.
A scenario where the main thread is under heavy contention is achieved by frequently busy-waiting on it while both players are fetching, buffering and playing. Furthermore, asynchronous appendBuffer operations are performed (on each of the main and worker MSE demos) in small chunks to enable rapid appearance of "buffering jank" on the player being buffered via MSE on the main thread versus a much better experience on the player being buffered via MSE on the worker thread, even if the media stream is short.
In practice, main thread (aka Window context) contention can result from many sources, though commonly it is from complex and frequent task execution demands made by the application on the Window execution context, and is made worse when the platform has less execution capacity available. The DOM and associated application javascript operate in the Window execution context. DedicatedWorkers run in a concurrent execution context with respect to the Window execution context. Even with concurrent buffering and smoother playback by using MSE on a dedicated worker context, observe that the video element for the MSE-in-Worker player can still have poor controls response time when the Window context is under high contention. This is because that element (and its controls) can only execute on the Window context and their event handlers can have high scheduling latency.
To try in Chrome, use 105.0.5180.0 or greater (earlier versions since 88.0.4300.0 experimentally supported worker MediaSource attachment using legacy object URLs, but that functionality has been removed from both the implementation and specification).
If the main thread MSE buffering playback is too slow (it might take a long while to render even the first frame on some machines), reduce the amount of contention on the main thread by stopping the demo, selecting a smaller busy-wait duration (to handle other main thread tasks more frequently) or a larger append-size (to do more real buffering work when scheduled), and restarting the demo.