Shaka-player: Listening to both 'webkitneedkey' and 'encrypted'

Created on 24 Oct 2019  路  15Comments  路  Source: google/shaka-player

Hello,

I tried playing a FairPlay stream with Shaka Player version 2.5.5 where the drm.fairPlayTransform configuration is set to false. I see that playback is successful, but there's an error with code 6006 and message "EME PatchedMediaKeysApple key error" that is logged in the console.

I looked to see what was happening, and it looks like the player is listening to both the 'webkitneedkey' event and the 'encrypted' event. (https://github.com/google/shaka-player/blob/master/lib/polyfill/patchedmediakeys_apple.js#L377 and https://github.com/google/shaka-player/blob/master/lib/media/drm_engine.js#L418)

The license request succeeds in response to the 'webkitneedkey' event, but the player runs into a webkitkeyerror during the polyfilled generateRequest function in response to the 'encrypted' event. The init data differs slightly between the two events. I noticed that if I ignore the 'encrypted' event, then the playback is successful and there is no error logged in the console.

I'm mainly curious about the intention to listen to both events and also if there is a case where both events would be needed for successful playback. Do you know if there would be a way to avoid the error?

archived bug

All 15 comments

Sounds like a duplicate of #2031. Note that we turn a webkitneedkey event into an encrypted event, so if you are looking in DrmEngine, you should see two encrypted events. If you only see one, then they are the same event.

If you disable all handling of the encrypted event, I don't see how you can play content at all. With FairPlay, we only request a license as a result of an encrypted event. So if the asset plays without it, the content must be clear, or the browser is handling it for us. Can you provide your manifest, license, and certificate URLs?

I agree that there looks to be a spurious error since the playback is successful anyways. I was hoping to see whether there is a way to avoid that error since the severity marks it as a critical error.

I see that the Shaka player turns the webkitneedkey event into the encrypted event. I also see that Safari fires an additional encrypted event as well. I didn't word my explanation very well, but what I meant to say is that if I ignore that second encrypted event then I don't see the error.

I sent a sample page to [email protected]. The page has the Shaka player playing the FairPlay stream, and the error is logged to the console.

I also included two other pages that just use the HTML5 video element instead of using the Shaka player. The first page listens to both the webkitneedkey event and the encrypted event. The spurious webkitkeyerror occurs after the browser fires the encrypted event. The second page just listens to the webkitneedkey event, and there is no error.

I'm having the same issue I think. My drm.initDataTransform callback is called twice. The first time I'm able to extract my contentId and transform it. The 2nd time it is garbled. I'm assuming it is encrypted now? What's the solution?

@abdevnet try this, in my case this ugly workaround works:

const str8 = String.fromCharCode.apply(null, initData)
const str16 = String.fromCharCode.apply(null, new Uint16Array(initData.buffer)).substring(2)
const str = str16.indexOf('skd://') === 0 ? str16 : str8
const contentId = new URL(str).hostname

@michellezhuogg and I tried this today on desktop Safari and had no issues with the repro steps emailed to us by @lyjimmy. We were able to reproduce the spurious error with v2.5.5 as used in the sample code sent to us, but not with the latest release, v2.5.8. So we believe this has been fixed already.

But we did not see an additional 'encrypted' event fired by Safari directly. @michellezhuogg, can you check and report what version of Safari you have, in case that's relevant?

We tested on Safari 13.0.4, and Mac version 10.15.2.

@joeyparrish and @michellezhuogg I just tried this with my test scenario using my fairplay license server and I still get the 6006 error and duplicate calls to my transform method. I tested on Safari 13.0.5 and macOS 10.15.3. I attached my project. I hosted this on node live server and loaded the simple.html page in safari. Hit the test video button. You should see the error in alert messages. Click through those alerts. Right click the video, enable the controls and then click play the video will then play.

fairplay.zip

Reopening as people are still seeing this. This is supposedly reproducible with the demo app in #2364. I was also able to see an error with the provided zip file.

For me this only happens when the adaption set changes rapidly, e.g. via https://github.com/google/shaka-player/issues/2426
I was able to work around it with simple cache. See the issue for details.

We have an alternate fix in review now. We found that our polyfill for prefixed EME in older Safari versions was incompatible with the unprefixed EME released in newer Safari versions. Fixes to the polyfill and to our FairPlay configurations should be available soon.

@joeyparrish I'll be happy to test whenever you have something available.

@joeyparrish is there an a release that contains the fix? Is this waiting for 2.6 or is a minor release possible?

The fix landed in the master branch two days ago. We haven't made another release since then. We need to look carefully at whether there are any compatibility issues with the fix that would prevent us from cherry-picking it to the v2.5.x branch. If it can be done without breaking existing sites, we will cherry-pick it to v2.5.x. The next v2.5 release would be v2.5.11.

@joeyparrish I pulled the master branch yesterday and tested it. The fix worked perfect for me. Just had to update my javascript as mentioned in the updated tutorial.

We are cherry-picking the fix to v2.5.x, and it should be released in v2.5.11 soon.

Was this page helpful?
0 / 5 - 0 ratings