multiqueue: Fix interleave calculation for data before segment start
authorEdward Hervey <edward@centricular.com>
Wed, 2 Mar 2022 16:07:37 +0000 (17:07 +0100)
committerGStreamer Marge Bot <gitlab-merge-bot@gstreamer-foundation.org>
Wed, 9 Mar 2022 18:49:51 +0000 (18:49 +0000)
This commit modifies the interleave calculation to allow growing when incoming
data is before the segment start.

The rationale is that there is no requirement whatsoever for data before the
segment start to be "coherent" on all streams.

For example, a demuxer could rightfully send data from the video stream from the
previous keyframe (potentially quite a bit before the segment start) and the
audio from just before the segment start.

This will activate the same logic as growing the interleave when some streams
haven't received buffers yet.

Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1892>

subprojects/gstreamer/plugins/elements/gstmultiqueue.c

index 50fd839..e900520 100644 (file)
@@ -1602,6 +1602,17 @@ calculate_interleave (GstMultiQueue * mq, GstSingleQueue * sq)
         low = oq->cached_sinktime;
       if (high == GST_CLOCK_STIME_NONE || oq->cached_sinktime > high)
         high = oq->cached_sinktime;
+
+      /* If the input is before the segment start, consider as inactive to allow
+       * the interleave to grow until *all* streams have data within the segment.
+       *
+       * The reason for this is that there is no requirements for data before
+       * the segment start to be "aligned" and therefore interleave calculation
+       * can't reliably be done. For example a demuxer could provide video data
+       * from the previous keyframe but audio only from just before the segment
+       * start */
+      if (oq->cached_sinktime < 0)
+        some_inactive = TRUE;
     }
     GST_LOG_OBJECT (mq,
         "queue %d , sinktime:%" GST_STIME_FORMAT " low:%" GST_STIME_FORMAT