Reuse secure decoder while moving from secured -> clear -> secure content

[mikulbhatt]

We observe that the decoder deinit and reinit while moving from secured to plain content and plain to secure content.

Is there a way to signal exoplayer so we can avoid de-init and re-init of decoder and ask MediaCodecRenderer to reuse the secured decoder for clear content?

[ojw28]

For your use case, does the secure content before and after the clear content use the same keys (e.g. is this like inserting a clear ad into a VOD stream)? Or would the second piece of secure content need a new license request?

[mikulbhatt]

@ojw28 yes they use the same key, yes its inserting a clear ad into a live stream, and the content of live stream has same key before and after the clear ad

[mikulbhatt]

also since the drm key and license remain same in and out of AD playing secured content. I want to avoid refetching license keys everytime.

[ojw28]

A few problems we face here are from the point of view of implementing a general solution are:

1. Not knowing if the second secure period will use the same keys. In some cases that period might not even be present in the manifest at the point of transitioning into the clear period, so it's unclear whether we should hold the session open or not (and if we do, should we actively refresh the keys, and when should we give up and close it).
2. If the user joins the stream during ads, it's possible we wont even know any part of the content is secure, and so will (correctly) initialize a non-secure decoder. I can't see much we can do to avoid at least one decoder re-init in this case, when we encounter the first period containing secure content.

Are you aware of any signalling in the DASH manifest to help with this? I'd rather not have the application side-load all this information, since it feels like something the content should be able to tell us directly.

[TheJohnBowers]

The PSSH data for key is unique per key, so if you get new unique PSSH data in the manifest that could be considered a manifest signal that the key has changed. You could keep using the the secure decoder until you see an new unique PSSH element in the manifest.

In the second case I could see being unable to determine that a secure period would come in the future in that case I think you are right, at least one re-init would be required.

[TheJohnBowers]

So what do you think about the idea of detecting the need for a new license by watching PSSH blocks and associating them with licenses? As soon as a new one pops into the live window you could send the license request, but if there isn't a new one for a period because a) The period didn't have one at all or b) because it didn't change -- Then you would keep using the existing license until it expires.

[ojw28]

I think this is one thing we're planning to do, except "as soon as a new one pops into the live window" is something more like "as soon as we start to buffer it" / "X seconds before we're going to play it".

[mikulbhatt]

yes, agreed! thats what we want @ojw28 . Let us know of any updates on this thread! thanks 👍

[mikulbhatt]

@ojw28 any update on this, is it being prioritized? thanks.

[BetweenTwoBits]

@tonihei any update on this issue?