Closed Bug 1705138 Opened 24 days ago Closed 2 days ago

Firefox 88 with Widevine CDM 4.10.2209.1 fails to playback encrypted content when license enforcing HDCPv1

Categories

(Core :: Audio/Video: Playback, defect, P1)

Firefox 88
defect

Tracking

()

RESOLVED FIXED
90 Branch
Tracking Status
firefox-esr78 88+ fixed
firefox88 + fixed
firefox89 + fixed
firefox90 + fixed

People

(Reporter: kieron.allsop, Assigned: bryce)

References

Details

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:87.0) Gecko/20100101 Firefox/87.0

Steps to reproduce:

Obtain license for encrypted content which will require HDCPv1 to be enforced for playback.
Attempt playback using Shaka Player on Windows 10 Laptop known to support HDCPv1.

Actual results:

Upon attempted playback, 'MANIFEST_RESTRICTIONS_CANNOT_BE_MET ' ('restrictedKeyStatuses : output-restricted') is returned.

This behaviour is consistent across all content we use in testing that enforces HDCPv1.

Expected results:

Content should have played.

The same content plays without issue in Firefox 87 with Widevine CDM 4.10.1582.2.

The Bugbug bot thinks this bug should belong to the 'Core::Audio/Video: Playback' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Component: Untriaged → Audio/Video: Playback
Product: Firefox → Core

Further to initial report here is a means to reproduce the issue.

Navigate to:
https://urm.latens.com:9443/bugzilla

There is one piece of encrypted content which requires HDCP v1.

Select PLAY and the video will load.

It will playback in Firefox 87 / Widevine CDM 4.10.1582.2
It will not playback in Firefox 88 / Widevine CDM 4.10.2209.1

Bryce, could you please help? Thanks!

Flags: needinfo?(bvandyk)
Assignee: nobody → bvandyk
Severity: -- → S2
Priority: -- → P1
Status: UNCONFIRMED → NEW
Ever confirmed: true

I'm investigating this, but I also see the file fail in Chrome with the new CDM. If I open the test page in comment 2 in Chrome, wait for the video to load and start playback, and then clock the 'Play' text underneath the 'DASH SingleKey HDCP v1' content, I see the same error. I also notice the test case behaving intermittently in old versions of Firefox that do not have the new CDM.

May I ask which version of Chrome. Just updated to Version 90.0.4430.72 which uses Widevine CDM Version: 4.10.2209.0 and playback is possible.

I've tested on 89.0.4389.128 and 90.0.4430.72. I've been able to repro on both, but it happens much less regularly than on Firefox. I'm also able to repro the issue on older versions of Firefox with the old CDM, but it seems less frequent. It feels like it happens more often if I disable the network cache in each browser via the dev tools, but since it's intermittent it's hard to be sure.

And when it fails is the error in Console 'MANIFEST_RESTRICTIONS_CANNOT_BE_MET ' ? Or some other error.
Some background... I run a suite of browser tests (via Robot / Selenium) nightly. There are 8 tests in total which required HDCPv1. Against a Windows 10 machine running Firefox 87 /Chrome 90 these pass. However they are currently the only failing tests I have against Firefox 88.

I've seen 'MANIFEST_RESTRICTIONS_CANNOT_BE_MET ' as well as others, but it's significantly rarer on Chrome, so it may not be the same issue. I notice even in old Firefox I'll typically get that error if I let playback start and then hit the play text a few more times. However, it is pretty much constant with the new CDM -- so I agree something is going on. I've got some theories to test and will report back once I've done so.

I think I've located the issue. It's caused by a Widevine behaviour change that hasn't been documented. The fix is likely to be fairly involved and some of the work may need to be tracked in secure bugs. I'll update this bug as work progresses.

Flags: needinfo?(bvandyk)

Hi, I have the same issue. The release of Firefox 88 on April 19th makes the issue more serious for us. This issue is seen in the production environment but our service can't give up HDCP_V1 because of the system requirement. Can you stop providing 4.10.2209.1 temporarily? We still have over a month before the revocation of older CDMs.

We're investigating mitigations and this is a top priority. One of those potential mitigations is the roll back of the CDM. However, we have a number of conflicting interests which means a rollback would also create issues with some partners. I'll be sure to update this bug once we have more info to share.

Severity: S2 → S1

I believe this is the bug preventing me from playing Amazon Prime DRM content in HD for the last two weeks?

We have a mitigation that we're planning on landing in nightly shortly, and will be rolling it out to be and release as soon as possible. I'll update this bug as we do so. We'll be following up the mitigation with further changes, but the initial mitigation should be enough to unblock this.


(In reply to PimpUigi from comment #12)

I believe this is the bug preventing me from playing Amazon Prime DRM content in HD for the last two weeks?

My understanding is this bug shouldn't be affecting Amazon prime. Could you open another bug and cc me on it so we can investigate?

I've seen some folks discussing this bug in the context of Widevine no longer working on MacOS 10.9 due to the CDM not supporting that OS version. To avoid ambiguity, I want to highlight that the MacOS compat issue is a separate issue from this and is tracked in bug 1706393.

I also believe this bug has blocked my ability to view HD on Amazon for roughly the past two weeks. It's been discussed on reddit and several others feel the same. I will wait for a new bug post on this if its not thought to be exactly the same issue.

I am served HD content on Amazon when using a build of Firefox that is affected by this issue. I suspect Amazon is serving lower resolution content to older versions of the CDM. If you navigate to about:support and find the media.gmp-widevinecdm.version preference value, recent versions of Fx will have 4.10.2209.1, while older ones will have a different version. It's those older versions I'd expect to see getting SD content.

If you have 4.10.2209.1 and are still getting SD, then it's possible something else is going on. Again, another bug to track that would be useful, as if the issue has a different root cause we want to keep the information separate from this bug.

I've created bug 1707688 to track further discussion on the Amazon Prime reports. Please continue any discussion on the Amazon Prime issue there and if it does turn out to be the same problem we can close it against this bug.

A mitigation for this has landed in the most recent nightly, and is effective in my testing. It would be useful to know if other folks see the most recent Firefox Nightly also working.

We're planning to roll the change back to other versions of Firefox also, and I will update this bug as we do.

Duplicate of this bug: 1707688

Added to the Firefox 88, Beta 89, and 78.10esr release notes as a known issue. As noted in comment 18, we intend to address this in upcoming point releases across all channels.

I can confirm that the issue would appear fixed in Firefox Nightly; I am able to play the entirety of the the trailor from the test page I provided to demostrate the issue.

I did a check with Bliss (2021) from Amazon Prime. It can be watched in HD 1080 after updating nightly to 90.0a1(2021-04-27).

Duplicate of this bug: 1708363

78.10.1esr shipped today with a fix for this issue. We expect to ship 88.0.1 tomorrow with a fix as well.

Duplicate of this bug: 1708990

Firefox 88.0.1 is also available now with a fix for this bug.

Status: NEW → RESOLVED
Closed: 2 days ago
Resolution: --- → FIXED
Target Milestone: --- → 90 Branch
You need to log in before you can comment on or make changes to this bug.