[Bug 697112] Revamp GstSurfaceMeta

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=697112
  GStreamer | gst-plugins-base | git

--- Comment #8 from Gwenole Beauchesne <gb.devel at gmail.com> 2013-04-11 04:40:22 UTC ---
(In reply to comment #7)
> For EGLImage see gst-plugins-bad/gst-libs/gst/egl (which is also not complete
> yet, but works fine for eglglessink and gst-omx already). Ideally I'd like to
> use EGLImages instead of stupid texture IDs everywhere too, yes. Just that not
> every API can handle that unfortunately.

Actually, if you talk about GLX, then I would like to deprecate it both in
libva and gstreamer-vaapi. It has a terrible design but it was useful back to
time when the hard constrain was "make it work with AMD/XvBA that can only
render to RGBA texture". Now that they published a Mesa/VDPAU implementation,
this opens the door to EGL (and VA-API). There is still NVIDIA/VDPAU to cope
with, but they are working on something too.

Since GstSurfaceMeta is the existing interface for GStreamer 1.0.x, I would
personally focus on it first. In order to avoid API change there, I think I
will just implement a GstSurfaceMeta API but customize the returned struct/info
to contain extra room for a GstBuffer pointer I could use later on, i.e. a
GstVaapiSurfaceMeta. Then, for 1.2, we can use the more correct APIs.

I think the first user for it would be WebKit. I will try to ping Damien or Rob
for clutter-gst but they would really want to handle only EGLImages. And I
don't think their opinion changed since this is the most sensible way to do,
anyway. :)

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.