DASH manifest with multiple DRM/ContentProtection entries (playReady and wideVine) fails

[GoogleCodeExporter]

The following seems to be an issue with the media-player.js version 1.0.0:

If a dash-manifest contains ContentProtection entries for both PlayReady and 
Widevine, the order of which they appear in the manifest seems to determine the 
payload of the license request. If I have specified a widevine license url in 
the sender application, the license request still contains a PlayReady payload 
when the PlayReady ContentProtection entry appears before the Widevine entry in 
the manifest. If I switch the order of the ContentProtection entries in the 
manifest, the request payload changes as well, and the stream plays as expected.

In our scenario, we need multiple ContentProtection schemes in the manifest in 
order to support different streaming-protocols/DRM-technologies on different 
platforms. 

This applies to an implementation of a Google Cast Custom Receiver using 
media-player.js v1.0.0

Original issue reported on code.google.com by havard@vimond.com on 17 Jun 2015 at 9:14

[GoogleCodeExporter]

MPL will try supported content protections systems based on the order listed in 
the manifest.  MPL assumes that since it's listed in the manifest, the 
application should be able to acquire the license for it. One possible 
workaround would be for the application to use host.processManifest override to 
remove the content protection system that it doesn't want MPL to use from the 
manifest: 
https://developers.google.com/cast/docs/reference/player/cast.player.api.Host#pr
ocessManifest. Alternatively, you can order the entries such that the one you 
want to use is listed first. We will consider implementing support for multiple 
DRM entries.

Original comment by jonathan...@google.com on 17 Jun 2015 at 11:54

• Changed state: Acknowledged
• Added labels: Priority-Medium, Type-Enhancement
• Removed labels: Priority-High, Type-Defect

[GoogleCodeExporter]

Thanks. Got it working by using host.processManifest()

Håvard

Original comment by havard@vimond.com on 18 Jun 2015 at 10:56