<div dir="ltr"><div><div><div><div><div><div><div><div>Hi,<br><br></div>I am not sure if clearkey allow you to access the raw video data after decryption and decoding.<br></div>If not you I know only 2 solutions:<br><br></div>- 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.<br>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.<br></div><div>It will allow to safely manipulate gltexture ids in webkit compositing engine.<br></div><div>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.<br></div><div><br></div>- 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: <a href="https://bugs.webkit.org/show_bug.cgi?id=141560">https://bugs.webkit.org/show_bug.cgi?id=141560</a><br><br></div><div>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.<br></div><br></div>What will be the sink and src caps for this GStreamer ClearKey decryptor ?<br><br></div>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)<br><br></div>I really wonder how iOS does support/implement EME ? (hole or driver)<br><div><br><div><div><div><div><div><div>Cheers<br></div><div>Julien<br><br></div></div></div></div></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 30 June 2015 at 10:33, Philippe Normand <span dir="ltr"><<a href="mailto:philn@igalia.com" target="_blank">philn@igalia.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Tue, 2015-06-30 at 11:19 +0200, Xabier Rodríguez Calvar wrote:<br>
> O Mar, 30-06-2015 ás 11:02 +0200, Philippe Normand escribiu:<br>
> > - disable EME in default production build<br>
> > - downstream users would need to enable it if they need it<br>
> > - add a GStreamer ClearKey decryptor in platform/graphics, that<br>
> > would<br>
> > depend on GStreamer >= 1.5<br>
> > - other DRM systems would need to be handled by downstream users<br>
> ><br>
> > The reason why this would depend on very recent GStreamer versions<br>
> > is<br>
> > that DRM support in upstream GStreamer was recently added.<br>
><br>
> My only concern here is you have also planned to bump GStreamer<br>
> requirement in internal JHBuild to 1.5 too. We might also want to add<br>
> some compilation check for GStreamer 1.5 and fail in case it is not<br>
> present.<br>
><br>
<br>
</div></div>I don't plan to bump the GStreamer version in JHBuild until 1.6 is<br>
released, at least :) Also we should bump the required version in the<br>
CMake build, currently we depend on 1.0.x, so at some point we should<br>
bump that as well and maybe clean-up the unused code paths, but that's<br>
another discussion :)<br>
<br>
About EME, yes, I'll make the CMake stuff error out if EME is enabled<br>
but GStreamer >= 1.5 isn't present.<br>
<div class="HOEnZb"><div class="h5"><br>
Philippe<br>
_______________________________________________<br>
webkit-gtk mailing list<br>
<a href="mailto:webkit-gtk@lists.webkit.org">webkit-gtk@lists.webkit.org</a><br>
<a href="https://lists.webkit.org/mailman/listinfo/webkit-gtk" rel="noreferrer" target="_blank">https://lists.webkit.org/mailman/listinfo/webkit-gtk</a><br>
</div></div></blockquote></div><br></div>