<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <br>
    <div class="moz-cite-prefix">On 17/01/15 06:42, Lasse Laursen wrote:<br>
    </div>
    <blockquote cite="mid:%3C54B96992.1030209@lasselaursen.com%3E"
      type="cite">
      <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
      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>
    </blockquote>
    <br>
    No it is not required to turn off the context.<br>
    <br>
    <blockquote cite="mid:%3C54B96992.1030209@lasselaursen.com%3E"
      type="cite"> 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 moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:gstreamer-devel@lists.freedesktop.org">gstreamer-devel@lists.freedesktop.org</a>
<a moz-do-not-send="true" 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 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>
  </body>
</html>