[Bug 746087] GstVideoCropMeta implementation is inconsistent

[GStreamer (GNOME Bugzilla)]

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

--- Comment #5 from Nicolas Dufresne (stormer) <nicolas.dufresne at collabora.co.uk> ---
(In reply to Jan Schmidt from comment #0)
> Currently GstVideoCropMeta implementation is problematic - caps width/height
> values and GstVideoMeta settings are a bit jumbled, and things need fixing
> and documenting across the board.
> 
> From slomo in bug #74010, it should work like this:
> 
> - 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.

> - GstVideoMeta contains the memory width/height

Agreed.

> - GstVideoCropMeta contains how much should be cropped relative to the
> values inside the video meta and the ALLOCATION query caps

I think the crop region should fit in the VideoMeta width/height. Allocation
caps should remain the negotiated caps imho.

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