[Webkit-unassigned] [Bug 154235] [GTK][GStreamer] ClearKey EME v1 decryption support

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=154235

Michael Catanzaro <mcatanzaro at igalia.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mcatanzaro at igalia.com

--- Comment #23 from Michael Catanzaro <mcatanzaro at igalia.com> ---
(In reply to comment #12)
> 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. 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? :)

> 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 :)

I think if you have it enabled by default (for developers) downstream, you can do it upstream too, right?

(In reply to comment #21) 
> I've been trying that but without much success. Just to be clear, by leaking
> the value out mean using GUniquePtr's reset()?

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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20160216/898b9d2c/attachment.html>