DRM: Don't work-around firefox issue if the application asked for specific capabilities #1498
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
…cific capabilities In #1495, we recently worked around an issue specific to firefox on windows where asking for at least one unsupported video or audio capability resulted (in our opinion, incorrectly) to a `navigator.requestMediaKeySystemAccess` API call failure. To work-around this and other similar bugs, we decided to just always perform a second `navigator.requestMediaKeySystemAccess` call in our logic which doesn't ask for any capability. However, I just realized that this may break some API usages. For example let's imagine that an application specifically set an `audioCapabilitiesConfig` or `videoCapabilitiesConfig` in a `loadVideo` call to ask for specific capabilities (either specific codecs, or specific robustnesses like PlayReady SL3000 or Widevine L1). Here, we would first perform a check with the asked capabilities, yet also a second one without. Meaning that an application could be left with a key system that is not the one it explicitely asked for (e.g. we could be playing with PlayReady SL2000 when the application asked explicitely for PlayReady SL3000). So the fix here is to disable the "no capabilities" work-around if an application explicitely ask for specific capabilities.
peaBerberian
added
bug
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.
In #1495, we recently worked around an issue specific to firefox on windows where asking for at least one unsupported video or audio capability resulted (in our opinion, incorrectly) to a
navigator.requestMediaKeySystemAccessAPI call failure.To work-around this and other similar bugs, we decided to just always perform a second
navigator.requestMediaKeySystemAccesscall in our logic which doesn't ask for any capability.However, I just realized that this may break some API usages.
For example let's imagine that an application specifically set an
audioCapabilitiesConfigorvideoCapabilitiesConfigin aloadVideocall to ask for specific capabilities (either specific codecs, or specific robustnesses like PlayReady SL3000 or Widevine L1).Here, we would first perform a check with the asked capabilities, yet also a second one without. Meaning that an application could be left with a key system that is not the one it explicitely asked for (e.g. we could be playing with PlayReady SL2000 when the application asked explicitely for PlayReady SL3000).
So the fix here is to disable the "no capabilities" work-around if an application explicitely ask for specific capabilities.