[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

Edward Hervey <bilboed> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEEDINFO
                 CC|                            |bilboed at bilboed.com

--- Comment #2 from Edward Hervey <bilboed at bilboed.com> 2014-12-02 08:44:01 UTC ---
What exactly are you trying to solve ?

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

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