render to egl texture

Joel Winarske joel.winarske at gmail.com
Sun Mar 14 21:13:05 UTC 2021


Using the below combo of variables seems to be invalid, for both Ubuntu
18.04 LTS (Wayland on Ubuntu) and Fedora 33 (Wayland is active by
default).  Canonical (Ubuntu) is stating they will default with Wayland
(again) in an upcoming release.

GST_GL_WINDOW=wayland
GST_GL_PLATFORM=egl
GST_GL_API=gles2

What gl test cases are expected to work via wayland/egl/gles2?  Or any test
case for that matter.

Thanks,
Joel


On Thu, Mar 11, 2021 at 4:02 PM Joel Winarske <joel.winarske at gmail.com>
wrote:

> 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/20210314/b2492225/attachment.htm>


More information about the gstreamer-devel mailing list