[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