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)
commit2a60a9f66fe3754ca1799eba5f08de28744572ec
tree546ad5b714983114304366b45f39e93a1d1a9861
parentcbafb022aad17976d4da44cee13a4872872c8441
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/compositor/compositor.c