[Bug 746087] GstVideoCropMeta implementation is inconsistent

[GStreamer (GNOME Bugzilla)]

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

--- Comment #8 from Nicolas Dufresne (stormer) <nicolas.dufresne at collabora.co.uk> ---
I wonder how the proposed changes here could have helpd solving recent issues
we had with libav video decoding. Here's the situation:

What happens in libav is that the video decoder only know the memory size at
the time of the allocation. As of now, because we still rely on sending caps
(hence display size) before doing the allocation query, the decoder will create
an internal (and tempory) pool with the requires alignments, and caps with the
memory size as described here. Later the decoder is informed of the display
size and negotiate (both the caps and the pool, though with display size).
Later, we find that downstream pool is not suitable for our needs (e.g. missing
VideoAlignment) but downstream do support the VideoMeta. We'd like to simply
push from our internal pool, but that leads to later failure downstrea, because
the width/height of the GstVideoMeta is larger. While this is acceptable for
frame_map() this completly fails for video_frame_copy(). Vaapisink
(unexpectedly) endup giving video_frame_copy() a src frame that is bigger
(memory size) then the dest frame (display size).

So the question is how precisely this should be handled ? I understand we'd
like avviddec to run the allocation query with the memory size in caps instead
(in the future even run that before caps if ever possible), but as avviddec is
not using downstream pool. It seems like a lot of work to for the the sink to
remember the memory size in order to use that for frame_copies later. Shall we
simply allow copying bigger to small in video_frame_copy ?

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