Skip to content

streamsynchronizer: Consider streams having received stream-start as waiting

Enrique Ocaña González requested to merge eocanha/gstreamer:eocanha-007 into main

When using the custom WebKitMediaSrc element (used by WebKit and able to perform an initial seek in playbin), a stall caused by streamsynchronizer was detected during an initial seek. The flow of events revealed that the intertwining of the initial configuration of the streams with the reset caused by the flush events from the seek left streamsynchronizer in an inconsistent state:

 streamsynchronizer0:sink_0 (video) events, starting before the seek:
  stream-start --> Sets the stream to wait
  flush-stop --> Clears the stream wait flag
  caps
  tag
  segment
  stream-collection
  (buffers start to come and flow properly)

 streamsynchronizer0:sink_1 (audio) events, happening after seek:
  (no flush events, because the stream hadn't been initialized when the seek happened)
  stream-start --> Sets the stream to wait
  caps
  segment
  (stalled because the stream is in wait mode!)

The code in streamsynchronizer expects that all the streams are in wait state before releasing all of them at once. The flush on the video stream broke that assumption and that's why the audio stream is never released in that scenario.

Avoiding the clearing of the wait flag on flush-stop isn't an actual solution to the problem, as it creates other side effects and at least makes the gst-editing-services/seek_with_stop test to timeout. The alternate solution implemented in this patch consists on recording when the stream-start event is received and then consider those started streams equally valid as those in waiting state when evaluating if all the streams should be unblocked.

Edited by Enrique Ocaña González

Merge request reports