Bug 213029 - [GStreamer] Avoid setting GstContext twice in GLVideoSinkGStreamer
Summary: [GStreamer] Avoid setting GstContext twice in GLVideoSinkGStreamer
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Media (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Víctor M. Jáquez L.
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2020-06-10 09:48 PDT by Víctor M. Jáquez L.
Modified: 2020-06-19 09:30 PDT (History)
16 users (show)

See Also:


Attachments
Patch (2.36 KB, patch)
2020-06-10 09:52 PDT, Víctor M. Jáquez L.
no flags Details | Formatted Diff | Diff
Patch (4.54 KB, patch)
2020-06-17 03:46 PDT, Víctor M. Jáquez L.
no flags Details | Formatted Diff | Diff
Patch (4.63 KB, patch)
2020-06-17 09:15 PDT, Víctor M. Jáquez L.
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Víctor M. Jáquez L. 2020-06-10 09:48:20 PDT
When the GL video sink changes it state, it might set in the bin its context twice.
Comment 1 Víctor M. Jáquez L. 2020-06-10 09:52:16 PDT
Created attachment 401549 [details]
Patch
Comment 2 Xabier Rodríguez Calvar 2020-06-10 23:58:34 PDT
Comment on attachment 401549 [details]
Patch

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

I guess a GstContext should disappear at some point when we transition down to a certain state, I don't know if this is READY or NULL but this element is not handling that. If context disappears in READY in the sub elements, you won't be setting it again, or am I missing anything? I guess we should check this, not in the scope of this patch. Besides, at some point I guess we should clear the context at some state here, right?

This patch seems to be ok considering only this piece of code but please consider the rest I'm saying.

> Source/WebCore/ChangeLog:3
> +        [GStreamer] Avoid set gstcontext twice in GLVideoSinkGStreamer

GstContext, please change the bug title in bugzilla.

> Source/WebCore/ChangeLog:10
> +        No new tests as there is no change in functionality.

I guess setting the GstContext twice does not create problems, right? If it creates problems it would be a bug and that would require a test.
Comment 3 Víctor M. Jáquez L. 2020-06-17 03:46:29 PDT
Created attachment 402097 [details]
Patch
Comment 4 Víctor M. Jáquez L. 2020-06-17 03:47:09 PDT
I've refactored the patch, so it might need a second look
Comment 5 Víctor M. Jáquez L. 2020-06-17 04:33:46 PDT
(In reply to Xabier Rodríguez Calvar from comment #2)
> Comment on attachment 401549 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=401549&action=review
> 
> I guess a GstContext should disappear at some point when we transition down
> to a certain state, I don't know if this is READY or NULL but this element
> is not handling that. If context disappears in READY in the sub elements,
> you won't be setting it again, or am I missing anything? I guess we should
> check this, not in the scope of this patch. Besides, at some point I guess
> we should clear the context at some state here, right?

if contexts are persistent (and ours are!) they are removed until dispose: https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/master/gst/gstelement.c#L3376

(non persistent contexts are removed when state changes from READY to NULL: https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/master/gst/gstelement.c#L3266 )

The problem setting them several times, at least, in a waste of cpu cycles because when they are set, the bin set them again to  its children, and so on.
Comment 6 Xabier Rodríguez Calvar 2020-06-17 07:43:09 PDT
Comment on attachment 402097 [details]
Patch

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

> Source/WebCore/platform/graphics/gstreamer/GLVideoSinkGStreamer.cpp:161
> +        auto setContext = [&] (const gchar *contextType) {

Nit: make this a regular function and you're done.
Comment 7 Víctor M. Jáquez L. 2020-06-17 09:15:57 PDT
Created attachment 402113 [details]
Patch
Comment 8 Philippe Normand 2020-06-18 10:03:26 PDT
If you want to land this with cq I'm afraid you'll need to re-upload the patch...
Comment 9 EWS 2020-06-18 10:25:12 PDT
Committed r263217: <https://trac.webkit.org/changeset/263217>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 402113 [details].
Comment 10 Radar WebKit Bug Importer 2020-06-18 10:26:19 PDT
<rdar://problem/64494905>
Comment 11 Aakash Jain 2020-06-19 09:30:17 PDT
(In reply to Philippe Normand from comment #8)
> If you want to land this with cq I'm afraid you'll need to re-upload the patch...
I believe you fixed the issue by removing and setting the cq+ flag. I have improved the commit-queue in Bug 213377 so that it can better handle such trac downtime.

Also, my aim is that no-one should have to re-upload a patch just because of EWS. Please file a bug if you come across any scenario requiring re-upload of patch because of any EWS issue.