videoaggregator: delay using new caps from a sink pad until the next buffer in the...
authorGeorge Kiagiadakis <george.kiagiadakis@collabora.com>
Tue, 4 Apr 2017 08:25:43 +0000 (11:25 +0300)
committerOlivier CrĂȘte <olivier.crete@collabora.com>
Sat, 20 May 2017 14:21:16 +0000 (16:21 +0200)
commit39d2526c34d2185c9d42a95ede8171b2d47fed18
tree01d4231c8f5d0fbf4156a68efae711efb5d954f9
parentd2335bce9b96c95edeb4bafdabcf4ba39def8ade
videoaggregator: delay using new caps from a sink pad until the next buffer in the queue is taken

When caps changes while streaming, the new caps was getting processed
immediately in videoaggregator, but the next buffer in the queue that
corresponds to this new caps was not necessarily being used immediately,
which resulted sometimes in using an old buffer with new caps. Of course
there used to be a separate buffer_vinfo for mapping the buffer with its
own caps, but in compositor the GstVideoConverter was still using wrong
info and resulted in invalid reads and corrupt output.

This approach here is more safe. We delay using the new caps
until we actually select the next buffer in the queue for use.
This way we also eliminate the need for buffer_vinfo, since the
pad->info is always in sync with the format of the selected buffer.

https://bugzilla.gnome.org/show_bug.cgi?id=780682
gst-libs/gst/video/gstvideoaggregator.c
gst-libs/gst/video/gstvideoaggregatorpad.h
gst/compositor/compositor.c