glimagesink and how it likes to do things

[Matthew Waters]

On 08/08/14 20:27, Lasse Laursen wrote:
> Looking closer at available plug-ins, there's also something called
> GstGLUpload - which says that it uploads to GL Textures... Is this
> supposed to be used as a sink? Can it?

GstGLImageSink is the only sink currently provided by the opengl
plugins.  In 1.4, GstGLUpload is now a helper object (not an element)
available within libgstgl for elements/applications to use.  All opengl
elements implicitly upload/download as required by the pipeline using it
and its counterpart, GstGLDownload.

> I've also just learned that if I wanted to use the GstGLShader object,
> I am forced to make use of the GstGLImageSink? Would GstGLUpload also
> be acceptable here?

GstGLShader (the element), like all opengl elements will upload/download
data as required by the surrounding elements.  So you could have any
other non-GL element after it and it should still work.

> Regards,
> Lasse
>
> On 08-08-2014 19:09, Lasse Laursen wrote:
>> Hey y'all,
>>
>> I know this is kind of a beaten horse, but given the recent release
>> of the 1.4 version of gStreamer I thought I'd pull out a stick and
>> give it a few more whacks.
>>
>> Today I finally got around to working out how to properly use an
>> appsink to copy gstreamers video output directly into an OpenGL
>> texture. This works pretty well for now - but I'm constantly trying
>> to work out, if there's a way of bypassing having to copy the data
>> manually and just have gstreamer throw it into an OpenGL texture for me.

GstGLUpload is designed for this use case :)

>> The glimagesink looked promising, despite it's current 'bad' status
>> and... 0.10 reference manual? I take it, this is the most up-to-date
>> doc currently:
>>
>> http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-gl-plugins/html/
>>
>> (although it probably should eventually be merged into the 'bad'
>> folder given it's status?)

There are docs in the -bad repository however they don't seem to have
been updated on/uploaded to the server.

>> Anyway - I had a closer look at the following example:
>>
>> http://cgit.freedesktop.org/gstreamer/gst-plugins-bad/tree/tests/examples/gl/generic/cube/main.cpp
>>
>>
>> It seems as though the client callback receives a texture
>> reference... Is there anyway of specifying a texture to which one
>> would like the glimagesink to write, instead of receiving a reference
>> to one in every callback? If not - is it possible to somehow
>> intercept the texture ID earlier - and are there any guarantees that
>> it doesn't change at some point down the line?

The exact behaviour will depend on the specific elements involved.  The
two possibilities are
1. glimagesink uploads the incoming video frame -> texture id will
change every draw call (performance gain is possible here although only
to the second case)
2. glimagesink displays upstream's GL texture and is using a bufferpool
-> texture id will loop between a certain amount of texture id's
depending on the lifetime of the buffers.  This is so that it is
possible to upload the previous texture while the next texture is being
displayed/used.  The other catch is that the basesink class by default
holds on to the last buffer rendered until the next buffer arrives.

Any existence of the texture id outside of the callback is not really
guaranteed.  Is there any particular reason you would like to set the
texture id for upload?

>> Regards,
>> Lasse
>>
>> -- 
>> Lasse Farnung Laursen
>> Post.doc at the University of Tokyo
>> www.lasselaursen.com <http://www.lasselaursen.com>
>> FB: lasse.laursen <https://www.facebook.com/lasse.laursen>
>> Twitter: @PMP_J <https://twitter.com/PMP_J>
>>
>>
>> _______________________________________________
>> gstreamer-devel mailing list
>> gstreamer-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20140808/4ba5b032/attachment-0001.sig>