Multiperiod: Optimize transition from unencrypted to encrypted period

[dsilhavy]

Description

In a multiperiod MPD some periods might be encrypted while other periods are not. An example of that is ad-insertion, in which the ad periods are typically not encrypted but the main content periods are.

For some DRM systems, it is necessary to initialize the MSE with an encrypted init segment to allow a smooth transition between unencrypted and encrypted periods. If the media player starts with an unencrypted period and then transitions to an encrypted period, the MSE will throw an error unless it has been initialized with an encrypted init segment first.

Our current implementation overcomes this limitation by resetting the MSE once and only in this scenario:

1. Playback is started with an unencrypted period
2. Player needs to transition to an encrypted period
3. MSE is reset prior to this transition.

Suggested implementation

To improve the scenario described above and avoid an MSE reset, we can synthesize an encrypted init segment directly in the player. The synthesized encrypted init segment has a static KID which we ignore in the resulting encrypted events thrown by the EME.

After appending this synthesized encrypted init segment we immediately append the "normal" unencrypted init segment of the first playback period and follow the default workflow.

Open questions

• Should we scan the MPD for encrypted periods before applying this workaround? Or should we always apply this workaround (configurable via settings parameter) as there might be periods with encrypted content coming up which are not yet signaled in the MPD.
• As an alternative, if we scan the MPD for encrypted periods we can also download an init segment from one of the upcoming encrypted periods. However, this requires us to initialize the period in dash.js internally which would require major rewriting of the existing logic. We would also need to be more dynamic when it comes to ignoring encrypted events thrown by the EME.

[dsilhavy]

Slack feedback by Joey Parrish on Slack:

As long as EME is configured before you append the first init segment, the transition later to an encrypted init segment just works. And Shaka Player always sets up EME if you have configure a license server.

On some platforms (Tizen & Xbox, I'm looking at you), we have to modify the first init segment to signal encryption. There is logic in Shaka Player to do exactly this when we detect platforms where this is known to be necessary.

At first glance, it looks like Shaka Player is probing the support with various configurations for requestMediaKeySystemAccess and then chooses the right MediaKeySystemAccess object to create the Media Keys and the Media Key Session once needed.

We are currently calling requestMediaKeySystemAccess once, we want to play a period with ContentProtection elements.

I need to investigate this further and will move it to a later release for now as it seems to require a larger rewrite of our DRM logic.