[Cogl] cogl-gst fixes/improvements and hardware decode stuff

[Robert Bragg]

Thanks for taking a look at this!

Having also talked about this with you and Neil a bit offline, it
seems that we can't see how it could be safe for us to integrate
hardware decode support by way of passing GStreamer a GL texture
handle. Firstly this suggests that GStreamer is going to try and
directly use the GL api to bind that texture which I'm worried will
trash some undocumented amount of GL state that we may be caching.
Also Cogl supports using OpenGL via GLX or EGL and OpenGL ES via EGL
and we can't see how GStreamer would know what GL API we are using if
we just pass it a texture handle?

Sadly the OpenGL api is not well suited for being able to integrate
orthogonal components such as GStreamer so I think maybe we'll need to
investigate an alternative approach, such as integrating via DRM or
via EGL and GLX. My hunch is that integrating at the DRM level could
be the best for us.

For now lets see if we can land some of these patches that look useful
even without the GL integration parts. I'll aim to follow up with
separate reviews for those patches.

regards,
Robert


On Mon, Dec 9, 2013 at 11:17 AM, Lionel Landwerlin
<llandwerlin at gmail.com> wrote:
> Hi there,
>
> I recently started to play around again with hardware decode in
> Clutter-Gst master and started to see problems and missing
> functionalities in Cogl-Gst. The following patch set includes fixes
> for some stuff already there, as well as new features to support
> hardware decode.
>
> This isn't the only thing we need to get hardware decode working out
> of the box. People who contributed this patch set have identified bugs
> in various places like Gst-vaapi or Gstreamer plugins, but it's a good
> step forward to get stuff to work.
>
> Cheers,
>
> -
> Lionel
>
>
> _______________________________________________
> Cogl mailing list
> Cogl at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/cogl