Support the generation of PlayReady PSSH with multiple key_ids

[barbarosalp]

I couldn't find a way to package content for PlayReady with multiple key_ids in a pssh that uses wrmheader 4.3.0.0. Could you guide me with any links or documentation? Thanks.

[kqyang]

That is not supported right now.

We need help get this implemented. Here is what we need to do:

• Add an additional boolean flag on whether to generate playready pssh 4.0 or 4.3
• Return true or false depending on the flag and the protection scheme in PlayReadyPsshGenerator::SupportMultipleKeys: https://github.com/google/shaka-packager/blob/981515e6c851e39a62d25cc6b07f4d7e8806e681/packager/media/base/playready_pssh_generator.cc#L162
• Implement PlayReadyPsshGenerator::GeneratePsshDataFromKeyIds. GeneratePlayReadyPsshData needs to be modified to support multiple key ids. https://github.com/google/shaka-packager/blob/981515e6c851e39a62d25cc6b07f4d7e8806e681/packager/media/base/playready_pssh_generator.cc#L183

I am not sure if we still want to support the generation of PlayReady 4.0 PSSH to support old clients. Are there still old PlayReady clients that needs to be supported? @vladimir-kazakov Any comment?

[kqyang]

Link to PlayReady PSSH spec: https://docs.microsoft.com/en-us/playready/specifications/playready-header-specification

[vladimir-kazakov]

I am not sure if we still want to support the generation of PlayReady 4.0 PSSH to support old clients. Are there still old PlayReady clients that needs to be supported? @vladimir-kazakov Any comment?

Difficult to say. On one hand, PlayReady 1 clients are quite old and from the Smooth Streaming / pre-DASH era, so probably they're not relevant anymore (it's highly unlikely that somebody will be using Shaka Packager to create content for them). On the other hand, the 4.0 header is still very popular, even in the recently created content. I think there may be badly implemented clients that still expect 4.0, instead of anything else, but I don't have any real testing data. That said, I don't see a good reason to not support it.

Add an additional boolean flag on whether to generate playready pssh 4.0 or 4.3

I think this feature could be implemented without adding additional flags. For example:

• If a single CTR key is used, use the 4.0 header. The 4.1 header is only interesting if scalable key rotation is needed, but Shaka Packager anyway doesn't support this feature, so there is no good reason to use it and break the support for PlayReady 1 clients.
• If multiple CTR keys are used, use the 4.2 header with a warning that such content will play only on PlayReady 3 clients.
• If one or many CBC keys are used, use the 4.3 header with a warning that such content will play only on PlayReady 4 clients.

[kqyang]

@vladimir-kazakov Thanks for the comment!

I think this feature could be implemented without adding additional flags. For example:

I'd like to understand a little bit more on the PlayReady practices as I know very little about it.

1. In the old days, when working with PlayReady 1 clients, are people always using the same content encryption key for different resolutions and also for audio and video, i.e. using a single CTR key for the content?

2. Can PlayReady 1 client support different keys for different resolutions? Different PSSHs will be used and thus multiple licenses will need to be supported?

If the answer to Q2 is yes, then we'll still need to support generating single-key PSSH when multiple CTR keys are used. Then it seems the best option is to introduce a flag so users can enable or disable it depending on whether there is a need to support legacy PlayReady 1 clients. What do you think?

[vladimir-kazakov]

In the old days, when working with PlayReady 1 clients, are people always using the same content encryption key for different resolutions and also for audio and video, i.e. using a single CTR key for the content?

Yes. In the past, nobody needed an improved security in the form of encrypting every stream differently. All streams in a content were encrypted using the same, single CTR key. I still see it as the most popular way to protect the content nowadays.

There was also a problem of not being able to request multiple keys in a single license request. PlayReady 1 and 2 clients support PlayReady headers that don't allow specifying multiple key IDs. If you needed to protect every stream differently, you would need a header for each stream. A media player then would need to acquire a license for each stream separately, which is not efficient even nowadays. A typical content consist of at least 5 streams, so there may be a noticeable delay before the media player will be able to start playback. Content providers usually try to avoid it.

Can PlayReady 1 client support different keys for different resolutions? Different PSSHs will be used and thus multiple licenses will need to be supported?

Yes, such scenario is supported, although as I already mentioned, it's quite inefficient when using modern content, which consists of many streams.

If the answer to Q2 is yes, then we'll still need to support generating single-key PSSH when multiple CTR keys are used. Then it seems the best option is to introduce a flag so users can enable or disable it depending on whether there is a need to support legacy PlayReady 1 clients. What do you think?

You're right. I forgot to consider this option.

[KarlGallagher]

@kqyang @vladimir-kazakov As per Microsoft spec : https://docs.microsoft.com/en-us/playready/specifications/mpeg-dash-playready

It is possible to insert two content protection tags for PlayReady - one intended for legacy applications and the other for more standards compliant implementations

This could be leveraged to support insertion of version 4.0 and 4.3/4.2 PRO simultaneously

It should be noted that PRO 4.3 is only supported by PlayReady 4.0 clients which don't seem widely deployed yet, so maybe 4.2 is all that's needed for multi keyid support

[kqyang]

@karlg-arris Thanks for the information.

It is possible to insert two content protection tags for PlayReady - one intended for legacy applications and the other for more standards compliant implementations

I don't see it mentioned in Microsoft spec. Can you point to me which section covers that?

It should be noted that PRO 4.3 is only supported by PlayReady 4.0 clients which don't seem widely deployed yet, so maybe 4.2 is all that's needed for multi keyid support

