1309891 - DRM protected video causes MediaKeySession InvalidModificationError exception

Status: RESOLVED INVALID

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

Description

[daniel.silhavy]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.143 Safari/537.36

Steps to reproduce:

1. We start the playback of HDCP_V1 protected content on a MAC OSX machine with an external display connected.
2. We receive a output-restricted event which is correct since HDCP_V1 does not support external displays in combination with MAC OSX.
3. We start the playback of HDCP_NONE proteced content
4. A new MediaKeySession is created
5. MediaKeySession::generateRequest fails with an InvalidModificationError and the message "An attempt was made to modify the type of the underlying obje"


Actual results:

MediaKeySession::generateRequest fails with an InvalidModificationError and the message "An attempt was made to modify the type of the underlying obje"

Firefox version: 49.0
DOMException
Code: 13
Message: An attempt was made to modify the type of the underlying objec
Name: InvalidModificationError
Result: 2152923149


Expected results:

MediaKeySession::generateRequest creates a new request. Same content/workflow works in Google Chrome. We are wondering if anyone is experiencing the same behavior.

Comment 1

[daniel.silhavy]

Might be related to this issue:
https://bugzilla.mozilla.org/show_bug.cgi?id=1265587

Comment 2

[Chris Pearce [:cpearce (Not reading bugmail)]]

Hi Daniel,

Apologies for my slow response, I've been busy.

We pushed a new Widevine CDM (version 903) to in Firefox 50, do you want to try testing with an up to date Firefox 50?

If you can still reproduce the bug in Firefox 50, can you share some test content that demonstrates the behaviour with us? That will make debugging it much easier.

Thanks!

Comment 3

[daniel.silhavy]

Hi Chris,
thanks for your support. I checked with Firefox version 50 and unfortunately the problem remains the same. I will try to provide some public test content and let you know as soon as I have some.
Thanks and best regards
Daniel

Comment 4

[JW Wang [:jwwang] [:jw_wang]]

ni? kilik to check EME issues.

Comment 5

[Kilik Kuo [:kikuo] (inactive)]

(In reply to daniel.silhavy from comment #3)
> Hi Chris,
> thanks for your support. I checked with Firefox version 50 and unfortunately
> the problem remains the same. I will try to provide some public test content
> and let you know as soon as I have some.
> Thanks and best regards
> Daniel

Hi Daniel,
Is it possible to provide content that would generate request which needs HDCP_V1 for us ? Or do you know any public resources for that ?
I'd like to follow this up, but cannot get further without that content.

Comment 6

[daniel.silhavy]

(In reply to Kilik Kuo [:kikuo] from comment #5)
> (In reply to daniel.silhavy from comment #3)
> > Hi Chris,
> > thanks for your support. I checked with Firefox version 50 and unfortunately
> > the problem remains the same. I will try to provide some public test content
> > and let you know as soon as I have some.
> > Thanks and best regards
> > Daniel
> 
> Hi Daniel,
> Is it possible to provide content that would generate request which needs
> HDCP_V1 for us ? Or do you know any public resources for that ?
> I'd like to follow this up, but cannot get further without that content.

Hi,
unfortunately I can not provide the content we used for the tests above. I know that Google has some test content which is linked in the Exoplayer repository:
https://github.com/google/ExoPlayer/blob/release-v2/demo/src/main/assets/media.exolist.json

Some more infos about what we did so far:
The problem occured when we were testing with the HAS player (https://github.com/Orange-OpenSource/hasplayer.js/tree/master) and Smooth Streaming content. I did some further testing and it turned out that we are not able to close the old MediaKeySession between step 3 and 4. To be more precise:

1. We start the playback of HDCP_V1 protected content on a MAC OSX machine with an external display connected.
2. We receive a output-restricted event which is correct since HDCP_V1 does not support external displays in combination with MAC OSX.
3. We start the playback of HDCP_NONE protected content without refreshing the page.
4. We try to close the old key session before we open up a new one.
5. The status of the session promise stays "pending", the session will not be closed. This step works in Chrome with the same player/content.

My first guess was that the output-restricted event somehow influences the key session, so I tried to reproduce the problem by setting up a local proxy and a plain MSE/EME player. Turns out I can close the keysession after I received an output-restricted event. So in general this seems to work fine.
I let you know if I have more updated on that issue or found a way to reliable reproduce it.
Thanks Daniel

Comment 7

[Blake Wu [:bwu][:blakewu]]

Kikuo,
Is there something we can do to move this bug forward? Or can we close this bug?

Comment 8

[Bulk Bug Changes for mreavy's org]

Mass change P1->P2 to align with new Mozilla triage process

Comment 9

[Kilik Kuo [:kikuo] (inactive)]

Sorry for the late response, just had a chance to borrow a Mac and made a test with current nightly.

I tested it on Shaka Demo Player with first HDCP_V1 content then HDCP_None content.
The promise to close MediaKeySession for HDCP_V1 content is rejected with NS_ERROR_DOM_UNKNOWN_ERR (Not pending) 
and the following EME procedures for HDCP_None content still work.

I'll dig further to find out where NS_ERROR_DOM_UNKNOWN_ERR comes from.

Comment 10

[Sylvestre Ledru [:Sylvestre]]

Moving to p3 because no activity for at least 1 year(s).
See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information