[Bug 780682] compositor: corrupts output when input caps change while running

[GStreamer (GNOME Bugzilla)]

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

Olivier Crête <olivier.crete at ocrete.ca> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED
   Target Milestone|git master                  |1.13.1

--- Comment #16 from Olivier Crête <olivier.crete at ocrete.ca> ---
Merged as:

commit 39d2526c34d2185c9d42a95ede8171b2d47fed18
Author: George Kiagiadakis <george.kiagiadakis at collabora.com>
Date:   Tue Apr 4 11:25:43 2017 +0300

    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

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