GNOME Bugzilla – Bug 756935
glimagesink: get_caps should return caps with current size
Last modified: 2018-11-03 11:42:41 UTC
This would help upstream elements that want to produce video buffers of the same size as the sink. It would also help when renegotiating after the sink surface is resized. The Upstream caps (re)negotiation documentation (http://gstreamer.freedesktop.org/data/doc/gstreamer/head/pwg/html/section-nego-upstream.html) can be understood as requiring that the sink returns caps with the current size. Other sinks, like ximagesrc, return caps with the current size.
Only ximagesink does this currently :) The problem here is that doing this might cause an upstream element to rescale in CPU, which is going to be much slower than letting glimagesink do the rescaling in the GPU.
Can't you just return e.g. video/x-raw, width=1920, height=1080; video/x-raw, width=[1,MAX], height=[1,MAX]; then upstream can know what the 'prefered' size is but also knows that it can passthrough any size, no?
Right, that's how it should work. To prefer upstream doing the conversion, we would have to override the get_caps vfunc like in ximagesink and do the filter handling the other way around.
Wanted, but forgot, to add an extract of the doc I referred to, so here it is: "Elements that want to propose a new format upstream need to first check if the new caps are acceptable upstream with an ACCEPT_CAPS query. Then they would send a RECONFIGURE event and be prepared to answer the CAPS query with the new preferred format. It should be noted that when there is no upstream element that can (or wants) to renegotiate, the element needs to deal with the currently configured format." It is pretty clear. The only counter argument could be that the element does *not* want to propose a new format. But why would it not want ;)
Created attachment 327940 [details] [review] glimagesink: expose preferring the current frame size
-- 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/gst-plugins-base/issues/235.