player freezes when transitioning from unencrypted content to DRM encrypted content

[seiji-fli]

Description

Player should decrypt and decode upcoming DRM segments with no issues. When player finishes playing unencrypted preroll content it freezes when attempting to play non-ad content.

Streams come from Google DAI with server-side ad insertion

Example is using:
videojs 7.6.6
videojs-contrib-eme 3.6.0
videojs-http-streaming 2.14.2

Reduced test case

http://fli-cw-drm-test.s3-website-us-east-1.amazonaws.com/

Steps to reproduce

1. click "Start Player" button
2. wait for preroll ad to finish
3. observe player

Errors

no errors in console or UI

What version of Video.js are you using?

7.6.6

Video.js plugins used.

videojs-contrib-eme, videojs-http-streaming

What browser(s) including version(s) does this occur with?

Chrome 95+, tested mostly on Chrome 99+

What OS(es) and version(s) does this occur with?

Linux Mint 20.2, Windows 10, MacOS

[welcome]

👋 Thanks for opening your first issue here! 👋

If you're reporting a 🐞 bug, please make sure you include steps to reproduce it. We get a lot of issues on this repo, so please be patient and we will get back to you as soon as we can.
To help make it easier for us to investigate your issue, please follow the contributing guidelines.

[misteroneill]

I'm not able to reproduce anything using the link provided. It fails to playback and the player CSS does not appear to be included.

[seiji-fli]

@misteroneill thank you for looking into this, I have updated the test site with a working stream

[seiji-fli]

hi @misteroneill have you had a chance to review our sample page demonstrating this issue?

[BucherTomas]

The mpeg-dash stream returns either 500 or 404 status, so the behavior cannot be verified, but there is one thing immediately raising red flags and that is the test page itself.

If you are using DRM with Chrome, the whole webpage environment needs to be served via https, so even your webpage needs to be served also as https://fli-cw-drm-test.s3-website-us-east-1.amazonaws.com/ (or alternatively from localhost) for the encrypted part of the stream to work in Chrome.

This is because of EME API which is mentioned here https://sites.google.com/a/chromium.org/dev/Home/chromium-security/deprecating-powerful-features-on-insecure-origins as requiring https.

[seiji-fli]

here's the test page served via https - https://d38oliqqso65pm.cloudfront.net/

[BucherTomas]

The actual stream quite often returns 500 status but in case it works, it shows on my end that the content from encrypted periods returns 403 status for all requests instead of the actual segments. Ad preroll period plays.

As an example, the init segment for one of the representations https://stream-hls.cwtv.com/nosec/The_CW/808/700/135064645582/out_video_0_init_d85bb36228d94bd2ac222f6b20b89f37_.mp4 returns 403 and this is true for all of them.

If it happens to you as well then this needs to be fixed first.

[video-archivist-bot]

Hey! We've detected some video files in a comment on this issue. If you'd like to permanently archive these videos and tie them to this project, a maintainer of the project can reply to this issue with the following commands:

• for https://stream-hls.cwtv.com/nosec/The_CW/808/700/135064645582/out_video_0_init_d85bb36228d94bd2ac222f6b20b89f37_.mp4: say @video-archivist-bot save PA0zMj

[seiji-fli]

@BucherTomas i'm not seeing any 500 or 403 errors on my end when playing the stream on the test page

[BucherTomas]

@seiji-fli I do get 403s for encrypted segments, but I see now it is due to geoblocking restrictions.

Can you instead capture HAR log from Chrome's network tab in dev tools and share it here?

[seiji-fli]

@BucherTomas how can I share these logs privately?

[BucherTomas]

Except maybe some cross-site cookies, HAR log does not contain any additional private information than what can anyone already see in the network tab when loading your test site.

[seiji-fli]

@BucherTomas here's a har log of what i'm seeing: https://drive.google.com/file/d/1jyygLA8siIFSr5XOEtxse2MYdDUbWHSd/view?usp=sharing

[BucherTomas]

