Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

getLicense function is not called for DRM content in case of fairplay #159

Open
shubham-wynk opened this issue Mar 24, 2022 · 3 comments · May be fixed by #180
Open

getLicense function is not called for DRM content in case of fairplay #159

shubham-wynk opened this issue Mar 24, 2022 · 3 comments · May be fixed by #180

Comments

@shubham-wynk
Copy link

player.ready(function () { player.eme(); player.src({ src: config?.playurl, type: "application/x-mpegURL", keySystems: config.keySystems, withCredentials: true, }); });

getLicense: function( emeOptions, contentId, keyMessage, callback, keyId ){ console.log("GET LICENECE"); },

@evanluu
Copy link

evanluu commented Sep 16, 2022

I have the same issue with DRM content when AirPlay on Safari

@cfra
Copy link

cfra commented Oct 31, 2022

I believe this is related to this early return in handleEncryptedEvent:

return Promise.resolve();

When FairPlay protected content is played back via AirPlay, the key request of the player is proxies through the users browser.

So after the initial encrypted event that was received when playback was started, another encrypted event will be received when switching to AirPlay.

I could not find a lot of documentation on this process out there, however there is a brief description on page 9 of this PDF by Apple.

Either way, it seems like this second encrypted event has exactly the same initialData like the first event, so the event gets ignored by videojs-contrib-eme, so the AirPlay target never receives the necessary key information and cannot start playback.

I resolved this problem by changing the code like this, however I am not sure if this really is a clean solution, or if it should be resolved differently:

diff --git a/src/plugin.js b/src/plugin.js
index 53cb8e9..41b4c54 100644
--- a/src/plugin.js
+++ b/src/plugin.js
@@ -71,11 +71,11 @@ export const handleEncryptedEvent = (player, event, options, sessions, eventBus)
     // set of stream(s) or media data."
     // eslint-disable-next-line max-len
     // @see [Initialization Data Spec]{@link https://www.w3.org/TR/encrypted-media/#initialization-data}
-    if (hasSession(sessions, initData) || !initData) {
+    if (!initData) {
       // TODO convert to videojs.log.debug and add back in
       // https://github.com/videojs/video.js/pull/4780
       // videojs.log('eme',
-      //             'Already have a configured session for init data, ignoring event.');
+      //             'Empty init data, ignoring event.');
       return Promise.resolve();
     } 

For reference, it seems like Shaka Player was running in the same issue as well.

The issue can be found here shaka-project/shaka-player#2177 and their resolution can be found here shaka-project/shaka-player#2257

It seems they opted to clear the session store when switching beween AirPlay playback and regular playback, but I neither have the experience nor the testing resources available to come up with a solution like this for videojs-contrib-eme without further guidance.

cfra added a commit to PicturePipe/videojs-contrib-eme that referenced this issue Oct 31, 2022
cfra added a commit to PicturePipe/videojs-contrib-eme that referenced this issue Nov 11, 2022
@cfra cfra linked a pull request Nov 11, 2022 that will close this issue
@cfra
Copy link

cfra commented Nov 11, 2022

The solution I described in the previous comment turns out to be a bad idea:

It leads to lots of duplicate license requests and high time to first frame in the best case, and playback failure in other cases where license requests are guarded by a nonce.

Clearing the list of existing sessions when switching beween regular and AirPlay playback similar to shaka-project/shaka-player#2257 seems like a better approach.

I have opened #180 with an implementation of this approach.

As the PR will only have any effect if AirPlay is used, and AirPlay was broken before, it should definitely be an improvement. 😃

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants