[Bug 743363] New: tsdemux: push segment that cause sink to think it's late

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=743363
  GStreamer | gst-plugins-bad | git master

           Summary: tsdemux: push segment that cause sink to think it's
                    late
    Classification: Platform
           Product: GStreamer
           Version: git master
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: major
          Priority: Normal
         Component: gst-plugins-bad
        AssignedTo: gstreamer-bugs at lists.freedesktop.org
        ReportedBy: aurelien.zanelli at parrot.com
         QAContact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---


I stream a video over wifi with rtp/udp and when, I think, some discontinuities
occurs, the playback become jerky and video sink complains about frames being
too late.
I try to debug the thing and I end up in the tsdemux segment related stuff.

In my current understanding, when the stream start, a new segment is created:
creating segment event time segment start=0:00:00.000000000,
offset=0:00:00.000000000, stop=99:99:99.999999999, rate=1,000000,
applied_rate=1,000000, flags=0x00, time=0:00:00.000000000,
base=0:00:00.000000000, position 0:00:00.000000000, duration 99:99:99.999999999
and propagated downstream.
tsdemux push buffers with pts starting from 0 and when the sink synchronize
to the clock, it check buffers running time using segment by doing basically
with current configured segment: buffer.timestamp - segment.start and compare
it to current pipeline running time.
At this moment, everything is good.                                             

But when discontinuity happens, I notice that tsdemux streams are flushed and
when data come again, tsdemux output a new segment using the first ts found in
new created stream. For instance:
creating segment event time segment start=0:00:10.833594372,
offset=0:00:00.000000000, stop=99:99:99.999999999, rate=1,000000,
applied_rate=1,000000, flags=0x00, time=0:00:00.000000000,
base=0:00:00.000000000, position 0:00:10.833594372, duration 99:99:99.999999999

At this moment when buffers reach the sink, their running-time are              
B.timestamp - S.start with B.timestamp starting from 0:00:10.833594372.         
So for the first buffer which have the timestamp set to the same as
segment.start, ie 0:00:10.833594372, its running-time is 0 but pipeline
running-time is 10s beyond causing the sink to complain and think it's too
late.

As a result, I think the involved code is
http://cgit.freedesktop.org/gstreamer/gst-plugins-bad/tree/gst/mpegtsdemux/tsdemux.c#n1999

Since this 'use case' works on 1.2, my first try was to remove this code to use
the old behavior.
It make the playback work, but I don't think it's the way to go :)              

Then I look more closely to GstSegment and times formula and see that
segment.base is in the one used to get buffer running-time. According to design 
documentation, segment.base is the total elapsed running-time of any previous
segment.
Hence I try to track position in the current defined segment, and when a new
one is defined, set segment.base using
gst_segment_to_running_time(previous-segment, GST_FORMAT_TIME,
previous-segment-position);
It works better but after a while, issue happens again, maybe due to some
drift.         

For records, I also tried some foolish things like setting segment.base to
current element running-time or segment.start. It's work in my case but I'm
pretty sure it's not the way to fix this and it breaks many things.

So I'm quite lost and need some help to solve this issue.
Is my understanding right ? Which is the preferred way to solve it ?

To help debugging it, I dump a stream received over network by using gdppay 
so this issue can be easily reproduced with the following pipeline:
gst-launch-1.0 filesrc location=dump.ts ! gdpdepay ! tsdemux ! video/x-h264 !
fakesink sync=true qos=true max-lateness=20000000

I used a fakesink here to reduce number of element involved, but video can be
decoded as well and I used following debug for my analysis:
basesink:5,tsdemux:5,GST_EVENT:5

The dump file can be downloaded here:
http://www.darkosphere.fr/tmp/tsdemux-segment-issue/dump.gdp
(sorry for slow Internet connection).

P.S: I set severity to major since it's work on 1.2, but feel free to lower it.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.