-
Notifications
You must be signed in to change notification settings - Fork 133
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Proposal] Add hidden "Dummy media API" experimental feature and add integration tests linked to DRM #1478
Open
peaBerberian
wants to merge
9
commits into
misc/no-eme-type
Choose a base branch
from
misc/mse-mock
base: misc/no-eme-type
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Conversation
This file contains 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
peaBerberian
added
tests
Relative to the RxPlayer's tests
tools
Relative to the RxPlayer's tools
Demo
Relative to the RxPlayer's demo page
labels
Jul 9, 2024
peaBerberian
force-pushed
the
misc/mse-mock
branch
3 times, most recently
from
July 9, 2024 15:59
bb18117
to
7743e95
Compare
peaBerberian
added
the
proposal
This Pull Request or Issue is only a proposal for a change with the expectation of a debate on it
label
Jul 9, 2024
peaBerberian
force-pushed
the
misc/mse-mock
branch
5 times, most recently
from
July 9, 2024 21:11
ae80343
to
9527be7
Compare
peaBerberian
force-pushed
the
misc/no-eme-type
branch
2 times, most recently
from
July 24, 2024 16:49
c4aae81
to
a7cc348
Compare
peaBerberian
force-pushed
the
misc/no-eme-type
branch
from
July 31, 2024 09:09
a7cc348
to
2fbc31b
Compare
peaBerberian
force-pushed
the
misc/mse-mock
branch
2 times, most recently
from
August 1, 2024 12:24
b5c4a45
to
418170b
Compare
peaBerberian
force-pushed
the
misc/no-eme-type
branch
3 times, most recently
from
August 1, 2024 13:56
6429671
to
ce097d5
Compare
peaBerberian
force-pushed
the
misc/mse-mock
branch
from
August 2, 2024 14:49
418170b
to
9001a12
Compare
peaBerberian
force-pushed
the
misc/no-eme-type
branch
from
August 12, 2024 13:56
ce097d5
to
231f5b1
Compare
peaBerberian
force-pushed
the
misc/mse-mock
branch
from
August 13, 2024 16:36
9001a12
to
46e9cd5
Compare
peaBerberian
added a commit
that referenced
this pull request
Aug 13, 2024
While working on new DRM integration test in #1478, to add tests for the not-yet-released features proposed by #1484, I noticed that some contents anounced HEVC by beginning the codec string with `hev` and others with `hvc`. When comparing family of codecs, we thus had false negative which may mean we would have ended up playing encrypted hevc on devices where it wasn't supported, if it was anounced in the MPD as `hev1...`. I now treat both the same way.
peaBerberian
force-pushed
the
misc/mse-mock
branch
from
August 13, 2024 16:49
46e9cd5
to
e19cc47
Compare
peaBerberian
force-pushed
the
misc/no-eme-type
branch
from
August 13, 2024 16:50
231f5b1
to
d52f7b9
Compare
peaBerberian
force-pushed
the
misc/mse-mock
branch
from
August 13, 2024 16:50
e19cc47
to
5c63db9
Compare
peaBerberian
force-pushed
the
misc/no-eme-type
branch
from
October 8, 2024 15:02
13d94f1
to
d5e9d37
Compare
peaBerberian
force-pushed
the
misc/mse-mock
branch
from
October 8, 2024 15:02
c81c211
to
2affdb9
Compare
peaBerberian
force-pushed
the
misc/no-eme-type
branch
from
November 15, 2024 17:30
d5e9d37
to
93465f5
Compare
peaBerberian
force-pushed
the
misc/mse-mock
branch
2 times, most recently
from
November 15, 2024 17:39
d20b29c
to
6bc16dc
Compare
peaBerberian
force-pushed
the
misc/no-eme-type
branch
from
December 12, 2024 12:09
93465f5
to
6cb2c4b
Compare
peaBerberian
force-pushed
the
misc/mse-mock
branch
2 times, most recently
from
December 12, 2024 13:19
c2a0d34
to
e52bc61
Compare
peaBerberian
force-pushed
the
misc/no-eme-type
branch
from
December 16, 2024 17:54
6cb2c4b
to
1cdf76b
Compare
peaBerberian
force-pushed
the
misc/mse-mock
branch
from
December 16, 2024 17:55
eb00de1
to
3f14f8f
Compare
peaBerberian
force-pushed
the
misc/no-eme-type
branch
from
December 17, 2024 14:25
1cdf76b
to
43802b5
Compare
peaBerberian
force-pushed
the
misc/mse-mock
branch
from
December 17, 2024 14:25
3f14f8f
to
903d71d
Compare
peaBerberian
force-pushed
the
misc/mse-mock
branch
from
December 17, 2024 14:27
903d71d
to
3c9b425
Compare
peaBerberian
force-pushed
the
misc/mse-mock
branch
from
December 23, 2024 10:55
be747ef
to
021309d
Compare
peaBerberian
added a commit
that referenced
this pull request
Dec 23, 2024
Thanks to the PR #1478, that basically allows integration tests on our DRM logic without a real encrypted or decodable contents nor MSE/EME available, I noticed that I very recently brought a minor regression in the rewrite of the `MediaKeySystemAccess` cache reusage rules. We relied on the `keySystems[].type` API to see if the cached one was compatible to the new wanted one, we probably wanted to compare the former with the `type` actually provided as argument to the `navigator.requestMediaKeySystemAccess` API instead (e.g. `keySystems[].type` could be set just to `widevine`, in which case the RxPlayer will probably ask for `com.widevine.alpha` instead). Thankfully, EME defines a [`MediaKeySystemAccess.prototype.keySystem`](https://www.w3.org/TR/encrypted-media-2/#dom-navigator-requestmediakeysystemaccess) property that seems to (according to that recommendation) always be equal to the asked `keySystem`.
peaBerberian
added a commit
that referenced
this pull request
Dec 23, 2024
Thanks to the PR #1478, that basically allows integration tests on our DRM logic without a real encrypted or decodable contents nor MSE/EME available, I noticed that I very recently brought a minor regression in the rewrite of the `MediaKeySystemAccess` cache reusage rules. We relied on the `keySystems[].type` API to see if the cached one was compatible to the new wanted one, we probably wanted to compare the former with the `type` actually provided as argument to the `navigator.requestMediaKeySystemAccess` API instead (e.g. `keySystems[].type` could be set just to `widevine`, in which case the RxPlayer will probably ask for `com.widevine.alpha` instead). Thankfully, EME defines a [`MediaKeySystemAccess.prototype.keySystem`](https://www.w3.org/TR/encrypted-media-2/#dom-navigator-requestmediakeysystemaccess) property that seems to (according to that recommendation) always be equal to the asked `keySystem`.
peaBerberian
added a commit
that referenced
this pull request
Dec 24, 2024
This is based on #1478. On #1478, I was mocking MSE+EME + a part of the [HTML5 media spec](https://html.spec.whatwg.org/#media-elements) to allow advanced integration tests without having to create encrypted contents nor having to physically test on all encountered environments. The subset of the MSE and EME API that we use isn't very complex, the harder part was to mock an `HTMLMediaElement`: especially the evolution of the current position, rebuffering, ending, readyState, autoplay etc. A shortcut I consequently took in #1478 was to rely on a potential browser behavior: [the allowed to play](https://html.spec.whatwg.org/#allowed-to-play) concept. By forbidding playback through this mechanism, I could avoid all those complex features while still being spec-compliant. However forbidding playback prevent us from making a lot of useful tests: e.g. on freezing, rebuffering, ending, auto-play etc. So this commit is an attempt to implement that. I relied on the WHATWG HTML spec but I took many shortcuts, especially by removing parts that aren't relied on at all by the RxPlayer. It's possible that I missed some quirks or that it still has some bugs, but it right now seems to following the behavior of a real `HTMLMediaElement` well enough. I also did not implement "directfile" playback for now. For all those missing features, we may ideally throw or indicate in some way that this is not yet implemented.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
Demo
Relative to the RxPlayer's demo page
Priority: 3 (Low)
This issue or PR has a low priority.
proposal
This Pull Request or Issue is only a proposal for a change with the expectation of a debate on it
tests
Relative to the RxPlayer's tests
tools
Relative to the RxPlayer's tools
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.
Based on #1477
Reason
Today, we can only test the RxPlayer's DRM-related logic either through:
unit tests. Writing those are very time-consuming considering that EME-related code changes often, and thus often lead to unit test rewrites.
To lower the lost time, we added the concept of "global unit tests", which instead of performing tests at the lower function-level, it performed them at the module-level, which has its own API much less subject to change.
Even then, we would prefer more stable and representative tests.
rx-tester
: Our closed-source repository that tests real production contents through one of our main application at canal+.This is nice but we have to go through another application that do not use the API at its full extent, so it's not an exhaustive test for us.
It's also closed-source and relying on specific real-life contents where we would prefer the idea of directly running in the RxPlayer CI tests on contents with all kinds of quirks.
manually, which is also time-consuming.
The idea is here to actually run DRM-related integration tests by completely mocking in them:
To be able to run those tests through
npm run test:integration
either locally or in our CI.Implementation
I decided to add an [incomplete] in-JS HTML5 media element implementation as an "experimental tool" (in
src/experimental/tools/DummyMediaElement
).That fake HTMLMediaElement actually implements the
IMediaElement
type defined in #1397 and so should be compatible with what the RxPlayer expects of a media element.It has also those supplementary properties:
FORCED_MEDIA_SOURCE
: our implementation of aIMediaSource
/ISourceBuffer
etc. (as defined in [Proposal] Forbid usage of the HTMLMediaElement and MSE TS types #1397) for a MSE implementationFORCED_EME_API
: our implementation ofIMediaKeySystemAccess
,IMediaKeys
,IMediaKeySession
etc. (as defined in [Proposal] Forbid usage of theMediaKeys
type and other EME TS types #1477) for an EME implementationWhen those are present, the RxPlayer will rely on them instead of the usual MSE and EME implementations.
I also added:
In the demo page: I added a
Dummy Media API
switch allowing to rely on our MSE+EME+HTML5 implementation instead of the browser's. This is mainly to be able to debug the RxPlayer logic on contents that cannot normally be played on the demo page, usually because of DRM.With this on, those contents will load - even if with a black screen (though subtitles are displayed) - and the RxPlayer will believe that the content can play.
In integration tests: I added a fake encrypted content with several keys and some tests checking for errors thrown, fallbacks, license request configuration etc.. More tests should be quick to add.
On that matter, I already spotted a potential issue when the
getLicense
respond much faster than aSourceBuffer.prototype.appendBuffer
call. I removed that test as I try to fix the issue.What's missing
Not the full extent of the MSE, EME nor HTML5 media API is implemented here.
Most notably, I did not yet implement:
actual content playback, as in the loaded content will always stay in pause.
The fake implementation will block actual playback by relying on the
NotAllowedError
exception on eachplay
call, so the RxPlayer still understands the issue.I did not implement playback yet because I did not want to take time implementing time-related complexities (stalling, ending etc.). Though I plan to.
persistent licenses. This does not seem hard to do, but I did not take the time yet. My implementation will just gives the standard answer indicating that the feature is not supported
MSE "sequence" mode: this can become complex and we do not need it at all for now in the RxPlayer
Only "mp4" files are handled for now, as we have to do some container parsing here
Multiple other minor features