Good point. For AES-CBC, we have to go with PRO 4.3; we can use PRO 4.2 for AES-CTR.

[KarlGallagher]

@karlg-arris Thanks for the information.

It is possible to insert two content protection tags for PlayReady - one intended for legacy applications and the other for more standards compliant implementations

I don't see it mentioned in Microsoft spec. Can you point to me which section covers that?

Section 2.1 and specifically 2.1.2. To clarify, it discusses adding two sub-elements under the PlayReady ContentProtectionDescriptor...

It should be noted that PRO 4.3 is only supported by PlayReady 4.0 clients which don't seem widely deployed yet, so maybe 4.2 is all that's needed for multi keyid support

Good point. For AES-CBC, we have to go with PRO 4.3; we can use PRO 4.2 for AES-CTR.

[kqyang]

Do you mean doing something like this:

<ContentProtection schemeIdUri="urn:uuid:9a04f079-9840-4286-ab92-e65be0885f95" value=”MSPR 2.0”>
    <cenc:pssh>
          <!-- *base64-encoded PlayReady ‘pssh’ complete box with PRO 4.2 or 4.3* -->
    </cenc:pssh>
    <mspr:pro>
          <!-- *base64-encoded PlayReady Object with PRO 4.0* -->
    </mspr:pro>
</ContentProtection>

I think it will be very confusing to players. It is also very difficult for players to handle it correctly.

[KarlGallagher]

@kqyang I do mean that.

I don't think this is confusing at all, given that it is merely specifying what players are already expecting. and implemented against.

Players (mainly embedded types) that were developed against the original Microsoft spec will still require this element and use it if present.

Standards compliant players (ExoPlayer/Shaka/Dash-IF/Theo/Bitmovin) are all currently using the element and will still do so.

Players will not be required to change handling implementation or be 'confused' - this is XML, so they will just ignore the redundant PRO data.

[kqyang]

Re https://github.com/google/shaka-packager/issues/735#issuecomment-611092936, let me clarify my points:

• There are no indications of PRO versions in either <cenc:pssh> or <mspr:pro>.
• Right now standard compliant players always use <cenc:pssh> and legacy non-standard compliant players always use <mspr:pro>.
• On legacy devices or platforms that supports PRO 4.0 only, standard complaint players will not work as <cenc:pssh> contains PRO 4.2/4.3.
• To handle it correctly, the players need to be updated to parse PRO and use <cenc:pssh> or <mspr:pro> depending on whether they are supported by the platform.

An alternative approach is that the users need to remember to always use legacy players on legacy platforms with PRO 4.0 support only and use standard compliant players on new platforms. @karlg-arris Is that what you are suggesting?

[KarlGallagher]

@kqyang Sorry for leaving this but I was dragged into other stuff...

What I am suggesting is based on the following assumptions: 1. tag is intended for backwards compatibility (i.e legacy or non-updatable players) 2.PRO 4.0 is a more generally compatible version of the PlayReady signalling format 3.PRO 4.2 + is required to enable newer PlayReady features - i.e. multi-key 4.Most legacy embedded players for PlayReady require based signalling

On the legacy platform issue - it must be considered: 1.If the platform actually supports using an application layer / web based player solution - many are just support black box, built-in players and based on assumption 4. should continue to work 2.If using PRO 4.3/ and you do want/need to use a custom OSS based or commercial player on a PlayReady based platform that only supports PRO 4.0 you always have an option to customise to your needs - e.g support fallback logic when processing ContentProtection elements - I think this is an edge case though... 3.If you need features only available in PRO 4.2/4.3 then it is unavoidable that you have to deal with compatibility 'sacrifices'

Therefore, in conclusion I think it makes sense that the element carries PRO version 4.0 (only) and ... could be made to support any configurable PRO version 4.0/4.1/4.2/4.3 ..etc Additionally, when PRO version 4.2 + is configured, then all supplied keys should be signalled in the XML (as per spec) Lastly, when 'cbcs' encryption pattern is configured, then PRO 4.3 + is implied.

Hope this makes sense!

[kqyang]

@karlg-arris Thanks for the information. A few follow-up questions.

you always have an option to customise to your needs - e.g support fallback logic when processing ContentProtection elements - I think this is an edge case though...

Are you aware of any OSS based or commercial player supporting the fallback?

I think this is an edge case though...

I know nothing about the deployment status of PRO 4.2. Do you have any data on that?

[KarlGallagher]

@karlg-arris Thanks for the information. A few follow-up questions. are you aware of any OSS based or commercial player supporting the fallback?

I am not aware of any players that do this currently. Although in general, it should not be needed, based on assumption that platforms supporting the requisite APIs for these players should already be using a more up to date PlayReady version.

I know nothing about the deployment status of PRO 4.2. Do you have any data on that?

No real data (I don't work for Microsoft). However the baseline requirement is PlayReady 3.0 SDK (client and server) Based on this : https://docs.microsoft.com/en-us/playready/overview/product-versions It seems like this was released ~ 5 years ago. Most platforms I deal with on a daily basis (Browser/Roku/Post 2017 SmartTV /Custom STB) support PR 3.0+. The problem platforms seem to mostly be custom solutions on legacy STB and/or depreacted SmartTV platforms, which typically are not kept up to date as much, but for those cases we have the 'mspr:pro' tag legacy compatibility mode to fall back on.

[vish91]

@kqyang any thoughts on what work is still needed and guidance on how to implement that like you mentioned before ? would like to try this out and see if we can help implement this . @cosmin @joeyparrish ^