render to egl texture

[Joel Winarske]

I'm taking a look at the sdlshare example, and porting to Fedora 33 -
wayland/egl.

After pausing the pipeline I get an eglCreateContext EGL Error of
EGL_BAD_CONTEXT.  The context being passed in is shared, without a surface.

Code: https://gist.github.com/jwinarske/a518d16f18a4e0345d91027984098ec9
Log: https://gist.github.com/jwinarske/2d19e39590415fb8331af2edbeb1b984

How do I avoid the dummy window altogether?

My end goal is to simply update a texture on each frame.  Something else
renders the texture.




On Tue, Mar 9, 2021 at 4:42 PM Matthew Waters <ystreet00 at gmail.com> wrote:

> There is no way to know the texture ID without uploading the frame.
>
> The texture ID is almost never a constant value.  At least, there will
> probably be two textures that will be flipped between. At most, each
> texture id will be unique.
>
> Cheers
> -Matt
>
> On 10/3/21 5:34 am, Joel Winarske wrote:
>
> In my use case (video player) I just need to initialize the pipeline and
> return a texture id.
>
> Is there a way to determine the texture id without loading a frame?
>
> Is the texture id constant over the lifecycle of the pipeline?
>
>
> On Mon, Mar 8, 2021 at 9:57 PM Matthew Waters <ystreet00 at gmail.com> wrote:
>
>> That is one option if you're looking to use glimagesink's rendering.  If
>> you're rendering the texture yourself, something like
>> https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/blob/master/tests/examples/gl/sdl/sdlshare.c
>> is more appropriate.
>>
>> Cheers
>> -Matt
>>
>> On 9/3/21 1:37 pm, Joel Winarske wrote:
>>
>> I'm figuring a pipeline like this:
>> uridecodebin uri=file:///usr/local/share/assets/video.mp4 !
>> video/x-raw(memory:GLMemory),format=RGBA,texture-target=2D ! glimagesink
>>
>> To get the texture id I see a pattern in the cube example of attaching
>> callback to "client-draw" of glimagesink, then mapping the video buffer
>> which provides access to the texture id.  Is this the only way to access
>> the texture id?
>>
>> Thanks,
>> Joel
>>
>>
>> On Mon, Mar 8, 2021 at 4:59 PM Joel Winarske <joel.winarske at gmail.com>
>> wrote:
>>
>>> Thank you for that.
>>>
>>> What is the current recommended pattern for rendering to a GL texture
>>> which gets consumed by a shared context?  The shared context handles the
>>> rendering.
>>>
>>> Cheers,
>>> Joel
>>>
>>>
>>> On Mon, Mar 8, 2021 at 4:32 PM Matthew Waters <ystreet00 at gmail.com>
>>> wrote:
>>>
>>>> No.
>>>>
>>>> clutter has not been recommended for many years.  gst-plugins-gl
>>>> neither for many more.  gst-plugins-gl has been migrated into
>>>> gst-plugins-bad as can be seen from the latest commit on that repo:
>>>> https://github.com/freedesktop/gstreamer-gst-plugins-gl/commit/bedade404ec82432742a901c663f18dfaa24356f)
>>>> and then promoted to gst-plugins-base and is available as the libgstgl-1.0
>>>> library.
>>>>
>>>> Cheers
>>>> -Matt
>>>>
>>>> On 9/3/21 8:59 am, Joel Winarske wrote:
>>>>
>>>> Is
>>>> https://github.com/freedesktop/gstreamer-gst-plugins-gl/blob/master/tests/examples/clutter
>>>> still the recommended pattern for rendering to an EGL texture?
>>>>
>>>> Thanks,
>>>> Joel
>>>>
>>>>
>>>> _______________________________________________
>>>> gstreamer-devel mailing listgstreamer-devel at lists.freedesktop.orghttps://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>>>>
>>>>
>>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20210311/75670a3a/attachment.htm>