[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 #6 from Aurélien Zanelli <aurelien.zanelli at parrot.com> 2015-01-30 15:57:08 UTC ---
(In reply to comment #4)
> 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?

Yes, I could give a try

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