[Bug 732664] add other-context support to GstGLMixer

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=732664
  GStreamer | gst-plugins-bad | 1.3.90

--- Comment #5 from comicfans44 <comicfans44 at gmail.com> 2014-07-04 13:25:49 UTC ---
greate thanks for the explanation
(In reply to comment #4)
> (In reply to comment #3)
> > (In reply to comment #1)
> > > Hmm, this should be negotiated, using property for that is most likely a relic
> > > from before GstContext.
> > 
> > I have a little question about GstGLContext, seems that upstream gl element
> > getting GstGLContext from downstream gl element , but in context share
> > scenario,
> 
> It tries both, downstream, then upstream, then ask the app, and if nothing
> found it create the context.

how could my app respond for GstGLContext request? I only found
GST_MESSAGE_NEED_CONTEXT with GstGLDisplay type in
_gst_gl_display_context_query , but it didn't carry GstGLContext, did I missed
something ?

> > if this is expected behaviour , I must use a GstGLFiter after GstGLMixer to 
> >giving GstGLMixer a proper shared context, this makes GstGLMixer/Filter 
> >different 
> No, each element are responsible for creating a context if none is found.
yes, each element can create context, but GstGLMixer can not create from shared
context like GstGLFilter. in myself usage, gstreamer opengl pipeline is part of
my app (through fakesink and context share) ,if GstGLMixer is the only element,
I must add a nop gleffects together to do context share (if #732662 resolved) ,
which this is different to that only one glfilterxxx in pipeline.

-- 
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.