-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Playlist with mixed segment with and without DRM (ClearKey) #4774
Comments
Switching between encrypted and unencrypted content in the player is a no-op. We don't do anything special. It is all handled by the browser's CDM and decoders. |
Mixed encrypted/unencrypted content is extremely common, especially for server-side ad insertion. This structure should not be an issue. In fact, even without ads, some encrypted VOD content begins unencrypted for several seconds (called a "clear lead") to allow time for the license exchange without delaying startup. Please check |
Thanks for sharing this useful information. I also understood that mixed encrypted/unencrypted content is extremely common. |
I don't see it. In the first screenshot, kPause is the last event shown. After re-reading your issue, I noticed something inconsistent that we should clarify. Are you using ClearKey (which is an open, demo DRM system)? Or HLS's AES-128 (which uses clear keys, but not ClearKey DRM)? There is an important distinction, and they have to be implemented in completely different ways in the player. |
I am not sure of the difference between ClearKey and clear keys, sorry if I am confusing you because the title and body content do not match. I am using HLS's AES-128. |
It's pretty confusing. AES-128 is a block cipher, and there are many "modes" in which you can use it, by combining it with other operations in some kind of chain, or by feeding it with certain data. All standardized DRM (the "Common Encryption" standard) uses AES-128 at its core, in one of two common modes (CTR or CBCS). However, the "AES-128" encryption used by Apple in HLS is incompatible with all of those DRM schemes. It uses CBC mode, but encrypts the entire segment instead of just parts of it. It's also not considered DRM. What makes it harder to understand is that Apple's FairPlay DRM uses Common Encryption, not the encryption they describe in HLS. All DRM uses the EME API in the browser. Encryption and key requests are handled inside the browser in something called a CDM (Content Decryption Module). Apple's FairPlay, Goggle's Widevine, and Microsoft's Play ready are all DRM. ClearKey DRM is not "real" DRM because the keys are in the clear, but it is handled by a CDM and uses the same decryption as the other DRM systems. HLS's "AES-128" encrypts the entire segment (unlike DRM), so the CDM can't decrypt it. Even the ClearKey CDM is incompatible with this. So this content is decrypted using WebCrypto APIs in JavaScript. I'm going to assume you're using HLS's AES-128 full-segment encryption. So what might be happening is that the player is decrypting a clear ad with the key for the previous main content. Then what gets fed to the browser for that ad is random-looking garbage, and it fails to decode. Can you please provide an accessible playlist URL for us to debug? I'll relabel this as a bug. Thanks! |
Thank you for your uncomplicated explanation. Please use the following assekey for your debugging playlist: |
Can you check with the main branch? |
Closing due to inactivity. If this is still an issue for you or if you have further questions, the OP can ask shaka-bot to reopen it by including |
@shaka-bot reopen I've confirmed that this problem no longer occurs. |
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?
4.3.0
Please ask your question
I am trying SSAI using Google IMA DAI SDK for HTML5
When playing the playlist which main content (non-advertisement part) is encrypted with AES-128 and advertisement is not encrypted, I get the following error before mid-roll is played.
Also, if the playlist that neither of which is encrypted, can play mid-roll without any problem.
I assume that this issue is caused by the shaka-player not being able to handle the switching between encrypted (ClearKey in this case) and unencrypted segments.
Could you confirm my understanding is correct? Thank you in advance for your answer.
The text was updated successfully, but these errors were encountered: