[Bug 740747] tsdemux: adjust upstream time segment if needed

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=740747
  GStreamer | gst-plugins-bad | 1.4.4

--- Comment #3 from Matthieu Bouron <matthieu.bouron at collabora.com> 2014-12-02 10:06:22 UTC ---
(In reply to comment #2)
> What exactly are you trying to solve ?

What is doing that particular element (which is proprietary) is pushing a TIME
segment with segment.start equals to the first PTS of the mpegts stream.
In my example it was 16:30:00.00~

But it was also affecting the buffers PTS to values not within the TIME segment
it is emitting (it was starting at around 00:01:00.00~ which looks like the
computation of the running time -> currentPts-basePts).
That was making tsdemux having a clock base of 00:01:00.00 instead of
16:30:00.00, and the mpegts PTS/DTS was shifted to that base.
I modified this element so the PTS/DTS are the current one corresponding to the
buffer and so it falls in the TIME segment the element emits.

The element is used to push recorded mpegts streams.

Can you confirm it is OK to do that ?

> 
> Getting an incoming segment with a start value equal to the first internal PTS
> of the stream is ... rare (make that almost impossible, PCR/PTS/DTS aren't
> meant to be predictable.).
> 
> The _incoming_ segment start value is to provide the basis of the running time
> for the _incoming_ stream.
> 
> If you have the beginning of a non-live TIME stream (from hlsdemux, or dlna
> sources), then your incoming stream is *starting* at running-time 0 (unless you
> purposefully want to shift/delay the rendering of that stream).
> => Your incoming segment.start and initial buffer should have identical running
> time (0, 5000, whatever, doesn't matter).
> 
> Note that those streams are not *live* per-se. Not every buffer will be
> timestamped. Heck, you don't even *need* to timestamp any buffer. If there are
> no timestamps => That incoming stream implicitely starts at running-time 0.
> 
> The only time where you will have timestamps on every/most incoming buffers is
> when it comes from an actual live source (DVB or RTP) where several things will
> happen:
> 1) the running-time of incoming buffers will not start at zero (there's a delay
> between the moment the pipeline goes to PLAYING and the moment the first buffer
> is captured by the sources). We need to propagate that running-time downstream,
> otherwise we'll end up with data always arriving late in the sinks (if your
> pipeline is live).
> 2) we need precise capture time on every buffers to correlate it with the
> internal PCR values (remote clock observations) to estimate the clock
> skew/drift (the remote clock might be going faster/slower than are local
> clock).

Thanks for those explanation, it is really helpful !

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