[Bug 751104] make Gtk sinks usable from gst-launch

GStreamer (GNOME Bugzilla) bugzilla at gnome.org
Thu Jun 18 01:24:33 PDT 2015


https://bugzilla.gnome.org/show_bug.cgi?id=751104

Matthew Waters <ystreet00 at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ystreet00 at gmail.com

--- Comment #6 from Matthew Waters <ystreet00 at gmail.com> ---
I like this!

(In reply to Xavier Claessens from comment #5)
> Code should be duplicated in the non-gl sink as well, but let's first check
> if that's correct, maybe we could add a base class when we have everything
> in place.
> 
> I've been reading this code and I think it's lacking a few things to be
> solid:
> 
> 1) It shouldn't call gtk_widget_realize() in _get_gl_context() but rather
> wait for "realized" signal. But then what should happen if show_frame() is
> called and the widget is still not realized?

"realize" needs to happen before show_frame. In order to get the GL context, we
need the widget realized in order for Gtk to set up it's GL context.  In order
to share the Gtk GL context with upstream elements, it's required that the Gtk
GL context be created in before upstream wants it to share with.

For what to do when not realized, I can think of a couple of use case that will
require different behaviour so maybe a property is required to choose between
them.  An starting list of strategies for the property: {error, warn, ignore,
wait? (probably not possible)}.

> 2) It should handle "unrealized" signal, it can happen if the user remove
> the widget from its parent, especially since we keep a strong ref so that
> won't trigger "destroyed" signal.

Agreed.

> 3) Wondering if widget_destroy_cb() should
> g_clear_object(&gtk_sink->widget); instead. If we keep a strong ref on a
> widget we are responsible to release that ref on destroy normally. The
> widget cannot be used any more for any GTK work.

Agreed.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.


More information about the gstreamer-bugs mailing list