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

[GStreamer (GNOME Bugzilla)]

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

--- Comment #3 from George Kiagiadakis <gkiagia at tolabaki.gr> ---
So, it looks like the actual problem in my case is not that the caps event is
not being processed in the src pad thread. The race in bug 779945 happens when
the queue is empty, which is not the case here.

The actual problem is that the framerate of the image stream in my example is
smaller than the framerate of the videotestsrc stream and this is what happens:

The last 320x240 buffer in c:sink_1 has pts=0.8s, while the first 640x480 one
has pts=0.9s
Compositor generates an output buffer (320x240) with t=0.8s, using the last
320x240 input buffer in the queue.
Right after that, it processes the caps event that was serialized and changes
the format to 640x480.
Next, it tries to generate the next output frame, which must have pts=0.833s,
since the output framerate is 30/1.
It considers the 640x480 frame, but notices that its PTS is 0.9s, so it keeps
it in the queue for later and continues using the previous frame (320x240).
Boom.

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