<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"><style type="text/css">body { background: rgba(255, 251, 247, 255); }</style></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div><blockquote type="cite" class=""><div class="">On 30 Jun 2015, at 12:49, Julien Isorce <<a href="mailto:julien.isorce@gmail.com" class="">julien.isorce@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class=""><div class=""><div class=""><div class=""><div class=""><div class=""><div class=""><div class="">Hi,<br class=""><br class=""></div>I am not sure if clearkey allow you to access the raw video data after decryption and decoding.<br class=""></div></div></div></div></div></div></div></div></div></blockquote><div><br class=""></div>I don’t think clear-key has strong requirements in that regard. It’s not meant to be used for real deployments, as far as I know.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><div class=""><div class=""><div class=""><div class=""><div class="">If not you I know only 2 solutions:<br class=""><br class=""></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 class="">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 class=""></div><div class="">It will allow to safely manipulate gltexture ids in webkit compositing engine.<br class=""></div><div class="">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 class=""></div><div class=""><br class=""></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" class="">https://bugs.webkit.org/show_bug.cgi?id=141560</a><br class=""><br class=""></div><div class="">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 class=""></div><br class=""></div></div></div></div></div></blockquote><div><br class=""></div>Yes, the CDM would request decryption keys and pass them to the decryptor, using an OOB event, for instance.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><div class="">What will be the sink and src caps for this GStreamer ClearKey decryptor ?<br class=""><br class=""></div></div></div></div></blockquote><div><br class=""></div><div style="margin: 0px;" class="">application/x-cenc, original-media-type=(string)video/x-h264, protection-system=(string)58147ec8-0423-4659-92e6-f52c5ce8c3cc</div><div style="margin: 0px;" class=""><br class=""></div><div style="margin: 0px;" class="">and video/x-h264</div><div style="margin: 0px;" class=""><br class=""></div><div style="margin: 0px;" class="">Same with audio/mpeg.</div><div style="margin: 0px;" class=""><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">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 class=""><br class=""></div>I really wonder how iOS does support/implement EME ? (hole or driver)<br class=""><div class=""><br class=""></div></div></div></blockquote><div><br class=""></div>Maybe ask in webkit-dev :)</div><div><br class=""></div><div>Philippe</div></body></html>