[Proposal] DRM: Add keySystems[].reuseMediaKeys loadVideo option
#1520
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
force-pushed
the
feat/renewMediaKeys
branch
from
54f2ba8
to
6b1b6cf
Compare
peaBerberian
added
DRM
We've seen multiple occurences lately on several devices where playback
failed after playing a few encrypted contents.
On those, setting the `closesSessionsOnStop` option (an option and
already-existing work-around) had no effect, yet renewing the MediaKeys
at each load fixed the issue.
It's very probably a device bug. For those, we usually had the strategy
of knowing on which devices this problem was encountered, detect it
inside the RxPlayer, and choose to always renew the `MediaKeys` on those
(without the application even knowing we did that).
However, some users suggested to us to add this as an option, because
they may have reproduced the issue on other devices.
I'm kind of ambivalent toward adding this as an option:
- I generally prefer our strategy of fixing it for all devices with the
issue, with people reporting issues to us when a new device has the
issue. This allows to fix it once and for all for all those devices.
- I understand that some applications might prefer to iterate rapidly
and be able to have more control over the RxPlayer behavior.
Another PR, #1510, would allow doing this by patching our config instead
but this would not be doable in production for applications (config
properties are not something we guarantee in our API).
This PR however, would allow applications to do it when and wherever they
please.
Thoughts?
peaBerberian
force-pushed
the
feat/renewMediaKeys
branch
from
6b1b6cf
to
3fdedf5
Compare
peaBerberian
changed the title
keySystems[].renewMediaKeys loadVideo optionkeySystems[].reuseMediaKeys loadVideo option
peaBerberian
added
Priority: 1 (High)
Comment on lines
+265
to
+267
| We noticed that reusing a previous `MediaKeys` had led to errors on a few devices. For | ||
| example some smart TVs had shown errors after playing several encrypted contents, errors | ||
| which disappeared if we renewed the `MediaKeys` for each content. |
There was a problem hiding this comment.
I'm wondering if those details are relevant in the documentation
There was a problem hiding this comment.
Why wouldn't it?
To me it explain why this option exists and why it may be useful no?
doc/api/Decryption_Options.md
Outdated
| example some smart TVs had shown errors after playing several encrypted contents, errors | ||
| which disappeared if we renewed the `MediaKeys` for each content. | ||
|
|
||
| We should already be able to detect most of those cases in the RxPlayer logic. However, it |
There was a problem hiding this comment.
It's hard to write good technical doc, but I think one improvement would be to not use pronoms like "we"
=> The RxPlayer should be able to detect most of those cases.
There was a problem hiding this comment.
Updated for renewMediaKeys only, we may want to update the wording for other option in a commit external to that PR
peaBerberian
force-pushed
the
feat/renewMediaKeys
branch
from
ff14e9a
to
fe5e039
Compare
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've seen multiple occurences lately on several devices where playback failed after playing a few encrypted contents.
On those, setting the
closesSessionsOnStopoption (an option and already-existing work-around) had no effect, yet renewing the MediaKeys at each load fixed the issue.It's very probably device bugs. For those, we usually had the strategy of knowing on which devices this problem was encountered, detect it inside the RxPlayer, and choose to always renew the
MediaKeyson those (without the application even knowing we did that).However, some users suggested to us to add this as an option, because they may have reproduced the issue on other devices.
I'm kind of ambivalent toward adding this as an option:
I generally prefer our strategy of fixing it for all devices with the issue, with people reporting issues to us when a new device has the issue. This allows to fix it once and for all for all those devices.
I understand that some applications might prefer to iterate rapidly and be able to have more control over the RxPlayer behavior.
Another PR, #1510, would allow doing this by patching our config instead but this would not be doable in production for applications (config properties are not something we guarantee in our API).
This PR however, would allow applications to do it when and wherever they please.
Thoughts?