add multi-DRM use-case
Now there is one Widevine use-case, we should consider adding the following;
MPD with both PlayReady and Widevine
- Only PlayReady license requested & installed
- Only Widevine license requested & installed
- Both PlayReady and Widevine license requested and installed
Both MSE/EME and native player With and without calling the setActiveDRM method (A.2.27)
From the December 1st IITF meeting, Widevine + native player is not defined. MSE+EME is preferred/required for Widevine. What would be a pass / success? In principle, anything other than a crash would be a pass. Fail with 'DRM not supported' would be a pass. Successful playback would be a pass. Fail with 'no license' might be a pass.
Normal manifest with multiple drm signals
- use a fully working laurl baked in a mpd,
init.mp4/psshbox may carry a non-working placeholder laurl. - laurl should point to
laurl_pr.php, laurl_wv.phpproxy script so that it never changes from the player point of view, script can use up-to-day expressplay token for widevine and microsoft test server for playready. - this also gives a hint which drm was selected by the device
- enable test content for hbbtv1, hbbtv2 and mseeme RefApp modes
AdaptationSet1(video): 3* resolutions (640p, 720p, 1080p)
- <ContentProtection> for Playready and Widevine
AdaptationSet2(audio): 1* bitrate(128Kbit), eng, (aac 48Khz)
- <ContentProtection> for Playready and Widevine
AdaptationSet3(audio): 1* bitrate(128Kbit), fin, (aac 48Khz)
- <ContentProtection> for Playready and Widevine
AdaptationSet4(audio): 1* bitrate(128Kbit), swe, (aac 48Khz)
- <ContentProtection> for Playready and Widevine
Use oipfDrmAgent.setActiveDRM(drmSystemID | "urn:hbbtv:oipfdrm:inactive" | null) method, maybe adding a menu actions to set playready, widevine, inactive, null state? NULL value resumes back to a device's default behaviour.
@jpiesing
Do devices automatically reset oipf.setActieveDRM settings if hbbtv app was destroyed (channel switch etc...)?
Something else in mind for manifest structure? One Multi-DRM test manifest as described above and four Set ActiveDRM menu actions should do the job?
Do devices automatically reset
oipf.setActieveDRMsettings if hbbtv app was destroyed (channel switch etc...)?
The spec says until ... the application stops for any reason.
Something else in mind for manifest structure? One
Multi-DRMtest manifest as described above and fourSet ActiveDRMmenu actions should do the job?
I'll send you an example MPD.
This is what I had in mind, ....
A new tab for "multi-DRM, PlayReady and Widevine" with perhaps the following.
7.1 PlayReady license requested, setActiveDRM not used 7.2 Widevine license requested, setActiveDRM not used 7.3 PlayReady and Widevine licenses both requested, setActiveDRM not used 7.4 PlayReady license requested, setActiveDRM used 7.5 Widevine license requested, setActiveDRM used 7.6 PlayReady and Widevine licenses both requested, setActiveDRM used
@jpiesing ok thanks, saying PlayReady|Widevine|Playready+Widevine license requested means one or both signalled in a <ContentProtection> manifest element and PSSH box in init.mp4 files.
7.6 PlayReady and Widevine licenses both requested, setActiveDRM used
Manifest+init.mp4 signalling both drm elements, we actually would like to have?
a) Playready+Widevine signalled, setActiveDRM(Playready_sysid)
b) Playready+Widevine signalled, setActiveDRM(Widevine_sysid)
Then it's up to a device decision with an optional help of oipfDrmAgent.setActiveDRM() invocation to choose drm system.
This set of tests should not use sendDRMMessage() to override laurl value at runtime, instead manifest should carry a working laurl value, it ok to write a placeholder laurl in init.mp4/pssh box as it's very rigid element in cdn file deliveries.
DRMSystemId values
playready=urn:dvb:casystemid:19219 | widevine=urn:dvb:casystemid:19156 | marlin=urn:dvb:casystemid:19188
Currently most drm test cases we already have do signal multiple drm elements (playready, widevine, marlin) but no setActiveDRM() function being used.
Device is instructed to use an appropriate laUrl by invoking oipfDrmAgent.sendDRMMessage(msgType, laUrlOverrideXml, drmSysId) function. This happens before playback is started and after a playback laUrlOverrideXml with an empty laurl field is sent to clear an overridden laurl value.
See http://refapp.hbbtv.org/staging/catalogue/ 7.1-7.3
Staging app has 7.1 - 7.6 test cases for oipfDrmAgent.setActiveDRM(sysId) testing.
- Manifests have a working LaUrl license address, tests cases do not use the laurl-override methods.
- Widevine manifest has
<dashif:laurl>https://...</dashif:laurl>element. - Playready manifest has laurl inside the
<mspr:pro>,<cenc:pssh>element. - None of the init.mp4 segments have
PSSHdrm box to make sure players don't use it and call the bogus laurl address. - At the end of playback
oipfDrmAgent.setActiveDRM(null)is invoked to reset the drm to a default state.
https://refapp.hbbtv.org/staging/catalogue/
I believe this is ready for first feedback @jpiesing @bobcampbell-eurofins documentation to be updated from the information from this ticket
We'll leave this open so people are aware its available and can try it out
Staging has an updated 7.1 - 7.6 MultiDRM oipfDrmAgent.setActiveDRM(sysid) test cases.
https://refapp.hbbtv.org/staging/catalogue/
Manifests don't have an embedded LaUrl anymore, manifest contain just <ContentProtection> elements to signal availability of drm systems.
- Application is using a laurl override method to submit an active laurl.
- init segment has just an appropriate PSSH tables (playready only, widevine only, both), previous tests did not write any PSSH tables.