<html>
<head>
<base href="https://bugs.webkit.org/" />
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - [GTK][GStreamer] ClearKey EME v1 decryption support"
href="https://bugs.webkit.org/show_bug.cgi?id=154235#c24">Comment # 24</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - [GTK][GStreamer] ClearKey EME v1 decryption support"
href="https://bugs.webkit.org/show_bug.cgi?id=154235">bug 154235</a>
from <span class="vcard"><a class="email" href="mailto:pnormand@igalia.com" title="Philippe Normand <pnormand@igalia.com>"> <span class="fn">Philippe Normand</span></a>
</span></b>
<pre>(In reply to <a href="show_bug.cgi?id=154235#c23">comment #23</a>)
<span class="quote">> (In reply to <a href="show_bug.cgi?id=154235#c12">comment #12</a>)
> > Ok so this is the exact same situation as in WebRTC support. We disabled it
> > temporarily in the bots and provided a custom JHBuild moduleset. Would that
> > be OK with you?
>
> I'm not sure I understand the decision behind WebRTC either, what was the
> point in disabling it, just to avoid the upgrade to GStreamer 1.6? I would
> prefer to get rid of the extra jhbuild moduleset and re-enable WebRTC for
> developers again. </span >
This isn't possible yet because OpenWebRTC depends on GStreamer 1.6 at least. And we can't bump the gst version in JHBuild yet either. Hence the decision to disable WebRTC in builds *for* *now* :)
<span class="quote">> Can't we do that for EME as well?</span >
Nope.
<span class="quote">>
> I think the primary difference there is that you guys have concrete plans to
> reenable WebRTC within a relatively short timespan. Also, WebRTC is a very
> important feature for the WebKit project, whereas EME is only useful to ease
> maintenance of downstream forks.</span >
Not only that. It's also needed to show that WebKitGTK itself can support EME.
<span class="quote">> And WebRTC support has existed upstream for
> a long time already. </span >
Both WebRTC and EME specs have roughly emerged around 2012, IIRC.
<span class="quote">> We should apply strict scrutiny when adding new
> features that would not be enabled by default; in this case, I think it
> makes strategic sense to have this, but I don't think it makes sense for the
> bots to not build or test it. (That's reasonable, no? :)
> </span >
Ok, I also would like to have this tested on the bots at some point but as mentioned already, it's not possible yet.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>