[Bug 792407] Windows: GL context sharing fails in async loading mode.

GStreamer (GNOME Bugzilla) bugzilla at gnome.org
Mon Mar 26 15:47:06 UTC 2018


https://bugzilla.gnome.org/show_bug.cgi?id=792407

Gordon Nickel <gordon.nickel at downstream.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |gordon.nickel at downstream.co
                   |                            |m

--- Comment #5 from Gordon Nickel <gordon.nickel at downstream.com> ---
(In reply to Matthew Waters (ystreet00) from comment #4)
> (In reply to Petros from comment #3)
> > In any case, I would like to provide proper fallback support when
> > wglCreateContextAttribsARB() fails so my question would be at which point
> > exactly should one disable and then (re)enable the application context ( in
> > this case the one coming from Cinder ) on a playbin - appsink based pipeline
> > so that wglShareLists() doesn't fail when GStreamer tries to setup/share the
> > context internally ?
> 
> Step 1 is to figure out why wglCreateContextAttribsARB fails exactly. This
> situation might be avoidable for the NVIDIA drivers.  Failing that, a bug
> with NVIDIA with might be prudent to get this fixed at the source.
> 
> As for a workaround, the only real way to know when the GL context has been
> created is by overriding the 'create-context' signal on GstGLDisplay and
> creating the GL context there with the cinder GL context not current.

Hi Matt, I'm working with the same source as Petros, and was able to get async
state changes working by using your suggestion of override the 'create-context'
signal. However, the only way it would work was to manually create a context
using gst_gl_context_new and share it with the main openGL context using
gst_gl_context_create. This introduces an approximately 1.5-2.0 second delay in
the main thread while the GstGLContext is created. Are there any ways to avoid
that delay or speed it up?

Here's the relevant context creation code (sGstAsyncContext is returned for the
create-context signal later): 
if(!sGstGLDisplay)
    sGstGLDisplay = gst_gl_display_new();
else
    holdDisplayRef = true;
ci::gl::env()->makeContextCurrent(nullptr);
auto platformData =
std::dynamic_pointer_cast<ci::gl::PlatformDataMsw>(ci::gl::context()->getPlatformData());
mGstData.context = gst_gl_context_new_wrapped(sGstGLDisplay,
(guintptr)platformData->mGlrc, GST_GL_PLATFORM_WGL, GST_GL_API_OPENGL);

if(sEnableAsyncStateChange && !sGstAsyncContext) {
    if(!sGstAsyncContext) {
        sGstAsyncContext = gst_gl_context_new(sGstGLDisplay);
        GError* err = NULL;
        if(!gst_gl_context_create(sGstAsyncContext, mGstData.context, &err) &&
err) {
            //g_printerr("Context not created with error " << err->code << " "
<< err->domain << " " << err->message);
        }
    } else {
        gst_object_ref(sGstAsyncContext);
    }
}

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