GNOME Bugzilla – Bug 784129
event: make DRM system id optional in GST_PROTECTION event
Last modified: 2018-09-05 15:32:51 UTC
I am working to add suppot for content encrypted with protection API like was done in qtdemux. In Matroska/WebM, we don't have the DRM system id in ContentEncryption element, only the KeyID. The DRM system id hasn't been specified neither in Matroska nor in WebM spec.
Created attachment 354313 [details] [review] Patch: make DRM system id optional in GST_PROTECTION event
If you only have the key id, how do you know which protection system to use? Is it always Google's Widevine ?
For the moment, when we have only keyid the protection system is either Widevine or Clearkey. In EME: The JS application can choose the protection system, then we can choose the right decryptor element. In playbin: We can use the rank, if we prefer a decryptor element than an other. For me if the mimetype is webm/mkv and the widevine decryptor element available, i'll choose widevine.
Why do you want to not put the DRM system ID into the event though? You know it, so you can as well put it into the event :) This might be related to https://bugzilla.gnome.org/show_bug.cgi?id=770107 ?
(In reply to Sebastian Dröge (slomo) from comment #4) > Why do you want to not put the DRM system ID into the event though? You know > it, so you can as well put it into the event :) > As i answered to Olivier. In Webm/Matroska encryption metadata don't have the DRM System ID. In my case, we always choose Widevine, but I can't set it as system DRM in matroskademux, because it can be an other DRM system encryption, like ClearKey. > This might be related to https://bugzilla.gnome.org/show_bug.cgi?id=770107 ? Yes is related, If i understood, they suggest to set many system DRM ID in the protection Event. I think, in long term, we should support all these cases: without or with one or many system DRM.
(In reply to y.bandou from comment #5) > (In reply to Sebastian Dröge (slomo) from comment #4) > > Why do you want to not put the DRM system ID into the event though? You know > > it, so you can as well put it into the event :) > > > > As i answered to Olivier. > > In Webm/Matroska encryption metadata don't have the DRM System ID. > > In my case, we always choose Widevine, but I can't set it as system DRM in > > matroskademux, because it can be an other DRM system encryption, like > ClearKey. How would a decryptor distinguish between them then, how would a decryptor know which DRM system is used or how could we make sure the correct decryptor that supports the required DRM system is used in the pipeline? That seems like something missing in the Matroska spec
(In reply to Sebastian Dröge (slomo) from comment #6) > (In reply to y.bandou from comment #5) > > (In reply to Sebastian Dröge (slomo) from comment #4) > > > Why do you want to not put the DRM system ID into the event though? You know > > > it, so you can as well put it into the event :) > > > > > > > As i answered to Olivier. > > > > In Webm/Matroska encryption metadata don't have the DRM System ID. > > > > In my case, we always choose Widevine, but I can't set it as system DRM in > > > > matroskademux, because it can be an other DRM system encryption, like > > ClearKey. > > How would a decryptor distinguish between them then, how would a decryptor > know which DRM system is used or how could we make sure the correct > decryptor that supports the required DRM system is used in the pipeline? > > That seems like something missing in the Matroska spec Yes I agree, I think there is a miss in the Webm spec.
Making the ID optional is also API breakage: bindings can currently assume that the ID is never NULL and map them to a non-nullable type.
(In reply to Sebastian Dröge (slomo) from comment #8) > Making the ID optional is also API breakage: bindings can currently assume > that the ID is never NULL and map them to a non-nullable type. I close this bug, we don't need this patch with the latest patch that was sent in bug 765275, setting the systemId "UNDEFINED" or something similar.
(In reply to y.bandou from comment #9) > I close this bug, we don't need this patch with the latest patch that was > sent in bug 765275, setting the systemId "UNDEFINED" or something similar. I think it is a bad idea to not change the API or create new functions to create and parse an event without the key system. I understand that the WebM spec can be wrong but it is what it is now and we should be able to work with it without this hack. If we decide there is no other possibility, then I think we should declare something like: #define GST_PROTECTION_EVENT_UNSPECIFIED_KEY_SYSTEM "unspecified.gstreamer.org" and then using this in the clients.