After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 698358 - Add HW decoder support back
Add HW decoder support back
Status: RESOLVED FIXED
Product: clutter-gst
Classification: Other
Component: general
2.0.x
Other Linux
: Normal normal
: ---
Assigned To: clutter-gst-maint
clutter-gst-maint
Depends on:
Blocks:
 
 
Reported: 2013-04-19 12:26 UTC by Gwenole Beauchesne
Modified: 2013-04-24 15:31 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
[clutter-gst] Add HW decoder support back (3.30 KB, patch)
2013-04-19 12:26 UTC, Gwenole Beauchesne 		committed Details | Review

Description Gwenole Beauchesne 2013-04-19 12:26:09 UTC 
Created attachment 241894 [details] [review]
[clutter-gst] Add HW decoder support back

Hi, this is a minimal patch to bring HW support back to clutter-gst 2.0 branch, thus also including the previous clutter-gst 1.9.92 release. For GStreamer 1.2, we will have yet another mechanism to deal with HW surfaces but GStreamer 1.0 APIs are still around for now.

Detecting CLUTTER_GST_SURFACE may be refined/improved by checking for "video/x-surface" caps instead.

Concerning the GstSurfaceMeta API, we can also consider exposing "x11-pixmap" instead of plain GL textures. This is left for a future patch. "opengl" tag has better coverage as this also allows support for AMD/XvBA based platforms. Otherwise, "x11-pixmap" would be fine for Intel/VA-API or NVIDIA/VDPAU too.
Comment 1 Gwenole Beauchesne 2013-04-19 12:30:43 UTC 
Note: for clutter-gst/cogl git master, we could consider only supporting the newer GStreamer 1.2.x APIs, if you like. You also have the opportunity right now to voice your opinion on what would be the best API in to suit your rendering pipeline.

I'd tend to expose EGLClientBuffer + metadata and let the renderer sink handle those, but others would prefer handling EGLImage (thus implying extra work to manage with EGL contexts), and others would also be stuck with support plain RGBA GL texture ids too.
Comment 2 Lionel Landwerlin 2013-04-24 15:31:54 UTC 
Pushed to the 2.0 branch. Thanks!