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

[Matthew Waters]

On 04/03/14 12:35, comicfans44 wrote:
> 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.

:(. That sounds like the contexts aren't being shared properly, or a 
driver bug.

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

The filter comment is wrong, it only needs one.  glimagesink needs 2 
because it (GstVideoSink) holds onto the last buffer for redisplay.

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

Awesome, thanks.