in an earlier post of mine (http://forums.adobe.com/message/4364896) it was stated that the content encryption key was derived from the common-key and the Content ID.
Now, I've been experimenting some with this, inserting a proxy doing some filename translations between the client and the actual server, any requests containing "999x222Seg*" gets rewritten to "999y222Seg*", i.e. a different filename. Both "999x222.mp4" and "999y222.mp4" exists on the server.
Client requests /hds-vod/999x222.mp4.f4m, proxy forwards exactly the same. Server sees 999x222_1400.mp4.f4m as filename, and the drmAdditionalHeader is set to drmContentId="999x222.mp4" as expected
Now, the client requests /hds-vod/999x222.mp4Seg1-Frag1 as expected. This is however translated in the proxy, and the server will see a request for /hds-vod/999y222.mp4Seg1-Frag1, i.e. NOT the same filename as the manifest was issued for, and thus not the same content ID (?), which would mean another content encryption key would be used.. However, the client is still able to play the video!
From my understanding, that should not be possible? 999x222.mp4 and 999y222.mp4 are two different files, two different content IDs, and should thus have two different content encryption keys. The key from the initial manifest should only be able to decrypt the fragments from 999x222, not 999y222?
FMIS 4.5.2 is used, and the default /hds-vod PHDS config is used, with protection specifics as follows:
Can anyone shed some light on this?
the default Apache config is used, the only changes made are in the hds-vod section, which reads:
Options -Indexes FollowSymLinks
One more thing, which might or might not make a difference. 999x222.mp4 was one file, and 999y222.mp4 was a symlink to the first file, rather than a truly standalone file.
By default, FMS uses non-unique content-id if protection-scheme is set. It takes path of the file as its content-id. Therefore, in your case, it takes same content-id for both files as they are kept in same folder. This was introduced so that same content-id encryption can be used for multi-bitrate stream where all files with different bit rate are kept in same folder.
If you want to use unique content-id for each file, please include this tag in ur httpd.conf file.
By default, this is set as false.
Also, If you want to specify some content-id (for example: 'my-content-id') to be used as content-id for all the files, please use this tag. Also, donot set FlashAccessUseUniqueContentID to true.
aha, that explains it. Setting FlashAccessUseUniqueContentID to true did the trick.
The m4f manifest for one single mp4 file has an drmAdditionalHeader with drmContentId="999x222_1800.mp4", i.e. the full filename, not including the path. This is the same regardless of the UseUniqueID setting. Bug?
Does the server or client benifit in any way of using a shared content ID for all the bitrates? The encryption metadata is sent in every m4f manifest (one per bitrate) anyway, correct? Since the drmContentId is different for all the files, I'd expect that the client has to decode the full drmAdditionalHeader element even though it's using the same key?
From what I've found in the docs, there is no mentioning of any of those two options, nor the fact that the same key is used for all files in a directory.
Are there any more undocumented quirks/features like this?
Europe, Middle East and Africa