[Bug 779310] New: tsdemux: racy handling of concurrent seek events in push mode

[GStreamer (GNOME Bugzilla)]

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

            Bug ID: 779310
           Summary: tsdemux: racy handling of concurrent seek events in
                    push mode
    Classification: Platform
           Product: GStreamer
           Version: git master
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: gst-plugins-bad
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: rawoul at gmail.com
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

When configured in push mode, tsdemux can generate a segment while flushing or
with wrong values, when two consecutive seek events are handled in parallel.
This can stall the pipeline for very long times.

Here's a stripped/tweaked log from tsdemux that exhibits this issue:

stm0: seek to 95032ms from start

<tsdemux0> seek event, rate: 1.000000 start: 0:01:35.032000000 stop:
99:99:99.999999999
<tsdemux0> Got event flush-start
<tsdemux0> Got event flush-stop
<tsdemux0> soft flush of all streams
<tsdemux0> Got event segment
<tsdemux0> soft flush of all streams
<tsdemux0:audio_0_0045> first PTS 0:01:32.669048481
<tsdemux0:video_0_0044> first PTS 0:01:33.429048481
<tsdemux0> Pushing segment event: 0x73d06ec0, time 99:99:99.999999999, seq-num
1133, GstEventSegment, segment=(GstSegment)"GstSegment,
flags=(GstSegmentFlags)GST_SEGMENT_FLAG_NONE, rate=(double)1,
applied-rate=(double)1, format=(GstFormat)GST_FORMAT_TIME, base=(guint64)0,
offset=(guint64)0, start=(guint64)92669048481,
stop=(guint64)18446744073709551615, time=(guint64)92669048481,
position=(guint64)92669048481, duration=(guint64)18446744073709551615;";

stm0: seek to 125032ms from start

<tsdemux0> seek event, rate: 1.000000 start: 0:02:05.032000000 stop:
99:99:99.999999999
<tsdemux0> Got event flush-start
<tsdemux0> Pushing segment event: 0x73d06e80, time 99:99:99.999999999, seq-num
1133, GstEventSegment, segment=(GstSegment)"GstSegment,
flags=(GstSegmentFlags)GST_SEGMENT_FLAG_NONE, rate=(double)1,
applied-rate=(double)1, format=(GstFormat)GST_FORMAT_TIME, base=(guint64)0,
offset=(guint64)0, start=(guint64)0, stop=(guint64)18446744073709551615,
time=(guint64)0, position=(guint64)0, duration=(guint64)18446744073709551615;";
<tsdemux0:audio_0_0045> first PTS 0:01:34.525048481
<tsdemux0> Got event flush-stop
<tsdemux0> soft flush of all streams
<tsdemux0> Got event segment
<tsdemux0> soft flush of all streams
<tsdemux0:video_0_0044> first PTS 0:02:03.429048481

GStreamer-WARNING **:
../../gitsrc/gst/gstpad.c:4429:gst_pad_push_data:<tsdemux0:video_0_0044> Got
data flow before segment event
GStreamer-WARNING **:
../../gitsrc/gst/gstpad.c:4176:gst_pad_chain_data_unchecked:<multiqueue0:sink_0>
Got data flow before segment event
...

In this example the second segment is sent too early, and its start value is
invalid. The start value should be the lowest PTS in all streams received after
the seek event, but here no data was received yet (flush_stop hasn't even been
received yet).

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