[WIP] Call generateRequest BEFORE pushing any segment with PlayReady #1486
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
bug
peaBerberian
force-pushed
the
fix/genreq-before-buffering
branch
3 times, most recently
from
8fad022 to
b2a68bf
Compare
peaBerberian
commented
Jul 23, 2024
| shouldCallGenerateRequestBeforeBufferingMedia(mediaKeySystemAccess.keySystem) | ||
| ) { | ||
| try { | ||
| await performFakeGenerateRequest(mediaKeys); |
There was a problem hiding this comment.
Note: maybe this does not need to be done if MediaKeySessions have already been created (and their generateRequest method called)?
To check, it could save us some time when playing multiple contents
peaBerberian
force-pushed
the
fix/genreq-before-buffering
branch
from
b2a68bf to
d5ba127
Compare
Another day, another PlayReady-specific issue :/
A partner signalled to us that they weren't able to play a mix of
unencrypted and encrypted content on any PlayReady devices.
After investigation, it seems that calling `generateRequest` for the
first time after clear segments are already present on a MSE
`SourceBuffer` associated to the MediaSource linked to the
corresponding media element immediately triggered an HTML5
`MEDIA_ERR_DECODE` error.
We tried A LOT of work-arounds:
- patching clear segments with a `tenc` box with a `0x0` key id to
incite the CDM to understand that encrypted contents may be pushed
in the future
- Rewriting the pssh sent through the EME `generateRequest` API so
that it is barebone to limit weird PlayReady edge cases.
- Replacing those stream clear segments' with those in our demo page,
just to check that the clear segments were not at fault here
- Waiting more time between the association of a MediaKeys to the
media element and pushing the first segments.
None of those actions had an effect.
However, what had an effect, was to call the `generateRequest` API
BEFORE buffering any segment yet AFTER attaching the MediaKeys (and
perhaps MediaSource) to the media element.
So this commit does just that, communicating dummy initialization data
for a session that will be closed directly after.
Note that we already do a fake `generateRequest` on Edge Chromium with
Playready since #1434, yet this test was not sufficient, seemingly
because it is performed BEFORE MediaKeys attachment.
Note that this commit fixes the clear -> encrypted issues our partner
were having, but we're unsure yet of if it fixes the encrypted -> clear
issues (and I have good reasons to think it does not).
So, uh, yeah, PlayReady seems to keep being hard-at-work giving us
challenges and head-scratchers.
peaBerberian
force-pushed
the
fix/genreq-before-buffering
branch
from
d5ba127 to
351ec6d
Compare
|
Turns out this doesn't really fix the issue, it leads to an infinite rebuffering when encrypted data is actually encountered (see #1403). Closing it |
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.
NOTE: This update is under tests by the partners that reported the issue, we aren't sure if it fixes the issue for them for now. I mainly opened this PR to add visibility to what that change could do and trigger discussions between RxPlayer developers.
Another day, another PlayReady-specific issue :/
A partner signalled to us that they weren't able to play a mix of unencrypted and encrypted content on any PlayReady devices.
After investigation, it seems that calling
generateRequestfor the first time after clear segments are already present on a MSESourceBufferassociated to the MediaSource linked to the corresponding media element immediately triggered an HTML5MEDIA_ERR_DECODEerror.We tried A LOT of work-arounds:
patching clear segments with a
tencbox with a0x0key id to incite the CDM to understand that encrypted contents may be pushed in the futureRewriting the pssh sent through the EME
generateRequestAPI so that it is barebone to limit weird PlayReady edge cases.Replacing those stream clear segments' with those in our demo page, just to check that the clear segments were not at fault here
Waiting more time between the association of a MediaKeys to the media element and pushing the first segments.
None of those actions had an effect.
However, what had an effect, was to call the
generateRequestAPI BEFORE buffering any segment yet AFTER attaching the MediaKeys (and perhaps MediaSource) to the media element.So this PR does just that, communicating dummy initialization data for a session that will be closed directly after.
Note that we already do a fake
generateRequeston Edge Chromium with Playready since #1434, yet this test was not sufficient, seemingly because it is performed BEFORE MediaKeys attachment.Note that this PR fixes the clear -> encrypted issues our partner were having, but we're unsure yet of if it fixes the encrypted -> clear issues (and I have good reasons to think it does not).
So, uh, yeah, PlayReady seems to keep being hard-at-work giving us challenges and head-scratchers.