DRM setup should be implied by DRM config, to better support unencrypted ads

[SemihGk]

When we load the live content during the yo-space ad, drm engine cannot be initialized properly. Because manifest does not have the content protection for the yo-space video segments(periods). I added a sample manifest below. Please check the yo-space manifest.
yo-space-ad-manifest.txt

So, drm-engine cannot be initialized properly due to no content protection info in manifest although last period has the content protection. As you may see the drm-engine:
Init Manifest:

Drm-engine:

After the ad, when protected content is started to play, playback fails at stream_utils due to keySystem . Because keySystem returns null. Small note: variant.drmInfos has the keys while keySystem variable is null. However, if we add
if (this.config_ && this.config_.advanced) { return Object.keys(this.config_.advanced)[0]; } into keySystemMethod

, it works fine. On the other hand, I am aware that this is not a proper solution, but I could not find a better answer.

Besides, video playback is fine if we load the video during protected content. This is only occurred when you join the stream during the ad.

Please let me know if you need further information or you need to see the sample app. I can send you email.

Thanks,
Semih.

[SemihGk]

I have spent a bit more time to clarify the issue and I have a better explanation now.

If we load the content during an ad and initialized manifest does not have any content protection,

Sample Manifest
non-protected-sample-manifest.txt

drmEngine would not be initialized properly. Because drmEngine init is only be called when shakaPlayer.load method is fired. Please check this line: drmEngine: keySystemsInOrder . If manifest does not have any drmInfo, it would not call the queryMediaKeys . Because, it would return Promise.resolve. That's why, drmEngine would not be initialized properly and it is going to be failed when protected content is loaded because of drmEngine initialization.

So, we need to initialize drmEngine for future protected contents although this manifest does not have any protected content. At this case, it seems we could only check config object to see this content is protected. Therefore, I added:

var isAnyDrmConfigSet = (this.config_.servers && Object.keys(this.config.servers) > 0) || (this.config_.advanced && Object.keys(this.config.advanced) > 0); if(!keySystemsInOrder.length && !isAnyDrmConfigSet) {

It works fine. So, I want to get your suggestion. At this case, should not yospace serve nonprotected manifest during an ad? Or do they need to serve a protected flag? Otherwise, would you consider a case to reinitialize drmEngine when a manifest that has protected periods is served? Although the last case seems a solid fix, it may decrease performance since we can do that config check easily. Thank you.

[joeyparrish]

At the very least, we need to know that the content will be protected. If the manifest doesn't have any clues to tell us encrypted content is expected, we won't set up EME.

Here's a possible solution that seems simple from my perspective: put ContentProtection elements in the ad periods, even though they aren't encrypted. It won't hurt anything to have them there, and that is an existing signalling mechanism that the Player recognizes.

Would that work for you?

[SemihGk]

Thank you for your response. I appreciate your suggestion and it seems a reasonable solution. I will share this with yospace team. However, this might be a hacky solution for them since this issue is related to shaka-player only and we cannot reproduce it on other platforms. I am just curious how about other DAI providers do. Do they encrypt ads as well? If not, this issue is going to remain for others. Also, you are right that the manifest does not tell anything about the encrypted content, but user configures the player that encrypted content will be expected. I think this should be considered.

I will keep you updated after we discuss this with yospace. Thank you!

[joeyparrish]

I'm not sure how other players or DAI providers handle this.

Part of our design for v2 has been that you can provide a complete DRM configuration without needing to care which providers are available for which platform, or even which pieces of content are encrypted. If you provide DRM configuration and play a piece of clear content, we will ignore that DRM configuration. So if you provide DRM configuration for, say, Widevine & PlayReady, you should still be able to play clear content on a browser with neither.

If we change that, and we set up DRM any time license servers are provided, DRM becomes required by that configuration, even for clear content. But if you provide license servers in your application, you are probably expecting DRM content at some point, either in some other manifest or some future period of this one. So it shouldn't be a big risk for developers if we change this.

I'm marking this as an enhancement, renaming, and scheduling tentatively for v2.4. In the mean time, if you want to make appropriate changes in your fork of Shaka Player or send us a pull request, we are always happy to have contributions from the community.

[chrisfillmore]

@joeyparrish I haven't looked at this issue directly myself, but I am surprised that this does not produce a ENCRYPTED_CONTENT_WITHOUT_DRM_INFO error. Would that not be the expected result in these circumstances?

[joeyparrish]

@chrisfillmore, I'm not sure.

But the underlying request is to expect DRM content when there is a DRM configuration provided, and I think I'm okay with that. We could be more selective and make this change in behavior conditional on live or dynamic content, since everything should be known upfront about static/VOD content.

Another option is to add a configuration to allow apps to say "expect DRM content at some point".

[SemihGk]

After some further discussion, implementing the fix to shaka will be a better solution at this case. I will work on a possible fix for this ticket since we may need this fix soon. However, this config check might not be a great idea because chromecast is overriding the drmInfo in the previous function. I still think the solution that reinitializes drm when encrypted content is received if drm manager is not initialized properly. Also, Chris is right. encrpyted event should be fired. However, it seems it is not working at all although I listened to the event during this error.

[joeyparrish]

Cherry-picked to v2.3.1.