fix(compat): on Edge test comprehensively KeySystems before considering them as usable #1434
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
Florent-Bouisset
added
DRM
Florent-Bouisset
force-pushed
the
fix/compatibilty-edge-test-keysystems
branch
from
5dd6167 to
e78c575
Compare
Florent-Bouisset
force-pushed
the
fix/compatibilty-edge-test-keysystems
branch
from
af66177 to
4528c5a
Compare
Florent-Bouisset
force-pushed
the
fix/compatibilty-edge-test-keysystems
branch
from
4528c5a to
791ec0e
Compare
|
LGTM Did you test the last iteration on one device that was problematic and another based on Edge-chromium that wasn't? (Just so we ensure this fixes the issue and doesn't break PlayReady devices where it is unnecessary?) |
Not yet, will do when I have the devices in hands |
|
I have tested it on a problematic device and another one that is OK. It behaved as expected |
This was referenced Jun 11, 2024
Merged
peaBerberian
added a commit
that referenced
this pull request
Jul 23, 2024
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
added a commit
that referenced
this pull request
Jul 23, 2024
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
added a commit
that referenced
this pull request
Jul 23, 2024
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
added a commit
that referenced
this pull request
Jul 23, 2024
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
added a commit
that referenced
this pull request
Jul 23, 2024
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
added a commit
that referenced
this pull request
Jul 23, 2024
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
added a commit
that referenced
this pull request
Jul 23, 2024
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
added a commit
that referenced
this pull request
Jul 23, 2024
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.
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.
We observed that the RxPlayer cannot trust the browser when it has successfully granted the MediaKeySystemAccess with
navigator.requestMediaKeySystemAccess(keySystem)function, and it should do some additional testing to confirm that thekeySystemis supported on the device.This behavior has been experienced on the following device:
On a Microsoft Surface with Edge v.124:
requestMediaKeySystemAccessresolve correctly with the keySystem"com.microsoft.playready.recommendation.3000", generating a request withgenerateRequestthrows an error: "NotSupportedError: Failed to execute 'generateRequest' on 'MediaKeySession': Failed to create MF PR CdmSession".In this particular case, the work-around was to consider recommendation.3000 as not supported and try another keySystem.