Work-around firefox 129 windows bug #1495
Merged
Conversation
This file contains hidden or 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/firefox-widevine-bug
branch
3 times, most recently
from
fa5504b to
11e1946
Compare
We noticed a pretty big issue on firefox 129 (released yesterday) on windows) where we cannot play encrypted content anymore (seen on production with multiple applications relying on the RxPlayer - so it's a relatively big issue). It seems that since this release, the `navigator.requestMediaKeySystemAccess` EME API, which we use to poll available decryption capabilities in the current environment, will fail as soon as there's at least one asked "robustness" (allows for example to ask for hardware-based DRM) even if we're asking for e.g. software-based DRM, which we know the device has. It seems likely this is a firefox issue, but it seems too big for us to just do nothing and throw the bug at them. Other streaming actors, such as Netflix and Amazon Prime Video don't seem to be impacted by the issue at first glance. In fact, they are, but they have a fallback call where they are calling the `navigator.requestMediaKeySystemAccess` API without any robustness just in case the API is broken like here. Yet, we also have the same work-around, but we integrated both configurations (the first with robustnesses, the second without), in the same `navigator.requestMediaKeySystemAccess` call, whereas they're doing two calls each with an array of a single element (the first with, the second without like us). So to """""fix""""" the issue, I decided to align with their work-arounds (so the next time it breaks, browser devs will see it also breaks Netflix and thus maybe detect the issue faster). For the same key system type, doing one call with multiple configurations or multiple calls with one configuration seems equivalent from my understanding of the EME recommendation, so what I did here should change nothing EME-wise (except more EME API calls), it is just to align the code with others. I still had to change our recently-added code about codec checking, to make it work robustly in that new scenario.
peaBerberian
force-pushed
the
fix/firefox-widevine-bug
branch
from
11e1946 to
53d5644
Compare
peaBerberian
added a commit
that referenced
this pull request
Aug 13, 2024
…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 a commit
that referenced
this pull request
Sep 13, 2024
…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.
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 noticed a pretty big issue on firefox 129 (released yesterday) on windows where we cannot play encrypted contents anymore (seen on production with multiple applications relying on the RxPlayer - so it's a relatively big issue).
It seems that since this release, the
navigator.requestMediaKeySystemAccessEME API, which we use to poll available decryption capabilities in the current environment, will fail as soon as there's at least one asked "robustness" (allows for example to ask for hardware-based DRM) isn't supported even if we're also asking for e.g. software-based DRM, which we know the device has.It seems likely this is a firefox issue, but it seems too big for us to just do nothing and throw the bug at them.
Other streaming actors, such as Netflix and Amazon Prime Video don't seem to be impacted by the issue at first glance.
In fact, they are, but they have a fallback call where they are calling the
navigator.requestMediaKeySystemAccessAPI without any robustness just in case the API is broken like here.Yet, we also have the same work-around, but we integrated both configurations (the first with robustnesses, the second without), in the same
navigator.requestMediaKeySystemAccesscall, whereas they're doing two calls each with an array of a single element (the first with, the second without like us).So to """""fix""""" the issue, I decided to align with their work-arounds (so the next time it breaks, browser devs will see it also breaks Netflix and thus maybe detect the issue faster).
For the same key system type, doing one call with multiple configurations or multiple calls with one configuration seems equivalent from my understanding of the EME recommendation, so what I did here should change nothing EME-wise (except more EME API calls), it is just to align the code with others.
I still had to change our recently-added code about codec checking, to make it work robustly in that new scenario.