[Bug 743363] 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

--- Comment #2 from Aurélien Zanelli <aurelien.zanelli at parrot.com> 2015-01-30 14:32:48 UTC ---
(In reply to comment #1)
> (In reply to comment #0)
> > 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.         
> 
> This is correct, did you try to debug why it happens again?

Yes, in my understanding, it is due to the fact that when I lost some packets,
the tsdemux obviously stop outputting buffers, hence segment.position is not
updated anymore. But pipeline clock keeps running.
When new data come again, tsdemux create a new segment and since I calculate
segment.base using the last known position, result could be far from elapsed
running-time.

For instance let assume following scenario.
We begin with following segment: start=0, stop=GST_CLOCK_TIME_NONE, base=0
Signal is good, tsdemux outputs buffers and tsdemux->segment.position is
updated each time. And running-time increase accordingly from 0.
Then some packets are lost. Before the gap, we pushed a buffer with PTS=ts1 so
tsdemux->segment.position=ts1 and running-time is rt1.
After a time 'tg', data comes again. At this moment running-time is rt2 = rt1 +
tg and first PTS after gap is roughly ts2 = ts1 + tg.
So we reach the point tsdemux calculate a new segment. So with my calculation:
segment.base = gst_segment_to_running_time(segment, GST_FORMAT_TIME, ts1) =
somewhere around rt1 = rt1' with rt1' < rt2.
segment.start = segment.position = ts2
segment.stop = GST_CLOCK_TIME_NONE

When buffer with PTS ts2 reach the sink, it's running time will be:
brt = ts2 - segment.start + segment.base = ts2 - ts2 + rt1' = rt1'


> 
> > 
> > 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.
> >
> 
> How is this different from the approach you stated above?
I just set segment.base to current running-time, I didn't track position at
all. But my doing this, I avoid the issue described above.

-- 
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.