Playback failure on Chrome 58 Beta (and Chrome Canary)

john....@verizondigitalmedia.com

unread,

Apr 7, 2017, 12:21:16 PM4/7/17

to Shaka Player Users

I hope that it isn't too early to comment on issues with chrome 58, but all of my previously working streams seem to be failing with the chrome 58 beta channel release.

I was actually trying to validate the fix to https://bugs.chromium.org/p/chromium/issues/detail?id=597443 (also announced in a formal blog post here: https://developers.google.com/web/updates/2017/03/mixing-streams), but when I started using chrome 58 none of my streams worked any longer.

All of the streams fail to playback sighting a DRM license acquisition failure from our Widevine proxy.

Shaka Error DRM.LICENSE_REQUEST_FAILED (shaka.util.Error { "severity": 2, "category": 1, "code": 1001, "data": [ "https://content-ausw2.uplynk.com/wv", 400, "<html><body>Widevine license request didn't include key ID</body></html>", { "content-type": "text/html", "cache-control": "no-cache, no-store", "": "" } ], "message": "Shaka Error NETWORK.BAD_HTTP_STATUS (https://content-ausw2.uplynk.com/wv,400,<html><body>Widevine license request didn't include key ID</body></html>,[object Object])", "stack": "Error: Shaka Error NETWORK.BAD_HTTP_STATUS (https://content-ausw2.uplynk.com/wv,400,<html><body>Widevine license request didn't include key ID</body></html>,[object Object])\n at new shaka.util.Error (http://localhost:8000/lib/util/error.js:65:13)\n at XMLHttpRequest.xhr.onload (http://localhost:8000/lib/net/http_plugin.js:80:16)" })

I am not 100% sure that the error message I am getting back from our Widevine proxy is entirely accurate (I will look into this more), but I don't really suspect an issue with the proxy as all of my samples fail on chrome 58, and they all work (minus the one with unencrypted portions) on chrome 57. They also continue to work perfectly with Shaka on Firefox.

Maybe something needs to change in my request or response filter functions for chrome 58 to work, or could there be an issue with Shaka or Chrome?

I am currently working with the Shaka demo app. I have tried against the 2.0.7 tag, as well as the latest code from master, but I have had no success with chrome 58. I have a small diff to the demo/assets.js file that I am attaching with 3 samples that all fail on chrome 58. Two of them work on chrome 57 as I mentioned although one of them runs into bug 597443.

You should be able to copy this diff into the Shaka root directory and apply it with "patch -p1 < assets.js_with_verizon_tests.diff" against 2.0.7 and probably master also (although I generated it off of 2.0.7).

Can you provide any insight into what is going wrong here?

John Bowers

VDMS Engineering

assets.js_with_verizon_tests.diff

Joey Parrish

unread,

Apr 7, 2017, 2:38:32 PM4/7/17

to Shaka Player Users

Hi John,

I suspect the issue may be in your proxy. To confirm, please open the network panel of Chrome dev tools and tell me if the failing request is very small, maybe 2-4 bytes long.

Widevine uses server certificates to encrypt identifying information in the license request. This is to protect the user's privacy. Only the intended license server has the private key needed to decrypt the client's ID.

Before Chrome 58, these certificates were only needed when certain options were turned on via EME. In Chrome 58 and after, these certificates are always needed.

If the server certificate is not provided by the application, the CDM will provision one through the license server before making an actual license request. This request is much smaller than a license request, so you can use this as a quick hack to detect the server certificate request. (For a better solution, you will need to contact Widevine support for guidance. I don't know the details on how this is supposed to be done.)

If your proxy is parsing every request and throwing an error when the request does not contain a key ID, it's probably failing on these certificate requests. If you pass these requests on to the backend, the CDM will get its server certificate and then make an actual license request.

Once you have fixed your proxy to correctly pass on these server certificate requests, you can take one more step in the client to optimize out this extra round trip. You can contact Widevine support to get a server certificate that you can supply to Shaka Player (who will in turn provide it to the CDM via EME). This will eliminate the extra round trip to provision the certificate. This extra step is a completely optional optimization.

Does this help?

-Joey

--
You received this message because you are subscribed to the Google Groups "Shaka Player Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to shaka-player-users+unsub...@googlegroups.com.
To post to this group, send email to shaka-player-users@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/shaka-player-users/842d7b48-3272-45f4-ae24-720bad6737cd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

john....@verizondigitalmedia.com

unread,

Apr 7, 2017, 3:14:04 PM4/7/17

to Shaka Player Users

Actually that is quite enlightening. Thank you. It makes perfect sense that it would be new requirement from chrome that would cause the issue. The failing request is indeed exactly 2 bytes long also, so that fits what you are suggesting quite nicely. I will get to work on getting the proxy to forward these requests so I can actually test what I was intending to test in the first place.

Thanks again.

To post to this group, send email to shaka-pla...@googlegroups.com.

Joey Parrish

unread,

Apr 7, 2017, 4:10:47 PM4/7/17

to Shaka Player Users

Happy to help!

To unsubscribe from this group and stop receiving emails from it, send an email to shaka-player-users+unsubscribe@googlegroups.com.

To post to this group, send email to shaka-pla...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/shaka-player-users/842d7b48-3272-45f4-ae24-720bad6737cd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Shaka Player Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to shaka-player-users+unsub...@googlegroups.com.

To post to this group, send email to shaka-player-users@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/shaka-player-users/1466e143-b489-49a0-8c83-6692ec325347%40googlegroups.com.

a...@intertrust.com

unread,

May 1, 2017, 3:30:14 PM5/1/17

to Shaka Player Users

Hi Joey,

Regarding the optimization, I tried the latest Shaka with the guidelines from Widevine for sending the certificate via the 'advanced' config properties with no luck. I retrieved the certificate from our proxy via a certificate request response and converted from B64 to Uint8Array, but keep getting (from both Chrome 59 and Canary):

Shaka Error DRM.INVALID_SERVER_CERTIFICATE (Rejected with system code (17))

Any guidance on the format of the certificate or methods to retrieve it from the Widevine cloud? The 'normal' 2 request (cert, then license) process works fine for us.

Thanks,

Ani

Joey Parrish

unread,

May 10, 2017, 5:51:11 PM5/10/17

to Shaka Player Users

Hi Ani,

Are you letting the CDM provision a server certificate once, then caching the response and feeding it in through the advanced config?

Thanks,

Joey

--
You received this message because you are subscribed to the Google Groups "Shaka Player Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to shaka-player-users+unsub...@googlegroups.com.
To post to this group, send email to shaka-player-users@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/shaka-player-users/6d16f19e-7bf6-4e79-87b1-3428b1283535%40googlegroups.com.

Reply all

Reply to author

Forward