[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 #4 from Thiago Sousa Santos <thiagossantos at gmail.com> 2015-01-30 15:32:52 UTC ---
Had a quick chat about this on IRC:

<thiagoss> bilboed, https://bugzilla.gnome.org/show_bug.cgi?id=743363 do you
know the proper way to fix this? The question is "when mpegts gets a discont,
how should the new segment look like to keep running-time going?"
<stormer> I wonder if a lost packet should affect the segment
<stormer> I would have expected the depayloader to send a gap, not a set
discount
<__tim> there's no need to generate a new segment event just because there's
some data loss
<__tim> if the input is live, the clock will continue running, the new data
will be timestamped based on the running clock and all will be well again
<thiagoss> Couldn't the stream/program have completely changed after the
discont?
<azanelli> tsdemux flushed the streams, then create new ones I think
<__tim> (everything else normal)
<thiagoss> The current implementation is that a flush will push all pending
data and the streams will be reset (and be marked for creating a new segment)
<__tim> uh
<__tim> maybe discont has been "overloaded" by hls etc?
<thiagoss> __tim, I agree that a new segment isn't needed. But isn't there a
corner case where the upstream signal could be completely different after the
discont and would really need a new segment?
<wtay> that would be stream-start
<thiagoss> __tim, afaik hls would only send a discont when it switches
bitrates, and even so, it creates a new pad
<__tim> thiagoss, maybe, but I'm assuming it's an otherwise continuous stream
for now, it seems a bit over the top to do a big reset just because there was
some packet loss
<wtay> discont is just a missing packet
<thiagoss> wtay, *nod*
<thiagoss> Will comment on the bug for the reporter to update his fix
<__tim> if data comes from hls (e.g. bitrate switch) it might be completely
different streams of course
<wtay> or after a seek or so, the stream is the same but the packet does not
follow the previous packet for some reason
<__tim> but that should be detected otherwise
<wtay> with stream-start IMHO

===
So, it seems that a buffer marked with a discont flag is causing the streams to
be flushed and marked as needing a new segment. It shouldn't be marked for a
new segment just for a discont. This should fix the issue for you.

Would be willing to write a patch for this?

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