Pass arround MediaSourceClass to replace DummyMediaElement's hotfix#1777
Open
peaBerberian wants to merge 2 commits intodevfrom
Open
Pass arround MediaSourceClass to replace DummyMediaElement's hotfix#1777peaBerberian wants to merge 2 commits intodevfrom
peaBerberian wants to merge 2 commits intodevfrom
Conversation
peaBerberian
force-pushed
the
dev
branch
9 times, most recently
from
0142e34 to
1fd9df3
Compare
peaBerberian
force-pushed
the
misc/pass-MediaSourceClass
branch
from
a246eec to
93ba098
Compare
|
✅ Automated performance checks have passed on commit DetailsPerformance tests 1st run outputNo significative change in performance for tests:
|
peaBerberian
added
the
Priority: 2 (Medium)
Back in our `v4.4.0` we brought the `DummyMediaElement` feature allowing to run the RxPlayer's logic even on environments where actual decoding and/or decryption is not possible (incompatible codecs, DRMs, unavailable media API etc.). Our main use case for this are testing purposes. While wrapping up the release, we noted that we still relied on the actual `MediaSource` API for checking codec support, removing a key use case of the feature: testing the RxPlayer on a content even if the current env does not support any of its codec. So we quickly implemented an exception in the corresponding code branch. It works and should catch all cases, but it was nonetheless not satisfactory for long-term maintainance. --- To make it more explicit, I propose here to pass from the `API` to the `Init` the `MediaSource` class that should be used to play the content. In a `DummyMediaElement`'s case, the `MediaSource` implementation linked to it will be provided instead of the favored `MediaSource` implementation found on the device. A remaining issue is that as the class is not transmitted to `core` (not serializable), `core` will still need to rely on the device's favored `MediaSource` implem. I thought that it wasn't an issue as a `DummyMediaElement` is not compatible for now with "MSE-in-worker" which is the only scenario where communicating its linked `MediaSource` would be needed.
peaBerberian
force-pushed
the
misc/pass-MediaSourceClass
branch
from
93ba098 to
a1dacdb
Compare
|
✅ Automated performance checks have passed on commit DetailsPerformance tests 1st run outputNo significative change in performance for tests:
|
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Back in our
v4.4.0we brought theDummyMediaElementfeature allowing to run the RxPlayer's logic even on environments where actual decoding and/or decryption is not possible (incompatible codecs, DRMs, unavailable media API etc.).Our main use case for this are testing purposes.
While wrapping up the release, we noted that we still relied on the actual
MediaSourceAPI for checking codec support, removing a key use case of the feature: testing the RxPlayer on a content even if the current env does not support any of its codec.So we quickly implemented an exception in the corresponding code branch. It works and should catch all cases, but it was nonetheless not satisfactory for long-term maintainance.
To make it more explicit, I propose here to pass from the
APIto theInittheMediaSourceclass that should be used to play the content. In aDummyMediaElement's case, theMediaSourceimplementation linked to it will be provided instead of the favoredMediaSourceimplementation found on the device.A remaining issue is that as the class is not transmitted to
core(as it is not serializable),corewill still need to rely on the device's favoredMediaSourceimplem. I thought that it wasn't an issue as aDummyMediaElementis not compatible for now with "MSE-in-worker" which is the only scenario where communicating its linkedMediaSourcewould be needed.