[Bug 704321] Add complete support for GstContext

GStreamer (bugzilla.gnome.org) bugzilla at gnome.org
Wed Nov 6 06:30:40 PST 2013


https://bugzilla.gnome.org/show_bug.cgi?id=704321
  GStreamer | gst-plugins-gl | git

--- Comment #13 from Sebastian Dröge (slomo) <slomo at coaxion.net> 2013-11-06 14:30:38 UTC ---
(In reply to comment #12)

> > This custom query is not needed anymore?
> 
> Soon :). That's to be moved to the ALLOCATION query.  Still needed currently
> because GstGLDisplay does not hold onto the GstGLContext.

OK :)

> > If the context is set as result of the need-context message, nothing will put
> > it into ctxt and this function won't return the display
> 
> Hmm, this will probably require intervention from the specific element now that
> gst_element_get_context has disappeared.  Just to make sure this is the correct
> order of proceedings for the need-context message.
> 
> 1. Element posts need-context with a type
> 2. Some bin/pipeline containing the element can respond if it already has that
> context
> 3. Else the application is given a chance (via the sync bus) to respond
> 4. If not successful create our own and propogate via have-context
> 
> The only way that I can find that the app/bin/pipeline can respond with is via
> gst_element_set_context (which we currently do not implement).
> 
> However, we do not really care that ctxt has been set or not, only that
> *display_ptr has been set.  Which, assuming that the element updates the
> pointer display_ptr points to in a gst_element_set_context, everything's fine.

Yes that's correct, GstElement::set_context() needs to be implemented by the
element (also handling of the CONTEXT query).

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- 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