[webkit-gtk] Encrypted Media support

[Julien Isorce]

Hi,

I am not sure if clearkey allow you to access the raw video data after
decryption and decoding.
If not you I know only 2 solutions:

- decoder and renderer can be setup to support DRM. I think a such setup
can only happen at driver level. And ideally CPU should not be able to
access this raw data.
In the case of HW decoder and GL driver it will prevent to download the
gltexture. For ex: you get a blackframe, same if you try to read back the
content of the framebuffer.
It will allow to safely manipulate gltexture ids in webkit compositing
engine.
I do not know if there are such existing GPU drivers. I remember seeing
some DRM structure members in openmax platform specific headers on
Raspberry-Pi but not sure if this is related and/or usable.

- if the platform does not support DRM, it should fallback to video hole
punching. A third-party will have to provide a gst element that implements
these GStreamer DRM interfaces/meta. DRM support in GStreamer should be
such that it allows to do that :) In that maybe we can revive this patch:
https://bugs.webkit.org/show_bug.cgi?id=141560

I am not sure how CDM comes into the game but I guess this is the API that
will connect EME javascript API to the gstreamer media player.

What will be the sink and src caps for this GStreamer ClearKey decryptor ?

As far as i know video hole punching is the technique used by chromium to
support EME (I think video hole has been introduced in chromium in the
first place to have EME on Android)

I really wonder how iOS does support/implement EME ? (hole or driver)

Cheers
Julien


On 30 June 2015 at 10:33, Philippe Normand <philn at igalia.com> wrote:

> On Tue, 2015-06-30 at 11:19 +0200, Xabier Rodríguez Calvar wrote:
> > O Mar, 30-06-2015 ás 11:02 +0200, Philippe Normand escribiu:
> > > - disable EME in default production build
> > > - downstream users would need to enable it if they need it
> > > - add a GStreamer ClearKey decryptor in platform/graphics, that
> > > would
> > > depend on GStreamer >= 1.5
> > > - other DRM systems would need to be handled by downstream users
> > >
> > > The reason why this would depend on very recent GStreamer versions
> > > is
> > > that DRM support in upstream GStreamer was recently added.
> >
> > My only concern here is you have also planned to bump GStreamer
> > requirement in internal JHBuild to 1.5 too. We might also want to add
> > some compilation check for GStreamer 1.5 and fail in case it is not
> > present.
> >
>
> I don't plan to bump the GStreamer version in JHBuild until 1.6 is
> released, at least :) Also we should bump the required version in the
> CMake build, currently we depend on 1.0.x, so at some point we should
> bump that as well and maybe clean-up the unused code paths, but that's
> another discussion :)
>
> About EME, yes, I'll make the CMake stuff error out if EME is enabled
> but GStreamer >= 1.5 isn't present.
>
> Philippe
> _______________________________________________
> webkit-gtk mailing list
> webkit-gtk at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-gtk
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-gtk/attachments/20150630/338f69ae/attachment.html>