[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
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED
   Target Milestone|HEAD                        |1.3.1

--- Comment #8 from Edward Hervey <bilboed at bilboed.com> 2013-09-28 11:28:44 UTC ---
And fixed with latest commits.

commit 2762ead5ef2a16885fbb6918dae9b8df836a361f
Author: Edward Hervey <edward at collabora.com>
Date:   Fri Jul 26 07:54:30 2013 +0200

    mpegtsdemux: New PCR<=>Offset estimation code

    This allows:
    * Better duration estimation
    * More accurate PCR location
    * Overall more accurate running-time location and calculation

    Location and values of PCR are recorded in groups (PCROffsetGroup)
    with notable PCR/Offset observations in them (when bitrate changed
    for example). PCR and offset are stored as 32bit values to
    reduce memory usage (they are differences against that group's
    first_{pcr|offset}.

    Those groups each contain a global PCR offset (pcr_offset) which
    indicates how far in the stream that group is.

    Whenever new PCR values are observed, we store them in a sliding
    window estimator (PCROffsetGroupCurrent).

    When a reset/wrapover/gap is detected, we close the current group with
    current values and start a new one (the pcr_offset of that new group
    is also calculated).

    When a notable change in bitrate is observed (+/- 10%), we record
    new values in the current group. This is a compromise between
    storing all PCR/offset observations and none, while at the same time
    providing better information for running-time<=>offset calculation
    in VBR streams.

    Whenever a new non-contiguous group is start (due to seeking for example)
    we re-evaluate the pcr_offset of each groups. This allows detecting as
    quickly as possible PCR wrapover/reset.

    When wanting to find the offset of a certain running-time, one can
    iterate the groups by looking at the pcr_offset (which in essence *is*
    the running-time of that group in the overall stream).
    Once a group (or neighbouring groups if the running-time is between two
    groups) is found, once can use the recorded values to find the most
    accurate offset.

    Right now this code is only used in pull-mode , but could also
    be activated later on for any seekable stream, like live timeshift
    with queue2.

    Future improvements:
    * some heuristics to "compress" the stored values in groups so as to keep
      the memory usage down while still keeping a decent amount of notable
      points.
    * After a seek compare expected and obtained PCR/Offset and if the
      difference is too big, re-calculate position with newly observed
      values and seek to that more accurate position.

    Note that this code will *not* provide keyframe-accurate seeking, but
    will allow a much more accurate PCR/running-time/offset location on
    any random stream.
    For past (observed) values it will be as accurate as can be.
    For future values it will be better than the current situation.
    Finally the more you seek, the more accurate your positioning will be.

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