[Bug 761700] basedrm: a base class based on CENC common encryption scheme for DRM playback

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=761700

Krzysztof Konopko <krzysztof.konopko at konagma.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |krzysztof.konopko at konagma.c
                   |                            |om

--- Comment #20 from Krzysztof Konopko <krzysztof.konopko at konagma.com> ---
I really like the idea and I think it's the right approach and I appreciate the
effort of submitting the proposal.

I'm not going to review it in details though (I'd have some comments) because I
think there are major design problems.

First of all, as some have already mentioned, it's PlayReady specific.  I'd
even say that it's actually PlayReady SDK specific.

Each DRM system has its own specification(s) and everyone can implement every
aspect of it on their own and go through a certification process.  But let's
face it: hardly anyone wants to do that and rather "reference" libraries (SDKs)
are used.  So what we are dealing with here are really various aspects of
different DRMs and "blessed" SDKs.

* no key rotation support

You seem to have been dealing with PlayReady WRM licenses of version < 4.1
which do not support multiple keys and binding a license means the only key is
set up automatically.  But CENC supports a different KID for each sample, which
may or may not change on every buffer/sample.  In the Clear Key implementation
you have an attempt to at least support separate KIDs for audio and video but
each track may have rotating keys.

Thereby, a base class should provide KID information for each buffer/subsample,
something like `void (*load_key)(GstBaseDrm * basedrm, GBytes * key, GBytes *
iv)`.

* different DRM (SDKs) deal with license acquisition and decryption differently

PlayReady requires a client app to participate in license acquisition and to
make requests to a license server.  The PlayReady SDK only deals with the
header, challenge, response, ack. and ack. response.  Also PlayReady SDK
handles decryption.

On a contrary, Marlin SDK for example does the entire license acquisition
internally and require a client app to do the decryption.

The decryption bit is not a big problem as there's a separate `decrypt()`
method proposed so the implementing classes can be built with or without
accelerated decryption implemented inside or outside DRM SDK, as required.

The license acquisition bit could be something like `bool (*acquire_license)
(GstBaseDrm * basedrm, GBytes * license_info, GBytes * default_key_id)` where
the implementation of the base class needs to handle `license_info` specific to
the implemented DRM system (SDK).

* no DME scatter-gather support

Again, the "block offset" approch seems PlayReady specific but some
implementations may want to use scatter-gather approach and need to know when
the base class is done with the sample, so for example:  `void (*decrypt)
(GstBaseDrm * basedrm, guint8 * data, gsize size)` and `void
(*decrypt_finish)(GstBaseDrm * basedrm)`.

* this is CENC specific

The proposal is for `GstBaseDrm` but it should be rather something like
`GstBaseCencDec` as it's not universal enought to represent any DRM system,
although I'd like to also see support for example for Marlin MPEG-2 TS which
requires additional signalling.

* CENC for MPEG-2 TS support

I don't know much about CENC specifically in the context of MPEG-2 TS but I
don't see how this proposal supports that directly without additional elements
upstream in a pipeline doing MPEG-2 TS parsing, handling additional signalling
and decorating outgoing buffers with `GstProtectionMeta`.  Presumabely there
needs to be an element to reassembles PES and decorate each AU with
`GstProtectionMeta`?  I wonder then what role of `GstBaseDrm` would be if
MPEG-2 TS processing (filtering/signalling and decoding) is hardware assisted. 
Not to mention other DRM SDKs like Marlin one which may handle MPEG-2 TS (PAT,
PMT and ECM) signalling and ECM parsing internally.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.