GNOME Bugzilla – Bug 779966
Avoid usage of GstVideoGLTextureUploadMeta
Last modified: 2018-11-03 15:49:36 UTC
The plan is for the upload meta to be replaced by gstreamer-gl and as such the first steps to deprecating it are in place in bug 779965. gstreamer-vaapi should avoid using it when deprecated symbols are disabled.
Created attachment 347801 [details] [review] plugins: avoid using GstVideoGLTextureUploadMeta when GST_DISABLE_DEPRECATED is defined
Matthew, in which version did you create the patch? it doesn't apply in master anymore, but looks way before branch 1.10
Created attachment 348022 [details] [review] plugins: deprecate usage GstVideoGLTextureUploadMeta When GST_DISABLE_DEPRECATED is defined don't expose GstVideoGLTextureUploadMeta
It was based on master just after 1.10.0 was released :)
AFAIK, the only efficient code path for clutter-gst (hence totem) is GstVideoGLTextureUploadMeta. If you deprecate it then efficient video playback in totem is lost, and clutter-gst will revert to the slow software upload path. Do you plan on enhancing clutter-gst to give it some other efficient render path in place of GstVideoGLTextureUploadMeta?
To be fair, my push would be to deprecated cluttergst in favour of gtkglsink. Pretty much all what we do in GL or zero-copy ends up incompatible due to conflicting limitations (old cogl that is).
I totally agree, but Totem relies on clutter-gst and is the default video player for Gnome. And Gnome is the default desktop for major Linuxes now. Hence we're stuck with clutter-gst's performance being a priority for the major Linux desktops.
(In reply to Daniel van Vugt from comment #7) > I totally agree, but Totem relies on clutter-gst and is the default video > player for Gnome. And Gnome is the default desktop for major Linuxes now. > > Hence we're stuck with clutter-gst's performance being a priority for the > major Linux desktops. What is the difference between modifying Totem vs Modifying GStreamer ?
I have no preference for what gets modified, so long as the outcome is the same: Totem can still accept zero-copy video frames, somehow. That could indeed be achieved by modifying Totem or GStreamer. See bug 740753 where I have a recent patch for the latter. My previous comments really are just about ensuring there is no period of uncertainty where Totem would have no efficient zero-copy code path. A feature should not be deprecated until some replacement for it exists.
Created attachment 371742 [details] [review] vaapi: silence deprecation warnings from GstVideoGLTextureUploadMeta
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/issues/52.