IIS 7 and Above
Use different content key in Transform Manager PlayReady Protection T...
Last post Aug 10, 2020 04:03 AM by unext-wendong
Aug 10, 2020 04:03 AM|unext-wendong|LINK
In our current content packaging pipeline, we are using the following workflow with regards to Smooth Streaming:
The encoding/transcoding of the content and the encryption of the content are being done as two steps by two different programs. This has been working fine for us.
Recently we are planning to combine these two steps into one, as we know that Transform Manager has a built in PlayReady Protection Task which can be chained after the encoding task, which would allow us to use one job template to generate encrypted Smooth
Streaming from video files.
Our questions is: by reading the document Encrypting On-Demand Smooth Streams, it seems the configuration of the PlayReady
Protection Task requires fixed content key or key seed, which means all the contents would be using the same content key or key seed. Is this understanding correct?
We are looking for a way in which we can encrypt different content with different content keys or key seeds. In the document above, there is a Note which seems to provide we need, but unfortunately the link there is no longer valid.
You can specify keyID and keySeedValue values in the Smooth Streaming presentation server manifest (.ism) file content header to override the property values in the
PlayReady Protection task definition. This provides another option to ensure that your Smooth Streaming presentations are uniquely identified for licensing purposes. For more information, see William Zhang's blog,
How to add PlayReady protection in a Transform Manager job template.
We then searched in this forum and found the following thread:
According to this thread, we can achieve this (applying different content key to different contents) by providing the DRM content key metadata in the ism content file. However, since it's not clear from that thread how we can actual do it, could you please
confirm if the following understanding is correct?
Regarding the format of the DRM metadata in the ism file, is the sample in the following post still valid?