[Bug 762543] xvimagesink: wrong pool selection when rendering buffers having GstVideoCropMeta attached

[GStreamer (GNOME Bugzilla)]

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

--- Comment #3 from sreerenj <bsreerenj at gmail.com> ---
(In reply to Sebastian Dröge (slomo) from comment #2)
> It would be good to use the pool independent of propose_allocation() I
> guess, and if upstream provides different buffers we would copy the buffers
> into the ones from our pool.
> 
> The resolution in propose_allocation() would be the allocation resolution,
> the one in set_caps() is the display resolution. And then for each buffer
> you need to check the crop meta to decide how much should be cropped and
> how. And you can get a propose_allocation() that is completely unrelated to
> the current CAPS and buffers you receive (maybe upstream has more buffers
> queued up in some old format, maybe upstream decided to not use your pool
> and do things differently, ...).

This is exactly the case here, how to handle
gst_video_frame_map()/gst_video_frame_copy() in gst_xv_image_sink_show_frame..

We can't use the GstVideoInfo received in set_caps() , The actual video_info
should be the one derived from propose_allocation.

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