[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

--- Comment #28 from Carlos Garcia Campos <cgarcia at igalia.com> ---
Comment on attachment 271332
  --> https://bugs.webkit.org/attachment.cgi?id=271332
patch

View in context: https://bugs.webkit.org/attachment.cgi?id=271332&action=review

>>> Source/WebCore/platform/graphics/gstreamer/WebKitCommonEncryptionDecryptorGStreamer.cpp:305
>>> +            if (self) {
>> 
>> This is not correct way to check if self is still alive. You should either use a weak ref/ptr, or protect the object with GRefPtr, and capture that.
> 
> I tried to use WeakPtr but the captured value stores nothing in the lambda.

The thing is that self is not going to be nullptr here if the object is destroyed before the lambda is called, so the check is wrong. You could use weak pointer or GRefPtr depending on what you want. If you want to ensure the object is nos destroyed until the lambda is called, then use GRefPtr, but if you want to ignore the lambda if the object is destroyed, you need a weakptr and check its value in the lambda to return early. Since this is a GObject maybe it's easier to use GObject weak references instead of WeakPtr

>>> Source/WebCore/platform/graphics/gstreamer/WebKitCommonEncryptionDecryptorGStreamer.cpp:310
>>> +                    self->priv->protectionEvent = nullptr;
>> 
>> Use GRefPtr for this. I don't understand why we need to keep the protectionEvent as a member of WebKitMediaCommonEncryptionDecrypt, we could use GrefPtr and capture it in the lambda.
> 
> We only need to keep it referenced until the initData is no longer needed. If a GRefPtr captured in the lambda can do that, then yeah, let's use the fancy stuff :)

You are indeed releasing the protection event inside the lambda.

-- 
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/20160220/00c59488/attachment.html>