<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Hey Matthew,<br>
    <br>
    Thanks for the reply and especially the example. I'm working on
    getting it function with the cinder framework. At first it seemed
    quite odd to hand over the context as a result of a bus message, but
    I can see the logic in not needing to create a secondary OpenGL
    context for gstreamer to make textures in, if one already exists. I
    do have one question though:<br>
    <br>
    Is it vital to turn off the OpenGL context when sharing it with
    Gstreamer? I've done a little context sharing before and I don't
    recall having to actively turn any contexts 'off'.<br>
    <br>
    Regards,<br>
    Lasse<br>
    <br>
    <div class="moz-cite-prefix">On 16-01-2015 00:27, Matthew Waters
      wrote:<br>
    </div>
    <blockquote cite="mid:54B85AE6.6000607@gmail.com" type="cite">
      <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
      A couple of points added inline.<br>
      <br>
      <div class="moz-cite-prefix">On 16/01/15 03:14, Lasse Laursen
        wrote:<br>
      </div>
      <blockquote cite="mid:%3C54B7E76D.6000904@lasselaursen.com%3E"
        type="cite">
        <meta http-equiv="content-type" content="text/html;
          charset=utf-8">
        Hello!<br>
        <br>
        Apologies for the double post, but my inept handling of
        Thunderbird caused my last post to be appended to an unrelated
        thread. Sorry about that Luis dArquer.<br>
        <br>
        For the sake of posterity, here's is the original question:<br>
        <br>
        I feel like I am so close to finally getting through to the
        other side with this problem, so I'm hoping someone can give me
        a few clues as to what pieces of the puzzle are missing. I used
        to use gStreamer as a pure 'decoding' library using this simple
        pipeline: <br>
        <br>
        uridecodebin uri=" + mPathToVideoFile +    " ! videoconvert !
        appsink name=sink
        caps="video/x-raw,format=RGB,pixel-aspect-ratio=1/1"; <br>
        <br>
        With this pipeline, I could quite easily grab the frames
        arriving at the sink and use them however I pleased. Mostly just
        throwing them on a texture in OpenGL and displaying them various
        places. This approach is - of course - quite horrible. I'm not
        making use of gstreamer as a fully-fledged media pipeline. So to
        rectify that - and because I'd like to run some simple shaders
        on the video data - I am now using this (almost as) simple
        pipeline: <br>
        <br>
        uridecodebin uri=" + mPathToVideoFile + " ! glshader name=shader
        location=" + pathToShader + " vars=\"float silver = float( 0.8
        ); \" ! appsink name=sink
        caps=\"video/x-raw,format=RGB,pixel-aspect-ratio=1/1\""; <br>
      </blockquote>
      <br>
      1. You should set the appsink caps to contain the
      memory:GstGLMemory caps features. e.g.
      video/x-raw(memory:GstGLMemory),format=RGBA... see gst-inspect-1.0
      glshader for the supported formats and features.  Otherwise,
      glshader (and any GL element) will download the texture upon
      seeing the system memory caps.<br>
      <br>
      <blockquote cite="mid:%3C54B7E76D.6000904@lasselaursen.com%3E"
        type="cite"> I make sure to share my current OpenGL context with
        the glshader element thusly: <br>
        <br>
        mPipeline_ShaderPre = gst_bin_get_by_name( GST_BIN( mGstPipeline
        ), "shader" ); <br>
        HGLRC mainContext = ::wglGetCurrentContext(); <br>
        g_object_set( mPipeline_ShaderPre, "other-context", mainContext,
        NULL ); <br>
      </blockquote>
      <br>
      2. The "other-context" property expects a GstGLContext rather than
      a platform specific handle.  You can wrap a context handle using
      gst_gl_context_new_wrapped().  However, in master there is no
      "other-context" property anymore so the sharing of GL context
      happens using GstContext.  See for example <a
        moz-do-not-send="true"
href="http://cgit.freedesktop.org/gstreamer/gst-plugins-bad/tree/tests/examples/gl/sdl/sdlshare.c#n232">http://cgit.freedesktop.org/gstreamer/gst-plugins-bad/tree/tests/examples/gl/sdl/sdlshare.c#n232</a>
      and the GstContext documentation.<br>
      <br>
      <blockquote cite="mid:%3C54B7E76D.6000904@lasselaursen.com%3E"
        type="cite"> Not sure if this is correct to be honest, but I
        didn't see any errors in gstreamers logs. Anyway - fast forward
        to my callback function that fires whenever a sample is ready at
        the sink I proceed to grab a Sample, from which I grab a Buffer,
        from which I grab a Frame, from which I grab a Texture ID,
        thusly: <br>
        <br>
        GstSample* gstVideoSinkSample = gst_app_sink_pull_sample(
        GST_APP_SINK( appsink ) ); <br>
        GstBuffer* gstBuffer = gst_sample_get_buffer( gstVideoSinkSample
        ); <br>
        if ( !gst_video_frame_map( &gstFrame, &gstInfo,
        gstBuffer, static_cast<GstMapFlags>( GST_MAP_READ | (
        GST_MAP_FLAG_LAST << 1 ) ) ) ) <br>
            { <br>
                errorToConsole( true, "Failed to map video frame" ); <br>
            } <br>
        GLuint textureId = *(guint *) gstFrame.data[0]; <br>
        <br>
        The result is the number 6. Which I felt was a plausible Texture
        ID handle. But when I then use a lovely tool named imdebug, and
        presume that the target for the texture is GL_TEXTURE_2D (which
        might be wrong), it throws a fit, because it attempts to
        determine the width and height of said texture via these calls:
        <br>
        <br>
        glBindTexture(target, texture); <br>
          glGetTexLevelParameteriv(target, 0, GL_TEXTURE_WIDTH, &w);
        <br>
          glGetTexLevelParameteriv(target, 0, GL_TEXTURE_HEIGHT,
        &h); <br>
        <br>
        So clearly something is wrong. Some place along this winding
        road, I've misunderstood something or overlooked something. I'd
        much appreciate any suggestions/clues! <br>
        <br>
        I myself am wondering if a callback at the sink is the right
        place to grab the texture ID, but I'm not sure how to get at it
        any earlier, and if that's wise. I am also unsure of how long
        this texture Id is valid if I want to render it on to a quad. I
        hope someone can shed a bit of light! <br>
      </blockquote>
      <br>
      It will be valid for as long as it's not overwritten/reused by the
      producing element which generally means while you keep a ref to
      the buffer or have the video frame mapped.<br>
      <br>
      <blockquote cite="mid:%3C54B7E76D.6000904@lasselaursen.com%3E"
        type="cite"> Regards, <br>
        Lasse <br>
        <br>
        <div class="moz-signature">-- <br>
          Lasse Farnung Laursen<br>
          Researcher at the University of Tokyo<br>
          <a moz-do-not-send="true" href="http://www.lasselaursen.com">www.lasselaursen.com</a><br>
          Twitter: <a moz-do-not-send="true"
            href="https://twitter.com/PMP_J">@PMP_J</a></div>
      </blockquote>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
gstreamer-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:gstreamer-devel@lists.freedesktop.org">gstreamer-devel@lists.freedesktop.org</a>
<a class="moz-txt-link-freetext" href="http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel">http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a>
</pre>
    </blockquote>
    <br>
    <div class="moz-signature">-- <br>
      Lasse Farnung Laursen<br>
      Researcher at the University of Tokyo<br>
      <a href="http://www.lasselaursen.com">www.lasselaursen.com</a><br>
      Twitter: <a href="https://twitter.com/PMP_J">@PMP_J</a></div>
  </body>
</html>