Multi-Period with mixed encrypted and unencrypted periods

[baconz]

I have a multi-period manifest wherein some periods can contain encrypted adaptation sets, and other periods have unencrypted adaptations sets. It seems that filterPeriods lets unencrypted streams through even when a key system has been selected:

      var match = streamSet.drmInfos.length == 0 ||
                  streamSet.drmInfos.some(function(drmInfo) {
                    return drmInfo.keySystem == keySystem; });

I'm not sure if this is by design -- is the sourceBuffer supposed to figure out that a segment is unencrypted if it doesn't have the cenc boxes?

At any rate, right now I get failed fetch and append: code=3015 with Failed to execute 'appendBuffer' on 'SourceBuffer': The HTMLMediaElement.error attribute is not null. when the player tries to append the unencrypted content.

[joeyparrish]

Unencrypted content is allowed by design. Imagine you have a piece of content with encrypted video streams but unencrypted audio. No encrypted AdaptationSets for audio are available. There's no reason this should be disallowed. Note that this filtering based on key system is independent of multi-period considerations.

With multi-period, things get more complicated. In particular, because we must change init segments when we change periods.

An encrypted stream can have unencrypted blocks. You can package the first several seconds in the clear to allow time for license acquisition, for example. The init segment still indicates that the content is encrypted, and as I understand it, the browser's media stack can tell that individual segments are or are not encrypted and decrypt them as needed.

So in theory, there should be no issue with initializing the decoder for encrypted content, then appending unencrypted content. If your first period was encrypted and the second period clear, one could easily imagine a browser that could still decode this.

Chrome, however, does not support changing from encrypted to unencrypted (or vice-versa). When the init segment for the second period is appended, Chrome rejects it. chrome://media-internals will show something like "audio encryption changes not allowed". We reported this in http://crbug.com/597443 and were told that this is working-as-intended for Chrome.

Shaka has no way to detect if a given browser supports this scenario or not, so there's no simple way to reject the content on browsers that can't play it. We could disallow this completely, but some other browsers do support it.

If this is something you need, my recommendation is that you report the issue to Chrome and detail why support for this is important to your application. Feel free to reference the existing crbug and/or this github issue for history.