Thanks! The player does not even request the DRM license according the log.

I quickly tested with another similar livestream from another player project that also has both encrypted and clear periods in its manifest and that seems to work fine in the demo player at https://videojs-http-streaming.netlify.app so both videojs and http streaming library appear to be ready for this scenario. Can you try testing your stream also directly via that player at https://videojs-http-streaming.netlify.app/?debug=true&url=https%3A%2F%2Fpubads.g.doubleclick.net%2Fondemand%2Fdash%2Fcontent%2F2585492%2Fvid%2F4c676f97-0148-45e5-aa90-4754835e584f%2FTUL%2Fstreams%2F30c6eb77-4789-4575-9098-2f8e046c12a7%2Fmanifest.mpd&type=application%2Fdash%2Bxml&keysystems=%7B%0A%20%20%22com.widevine.alpha%22%3A%20%7B%0A%20%20%20%20%22url%22%3A%20%22https%3A%2F%2Fwidevine.entitlement.theplatform.com%2Fwv%2Fweb%2FModularDrm%2FgetRawWidevineLicense%3Ftoken%3DeyJhbGciOiJSUzUxMiJ9.eyJzdWIiOiJ3dXhsemM0NGRhOGtjRG00LzczMDYxNjUzNyIsImlzcyI6IjEiLCJleHAiOjE5NzIwNDU0MjgsImlhdCI6MTY1NjY4NTQyODU1MSwianRpIjoiZGRmOTVhNGMtM2QzZS00MjhlLWI4MWYtM2UyN2QyNzk2MmU1IiwiZGlkIjoid3V4bHpjNDRkYThrY0RtNCIsInVubSI6Imd1ZXN0IiwiY3R4Ijoie1wiaWRcIjpcImh0dHBzOi8vZXVpZC50aGVwbGF0Zm9ybS5jb20vaWRtL2RhdGEvVXNlci93dXhsemM0NGRhOGtjRG00LzczMDYxNjUzN1wiLFwidXNlck5hbWVcIjpcImd1ZXN0XCIsXCJmdWxsTmFtZVwiOlwiQ1dUViBHdWVzdFwiLFwiZW1haWxcIjpcIlwiLFwiYXR0cmlidXRlc1wiOnt9fSIsIm9pZCI6IjI3MDM0NTQxNDkifQ.CmAs4FJDTlODnPKbkW9yj8Q0RcUw70Ew_GD21t-IuiBhDiau9dpEN22KiyrO3eR4Q6bEsbr0sU8w7nR5DIS003yeUi8xeOncPrCOAngE9acB4k2DAx6yvpxRhl27AcyBxp21sMZnFYSJmTvjtCuk_G_Cc5bOgDJCjgFJkaWSEf-lz9WfGF42prE916CBsJ93oeeIegmNNvEDHQh8FhEJinUt1lI_8rH1BTGBqWAMZMRzYqmBhsRKDVVw-BYSnDlVo08FTczMAi4J_PO-St1qOsYPN7dluKzOPlDhQM8Pq9EJVD5PlSOqk9u0NJFI09Mugc2ZlsjYpg5EU8vd2JCW9w%26form%3Djson%26schema%3D1.0%26account%3Dhttp%253A%252F%252Faccess.auth.theplatform.com%252Fdata%252FAccount%252F2703454149%26releasePid%3D5_fWiav6Ot2_%22%0A%20%20%7D%0A%7D

Since I am geoblocked by your stream, I can't do it myself.

[seiji-fli]

@BucherTomas experiencing the same as my test page on https://videojs-http-streaming.netlify.app/

[BucherTomas]

Have you tested the stream in any other freely available player demos such as dashjs or Shaka just to make sure the stream itself is not at fault? The mpd manifest looked fine to me the last time I saw it, but the devil is in the details.

Sorry, I can't be of much further help. as I'm being blocked by the encrypted periods of the stream in my region and it's almost impossible to provide any meaningful guidance if I can't analyze the behavior in the player directly.

