[Bug 746087] GstVideoCropMeta implementation is inconsistent

GStreamer (GNOME Bugzilla) bugzilla at gnome.org
Fri Mar 13 05:34:27 PDT 2015


https://bugzilla.gnome.org/show_bug.cgi?id=746087

--- Comment #6 from Sebastian Dröge (slomo) <slomo at coaxion.net> ---
(In reply to Nicolas Dufresne (stormer) from comment #5)
> > - CAPS event contains the display width/height (otherwise applications will
> > become unhappy, GstDiscoverer reports wrong information, etc)
> > - caps inside the ALLOCATION query contain the memory width/height
> 
> I'm not sure I agree with this one yet. Using caps to tell the pool what
> padding need to be allocated is weird. The padded width/height being in
> VideoMeta should be enough. I think we should be able to tell the pool the
> VideoAlignment we want, and by having CROP META option enable, we'd get
> frames that maps to the larger image instead of the cropped region.

VideoAlignment is completely orthogonal to the CROP meta and should not be a
requirement for using it.

Inside the ALLOCATION query in think we should have the memory width/height
because downstream elements might decide to offer a buffer pool or not based on
that, or to offer different buffer pools. E.g. think of xvimagesink which has a
maximum allocation size for which it can provide shared memory.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.


More information about the gstreamer-bugs mailing list