<html>
<head>
<base href="https://bugs.webkit.org/" />
</head>
<body><span class="vcard"><a class="email" href="mailto:mcatanzaro@igalia.com" title="Michael Catanzaro <mcatanzaro@igalia.com>"> <span class="fn">Michael Catanzaro</span></a>
</span> changed
<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>
<br>
<table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>What</th>
<th>Removed</th>
<th>Added</th>
</tr>
<tr>
<td style="text-align:right;">CC</td>
<td>
</td>
<td>mcatanzaro@igalia.com
</td>
</tr></table>
<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#c23">Comment # 23</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:mcatanzaro@igalia.com" title="Michael Catanzaro <mcatanzaro@igalia.com>"> <span class="fn">Michael Catanzaro</span></a>
</span></b>
<pre>(In reply to <a href="show_bug.cgi?id=154235#c12">comment #12</a>)
<span class="quote">> 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?</span >
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. Can't we do that for EME as well?
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. And WebRTC support has existed upstream for a long time already. 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 class="quote">> About the concern of this not being enabled and bitrotting, I think it's not
> a valid concern because this code is actively used in a downstream fork. So
> every build break that will happen will be noticed downstream and I'll be
> happy to fix in ToT whenever needed :)</span >
I think if you have it enabled by default (for developers) downstream, you can do it upstream too, right?
(In reply to <a href="show_bug.cgi?id=154235#c21">comment #21</a>)
<span class="quote">> I've been trying that but without much success. Just to be clear, by leaking
> the value out mean using GUniquePtr's reset()?</span >
Reset does an unref. It's basically the same as g_set_object (ref new value, set pointer to new value, unref old value). With no arguments, that's the same as g_clear_object (set pointer to null, unref old value).
It's identical to std::unique_ptr, actually; GUniquePtr is just a std::unique_ptr that frees with g_free instead of delete.</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>