[seiji-fli]

@BucherTomas
when I attempt to load the stream in to the shaka player demo, it gets pass the initial preroll ad and the first 6 second video segment. Once it gets to the initial encrypted video segment, it fails to load

[BucherTomas]

OK, as I said the last time, I have exhausted all the help I could provide considering I have no access to the full stream. Maintainers of videojs residing in the U.S. to get around stream geoblocking would need to join in the analysis here.

However, since another player has also similar issue while transitioning to the encrypted part, it could point to an issue with the content itself rather than with the player framework.

[seiji-fli]

@BucherTomas
can I get your ip address to whitelist the stream? can also send to smorikami@imds.tv

thank you

[jamescahall]

@BucherTomas I'd like to bring this issue back to life. I know the exact use case here and will try to explain clearly.

1. We start with a MPEG-DASH stream that uses CENC DRM (supporting both Modular Widevine and Microsoft PlayReady). The manifest itself contains ContentProtection values though they are not the primary decryption mechanism. Decryption is handled with a license url (Widevine when tested in Chrome browser on macOS) fed to VideoJS. When played out in this manner, the license is requested and there are no issues with playback.

2. When this stream is passed to Google DAI to be SSAI backed, it comes back with a multi-period manifest where some periods are Clear (bumpers and ads) and some periods are DRM protected (primary content).

The underlying issue is that VideoJS seems to ignore the license url that has been passed in player setup when it sees that the first period of content is not encrypted and fails to ever call the license url to decrypt content when it gets to a period with content. You can see in the network tab that the license url is never requested. videojs-contrib-eme suggests there is a method that could be called initializemediakeys:
https://github.com/videojs/videojs-contrib-eme#initializemediakeys

But using this always results in:
"Unsupported keySystem or supportedConfigurations."

Example urls can only be shared privately due to legal reasons.

I can say that the same streams play fine and we see DRM license url calls in:

1. Shaka Player
2. Bitmovin Player
3. Tizen AVPlay
4. AVPlayerViewController on iOS/tvOS
5. ExoPlayer on Android/AndroidTV/FireTV
6. Roku Player

Very much appreciate the help looking in to this.

As a general note, the OTT community has been searching for a long time (10+ years) for a HTML5-based player that will work on all of the major TV platforms (Samsung, LG, VIZIO, Hisense, and Philips at a bare minimum) and support typical DRM + SSAI, VOD/Live/Linear, captions, multi-audio, etc. and we keep hitting hurdles like this that lead to having to use one player on MANY HTML5 platforms and then have to use an alternative player on others. We want to help but the feedback we regularly get is "we don't have those TVs" or "we need test streams" (which is very challenging to deliver when every discussion is public) when the scenarios are quite common scenarios. We can connect you with TV manufacturers to get free or deeply discounted TVs so that really shouldn't be a hurdle. I'd like VideoJS to be the solution and already using it on hundreds of millions of devices but it is just not quite feature-complete enough to use ubiquitously.

[BucherTomas]

@jamescahall This should be addressed to the Video.js development team, I'm just another user who was attempting to help narrow down the possible reasons for the behavior, because it may affect our own usage of the player in the future as well.

You have seemingly managed to identify the reason successfully based on your description. But as it appears to be directly related to the https://github.com/videojs/videojs-contrib-eme library, I'd suggest to create an issue in that repo, too. Good luck.

[jamescahall]

Thanks for the feedback. @misteroneill is this something you can review with the videojs team?

[adrums86]

We are looking into this, or more specifically a related issue which I think will address these issues as well. I will provide an update when some more progress has been made.

[jamescahall]

Thank you @adrums86 . Is this something you expect will have a fix in the short term or will be something weeks or months out in a future release?

[adrums86]

@jamescahall no problem. Unfortunately it's difficult to provide a reliable estimate as we're juggling quite a bit currently. I can say that DRM issues are high on our priority list right now and I will try and keep these github issues updated as we work to address them.