[MULTI_THREAD] Communicate to /init whether we're relying on MSE-in-worker
#1669
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…-worker Built on #1664 (the PR, not the other thing). While exchanging in that PR with @Florent-Bouisset, we noticed that the choice of whether we rely on mse-in-worker was done by the Public API part of the code, which then directly told our WebWorker to use that feature without telling any other part of the code. However, that PR brought the need to have that information inside the `ContentInitializer` - so that it knows whether a given codec is supported (for cases, only seen on Edge for now, where codec support is different depending on if MSE is relied on inside a worker or on main thread). Even without this, I thought that our `ContentInitializer`, as a global controlling module, should probably architecturally be in the know of whether MSE API are called in-worker or in-main-thread. So I propose this modification, where the information on whether mse-in-worker should be used is both communicated to the `ContentInitializer`, but is also set per-content (we don't need that, but it's actually both simpler and more powerful that way so why not). This also opens the way for an API to control this, but I did not add one for now.
|
✅ Automated performance checks have passed on commit DetailsPerformance tests 1st run outputNo significative change in performance for tests:
|
Florent-Bouisset
approved these changes
Apr 8, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Built on #1664 (the PR, not the other thing).
While exchanging in that PR with @Florent-Bouisset, we noticed that the choice of whether we rely on mse-in-worker was done by the Public API part of the code, which then directly told our WebWorker to use that feature without telling any other part of the code.
However, that PR brought the need to have that information inside the
ContentInitializer- so that it knows whether a given codec is supported (for cases, only seen on Edge for now, where codec support is different depending on if MSE is relied on inside a worker or on main thread).Even without this, I thought that our
ContentInitializer, as a global controlling module, should probably architecturally be in the know of whether MSE API are called in-worker or in-main-thread.So I propose this modification, where the information on whether mse-in-worker should be used is both communicated to the
ContentInitializer, but is also set per-content (we don't need that, but it's actually both simpler and more powerful that way so why not).This also opens the way for an API to control this, but I did not add one for now.