[Bug 746087] GstVideoCropMeta implementation is inconsistent

[GStreamer (GNOME Bugzilla)]

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

--- Comment #13 from Nicolas Dufresne (stormer) <nicolas at ndufresne.ca> ---
Some heads up, in order to help fixing this, I've added crop meta support to
videocrop element. This way we can generate any kind of crop meta for testing.
As expected, it failed badly with pretentious elements that thinks they can
handle crop meta without looking at it (videoconvert ;-P). For now,
videoconvert no longer pretend that, a solution to that is required to
figure-out how to control the allocation caps in GstBaseTransform, I'll file a
sep bug. Fixing this will open up a large amount of use cases.

Second row of issues, sink sometimes need to copy images. But sinks tends to
copy to a pool initialized from caps, which is not padded. That cause the
gst_video_frame_copy() call to fail. The sink needs to do lazy allocation of
internal pool, and base their pool on the GstVideoMeta width/height. As a side
effect, it needs to check for any GstVideoMeta changes. This reminds me a bit
the caps in 0.10 though. Note that looking at decide_allocation won't work, the
pool used to allocate the buffers your be larger without coming from the sink
pool.

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

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