render to egl texture
joel.winarske at gmail.com
Fri Mar 12 00:02:58 UTC 2021
I'm taking a look at the sdlshare example, and porting to Fedora 33 -
After pausing the pipeline I get an eglCreateContext EGL Error of
EGL_BAD_CONTEXT. The context being passed in is shared, without a surface.
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.
> 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
>> is more appropriate.
>> 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?
>> On Mon, Mar 8, 2021 at 4:59 PM Joel Winarske <joel.winarske at gmail.com>
>>> 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
>>> On Mon, Mar 8, 2021 at 4:32 PM Matthew Waters <ystreet00 at gmail.com>
>>>> 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:
>>>> and then promoted to gst-plugins-base and is available as the libgstgl-1.0
>>>> On 9/3/21 8:59 am, Joel Winarske wrote:
>>>> still the recommended pattern for rendering to an EGL texture?
>>>> gstreamer-devel mailing listgstreamer-devel at lists.freedesktop.orghttps://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the gstreamer-devel