[Bug 608148] [tsdemux] Better handle PCR<=>PTS conversion (big difference, latency, ...)

[GStreamer (bugzilla.gnome.org)]

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

Edward Hervey <bilboed> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[mpegtsdemux] Wrong start   |[tsdemux] Better handle
                   |value in NEWSEGMENT events  |PCR<=>PTS conversion (big
                   |                            |difference, latency, ...)
           Severity|normal                      |major

--- Comment #6 from Edward Hervey <bilboed at gmail.com> 2013-07-15 16:15:57 UTC ---
grmbl, this might require some re-thinking of how PCR/PTS are handled.

Right now if upstream provides timestamped buffers (dvb, hls, ...) we assume
(wrongly) that the same clock is used for PCR and PTS.... and not just the same
clock "rate".

As a result, we end up with something like the following:
Input buffer timestamp : 0s
First PCR seen : 15 hours
First PTS seen : 19 hours

... and we end up with a first timestamps of 19 - 15 = 4 hours :(

Note that this issue will also happen when working with non-timed input also
now that I look at it.


Maybe something smarter would be, if no base PTS has been established to:
* Calculate lowest PTS between all streams
* Figure out PCR when beginning of that buffer was received
* Use that "smallest (PCR vs PTS) diff" as a base pts time

And then report for the latency:
* Difference between smallest and biggest PTS accross all stream pids of a
program.

This is in par with a discussion that took place (late at night) in Milan
during GStreamer hackfest.

Changing title accordingly

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