GNOME Bugzilla – Bug 732664
add other-context support to GstGLMixer
Last modified: 2014-11-11 05:42:10 UTC
Created attachment 279817 [details] [review] add other context property to GstGLMixer add other-context property to GstGLMixer to support context share, this patch just copy some code from GstGLFilter to GstGLMixer
Hmm, this should be negotiated, using property for that is most likely a relic from before GstContext.
Isn't that bug a dup of #732662 ?
(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, GstGLMixer may be the last element of GL pipeline (consider videotestsrc ! glvideomixer ! fakesink ,then getting texture from fakesink to custom share context OpenGL app , like qglwtextureshare demo) , and GstGLMixer can not use context share since there's no downstream gl element. if this is expected behaviour , I must use a GstGLFiter after GstGLMixer to giving GstGLMixer a proper shared context, this makes GstGLMixer/Filter different please corrent me if there's some misunderstood
(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. > GstGLMixer may be the last element of GL pipeline (consider videotestsrc ! > glvideomixer ! fakesink ,then getting texture from fakesink to custom share > context OpenGL app , like qglwtextureshare demo) , and GstGLMixer can not use > context share since there's no downstream gl element. Right, in this case, glvideomixer would have it's own context, and it would not be shared. > > 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.
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.
The other-context property is to allow the app to provide an external context with which we share our internal GL context with. This should probably be exposed through the GstContext mechanism. Probably after 1.4 is out. The internal GL context(s) are not shared using the GstContext mechanism but through the allocation query.
(In reply to comment #6) > The other-context property is to allow the app to provide an external context > with which we share our internal GL context with. This should probably be > exposed through the GstContext mechanism. Probably after 1.4 is out. > > The internal GL context(s) are not shared using the GstContext mechanism but > through the allocation query. Thanks for explanation
commit e40d70c69a96daf9081275dbca5c79bdd37438cc Author: Matthew Waters <ystreet00@gmail.com> Date: Thu Aug 14 23:29:00 2014 +1000 gl: propogate other-context using GstContext