Shaka-player: Multiple request to license api for Widevine DRM in Chrome

Created on 27 Jul 2020  路  10Comments  路  Source: google/shaka-player

Have you read the Tutorials? Yes

Have you read the FAQ and checked for duplicate open issues? Yes

What version of Shaka Player are you using? v3.0.1

Please ask your question
I am testing Shaka player with DRM content on the demo page and
I found that the player will request license multiple times for encrypted(Widevine) content in Chrome and Edge.

Sample link: https://shaka-player-demo.appspot.com/demo/#audiolang=en-GB;textlang=en-GB;uilang=en-GB;asset=https://storage.googleapis.com/shaka-demo-assets/angel-one-widevine/dash.mpd;panel=ALL_CONTENT;panelData=drm:WIDEVINE;build=uncompiled

Is it possible to avoid this situation? This behaviour will increase our cost because of the increased license requests.

Thanks a lot.

On Chrome:
Screen Shot 2020-07-27 at 16 25 51

archived bug

All 10 comments

We have noticed the same in our app and thought it was some issue on our side. Good to know that it might be related to shaka player 3.x

This could be a server certificate request. To protect the user's privacy, the Widevine CDM uses this cert to encrypt certain information in the license request such that only the intended server can read it. This means that the server cert must be fetched before a real license request can be generated.

Please check the length of the body of the first request. If it's very short (a few bytes), then it's a server certificate request.

To avoid a server certificate request, you can supply your license server's certificate ahead of time through advanced DRM configuration. This is distinct from the TLS/SSL certificate used for HTTPS, and you'll have to get it from whomever provides your license server. If you're using Widevine services directly, I can help you get that cert. Otherwise, contact your provider.

When you have the cert, load it into memory as an ArrayBuffer or Uint8Array. You can store it alongside your application and fetch it from your web server, or you can hard-code it into your application code as a Uint8Array.

Then configure Shaka Player like this:

player.configure('drm.advanced.com\\.widevine\\.alpha.serverCertificate', serverCertificate);

If you want to hard-code your cert, you can easily turn a hex dump of the cert into a Uint8Array. For example:

const serverCertificate = new Uint8Array([
  0xde, 0xad, 0xbe, 0xef, 0x43, 0x90, 0x11, 0x6...
]);

See also the DRM configuration tutorial: https://shaka-player-demo.appspot.com/docs/api/tutorial-drm-config.html
And the API docs for the advanced DRM configuration: https://shaka-player-demo.appspot.com/docs/api/shaka.extern.html#.AdvancedDrmConfiguration

Does this help?

The example given is a demo asset and does contain two license requests (with two certificate requests). For some reason we are requesting a license twice for the same init data. If I log the DrmEngine.activeSessions_ value, there are two entries with the same initData value. It appears we aren't de-duping requests somewhere.

@jerryipcri Does this answer all your questions? Can we close the issue?

I am confused now, is it considered a bug @joeyparrish ? From @TheModMaker I was under impression that it's a bug on Shaka player side

Thank you
Jakub

We also tested different DRM in different browser e.g. Edge + PlayReady, Safari + FairPlay and we found that the behaviour are different in Shaka player.

No. of license requests: (streams of playback source: 1 video + 1 audio)
Mac +Chrome + Widevine : 2 POST x 2
Safari + FairPlay : 1 POST x 2
Edge + PlayReady: 1 POST (1 OPTION, 1 GET)
iOS + Safari + FairPlay : 1 POST
Android + Chrome + Widevine : 2 POST x 2

Why does the player work in different browser/DRM differently ?

Thank you.

On iOS we use src=, so the browser handles everything and we have no control.

On Safari (if using DASH on Mac), we'll do the same thing as Widevine, but without the server certificate request.

On Edge, we send an OPTION because we include extra headers to the request, so it may no longer be a "simple request" so we need to send a CORS request first. Not sure why there aren't two sets.

On the others, we use Widevine, which is always the same. As @joeyparrish said, the two requests are first for a server certificate and then for the normal license.

In all cases, we do two sets for audio and video. Normally we should de-dupe the same requests, but there appears to be a bug that prevents that.

We have roughly tested that the problem is resolved.
Could you let me know when you will rollout this version?
We would like to use this fixed version as soon as possible as it is affecting our cost on using DRM provider.
Your action is much appreciated.
Thank you so much.

This fix will be cherry-picked to both the v2.5 and v3.0 branches. I intend to release from both branches this week, but I can't give an exact date because some parts of the release process require internal approvals that sometimes come from different time zones.

Thanks for your response. We will wait for your next version release then.

Was this page helpful?
0 / 5 - 0 ratings