[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

--- Comment #23 from Krzysztof Konopko <krzysztof.konopko at konagma.com> ---
> So seems the DRM SDK should responsible for video ES parsing. Is it right? But 
> video decoder will do those kind of video ES parsing, so it is duplicate
> effort. How to balance those video ES parsing loading?

In this case only ECM PID needs to be parsed so there's no duplication of
effort if a GStreamer element does that.  DRM SDK in this case is merely
responsible for providing ECM PID based on information in PAT/PMT (as this may
be DRM specific) and for the actual ECM _payload_ parsing (not ES parsing).  In
this situation it's GStreamer element feeding DRM SDK with PAT/PMT and ECM
payloads.

The situation is different if decryption needs to be done in the H/W as well
and in case of MPEG-TS usually demuxing already happens in H/W.  It's a bit
tricky as ECM signalling must be aligned with what's in demuxer's buffer as the
stream is far from being framed, so not visible really in GStreamer pipeline. 
In this case H/W demuxer would need to provide similar PAT/PMT and ECM
signalling (with payloads).

> As license acquisition need access socket. Maybe has problem on Android 
> platform which need authority for socket access. Application has the authority, 
> but DRM plugin maybe haven't the authority.

What do you mean by "access socket"? In case of Marlin SDK it's "merely" a TCP
socket with all TLS and HTTP(S) done by the SDK.  If you think of it as the
"authority" to access network then it's a fair point as it's not desired for
the DRM part to do much of networking but this is the approach taken by Marlin
SDK.  PlayReady makes the app responsible for this instead.  A matter of choice
I guess and trust in the implementation robustness.

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