dual-DRM possible?

[axiomatic-systems]

dual-DRM possible?

[barbibulle]

This can be done easily using both the --widevine and --playready options of the mp4-dash tool.
(both options have associated arguments for fine tuning, see the 'Encrypting the Media' section on http://www.bento4.com/developers/dash/

[kyungtae-K]

I used next command

mp4-dash.py
-f
-d
-o C:/enc/
--widevine
--playready
--widevine-header "#CAESEIgGA99tRV9QmnnAIBTgoUMaDXdpZGV2aW5lX3Rlc3QiBAEjRWcqAkhEMgA="
--encryption-key 880603df6d455f509a79c02014e0a143:6f0b0f06e536e4d71613974afac1c2ab
--playready-header=LA_URL:http://myPlayReadyLicenseServerUrl/rightsmanager.asmx
--mpd-name=sintel.mpd
--use-segment-timeline
--profiles=on-demand
E:/dash.mp4

In WideVinePlayer it will play, but, PlayReadyPlayer don't play.

some example command source please.

[barbibulle]

A few questions:

• what player are you using to test?
• are you sure that your PlayReady server is configured to return the correct key for the KID used here? (one common issue with PlayReady software is that MS often treats things like KIDs as GUIDs in little-endian format, so the way it represents KIDs is swapped.

[kyungtae-K]

Widevine Player(Chrome) : http://shaka-player-demo.appspot.com/
PlayReady Player(win8.1 / IE11 ): http://demo.unified-streaming.com/players/dashjs/index.html, http://dash-mse-test.appspot.com/decoder-test.html

my PlayReady(SDK v2.1) License Server set :
DB Insert KeyID in to the managing Table

GUID "880603df-6d45-5f50-9a79-c02014e0a143"

and

LicenseIssue.ContentKey = AESContentKey(6f0b0f06e536e4d71613974afac1c2ab, 880603df6d455f509a79c02014e0a143)

License issuing success.
but don't playing.
I did create the wrong licensing process?

[barbibulle]

I'm not familiar with how the PlayReady License Server SDK works, but what I can see here is that the GUID "880603df-6d45-5f50-9a79-c02014e0a143" is probably in the wrong byte order. MS likes to byte-swap integers, and in most of their APIs, things like GUIDs are in 4/2/2/8 form, so the KID 880603df6d455f509a79c02014e0a143 would be represented as: df880306-456d-505f-9a79c02014e0a143.
The key value itself, not being treated as a GUID, doesn't need to be byte-swapped.

Also, the function AESContentKey looks like it takes the KID as a parameter. I suspect this is the function that derives an AES key from a "key seed" and a KID (this is standard with PlayReady). (see the pr-derive-key.py utility in the Bento4 distribution for details). If that's the case, the return value of this function is not the encryption key you want here. Your encryption key here is already known (6f0b0f06e536e4d71613974afac1c2ab), so you don't need to derive it. So your LicenseIssue.ContentKey should be this key directly, not a key derived by calling AESContentKey(6f0b0f06e536e4d71613974afac1c2ab, 880603df6d455f509a79c02014e0a143)

If you have the wrong content key returned in the license, you won't see an error when the license is acquired, but nothing will play, as the client will have a valid license, but with the wrong key.

[kyungtae-K]

I understand generate process and encrypt.

pr-derive-key.py :
result =

mp4-dash.py
-o C:/enc/
--encryption-key=:
--playready-header=LA_URL:http:///rightsmanager.asmx
--mpd-name=dash.mpd
--use-segment-timeline
--profiles=on-demand
C:/dash.mp4

get success License and playing.
It's only playready DRM.

how to use widevine and playready dual drm?
may be PlayReady and Widevine to use same , but is diffrent.

[barbibulle]

If you encrypt with the derived key (the key you obtained using pr-derive-key passing the seed and KID), then you will also need to make sure that your Widevine server returns a license with the same key (and use both --widevine and --playready option with mp4-dash.py)

[kyungtae-K]

I think I've learned a lot.
Thank you for your quick response. :)