Skip to content

streamsynchronizer: Setting invalid segment.base if SEEK events are handled in parallel and some streams are finished flushing before others started

Submitted by Sebastian Dröge @slomo

Link to original bug (#771479)

Description

Problem here is that we send steps only to the video sink, which makes sense. BUFFERS format makes no sense for audio, but for video it is frames.

That however causes the audio sink to not move anywhere, which has to negative side effects:

  1. in reverse mode, this means that the video position goes backwards with every step but audio stays the same. The position query returns the maximum of all values, so it always returns the (constant) audio position

  2. in general, we move video but not audio. After a while queues run full and we lock up because the audio did not consume any data at the same time.

My idea for a solution here is to keep track of how much video we stepped (position queries and the step messages), and then do a TIME step on the audio sink in the same way to catch up. And only then forward the step-done message.