gst-gl-plugin: texture share problem and customized GstGLContext/Window

[comicfans44]

Hi

Matthew Waters <ystreet00 at gmail.com> wrote:

> > 1 :  in Qt GL callback,  use glXGetCurrentContext get current GL
> > context ,  I don't know how to get  x11 Display*  from Qt so I
> > use XOpenDisplay(getenv("DISPLAY")) to open One
> 
> Another option is to create your display normally and then pass that 
> into gst-gl using the GstContext query.
> 
> > 3:  pass the GstGLContextGLX*  to a   global variable ,  hack
> > gst_gl_context_glx_create_context  to use this variable (which will
> > run the share context code path) .    I didn't know how to do this
> > step through gst-gl public API , since  GstGLImageSink always call
> > gst_gl_context_create  with shared context=0 . GstGLFilter has
> > other-context property but I did not always have a GstGLFilter all
> > the time.
> 
> Hmm, it should be possible to add that property to glimagesink, the 
> workaround, as you suggested, is to use some GstGLFilter subclass 
> (glcolorscale or gleffects with effect property set to 0).  Also, you 
> should use gst_gl_context_new_wrapped to wrap an existing GL context.
> 
Thanks for advising, but  I'm afraid this also suffered
from the random lock problem, since its also goes through the
context share code path .I'll try this and report later.

> > plus , I found that if I draw the  result texture in both
> > thread , more random locks.(I wait Qt GL draw completed then draw
> > it in clientDrawCallback,so texture is not used at the same time.
> > at least at my opengl code level)
> >
> > so , I wonder if this is a problem in my misused code , or a bug in
> > driver?
> 
> Sounds like a driver bug to me.  Unfortunately I do not have any
> radeon GPU's to test with.  You could alternatively try with the mesa
> stack (which AMD is contributing to)
> 
unfortunately , I tried the mesa but when running program, stdout gives
radeon: The kernel rejected CS, see dmesg for more information.
dmesg shows:[drm:radeon_cs_parser_relocs] *ERROR* gem object lookup
failed 0x39 [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -2!
seems that mesa or kernel has some problem. plus draw performance of
mesa not satisfied my requirement.  

> > I can receive gl texture ,but
> > the texture id always increases in every buffer receive (seems
> > texture never freed ), instead of two id swapping as glimagesink, I
> > don't know which part of code does the trick  ?
> 
> Bufferpools allow the reuse of GstBuffer's.  And GstBuffer's contain 
> GstMemory's and there's a GstGLMemory which holds a GL texture.
> Although that *should* already be used.
> 
I tried a pipeline like   videotestsrc -> glfilterblur ->myappsink ,I
found the BufferPool usage in glfilter ,but I still found texture not
freed. plus there is comment in glfilter.c :790

  /* we need at least 2 buffer because we hold on to the last one */
  gst_query_add_allocation_pool (query, pool, size, 1, 0);    -->1 or 2?

but in gstglimagesink.c:919 

  /* we need at least 2 buffer because we hold on to the last one */
  gst_query_add_allocation_pool (query, pool, size, 2, 0);

why this difference? I also tried to change glfilter argument to 2 but
texture still not freed.  override appsink's
propose_allocation and do as glimagesink, still no luck
> > can somebody provide some suggestions? if sharing texture between
> > thread (option A) is not stable, should we provide a easier way to
> > use custom GstGLContext/GstGLWindow (option B) ?  or how to use
> > appsink (option C)to receive buffer and correctly release it ?
> > Thanks
> >
> >
> >
> 
> It would be stupendous if you could file a bug here 
> https://bugzilla.gnome.org/enter_bug.cgi?product=GStreamer against 
> gst-plugins-gl with the example program/s.
OK, I'll clean my code and post it , Great thanks for suggestion.