[Bug 704331] New: Clock estimation (aka: Forward QoS)

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=704331
  GStreamer | gstreamer (core) | git

           Summary: Clock estimation (aka: Forward QoS)
    Classification: Platform
           Product: GStreamer
           Version: git
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: Normal
         Component: gstreamer (core)
        AssignedTo: gstreamer-bugs at lists.freedesktop.org
        ReportedBy: bilboed at gmail.com
         QAContact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---


Problems:
    Currently elements that do remote clock estimation modify the values
    of the buffer timestamps they output.

    This causes several problems:
      * Loss of original information
         An original perfect 25fps video stream ends up having buffers
         no longer spaced by 1/25th of a second.
      * Correction should only be applied when doing synchronzation
        in, and only in, the current pipeline and with the same clock.
          If the stream is stored in a file, the time corrections are
          stored with it and the resulting file ends up playing back
          faster/slower than targetted.

Goal: For live systems split the remote clock estimation/correction
   into two parts:
     1) Remote clock estimation is done in elements that can do it
     2) Elements capable of clock estimation do not modify the original
        values of in-band timing and instead only modify the segment
        values such that the running-time of buffers being outputted
        is coherent with the running-time of buffers it received.
     3) Synchronization correction is only done in elements that
        actually wait against the clock.


Proposal:
  New event GST_EVENT_CLOCK_CORRECTION (in-band, sticky)

  Fields:
    GstClockTime time : The running-time of the clock to which this
                        correction applies.
    GstClockTimeDiff offset : The correction to apply to 'time' (can
                              be negative)
    gdouble rate : The long-term rate correction.

  GstEvent *gst_event_new_clock_correction (GstClockTime time,
                                            GstClockTimeDiff offset,
                        gdouble rate);

  gboolean gst_event_parse_clock_correction (GstEvent *event,
                              GstClockTime *time,
                         GstClockTimeDiff *offset,
                         gdouble *rate);

Description

  Over time the rate will stabilize. We get a more and more accurate
   estimation of the remote clock rate.

  The rate might change if the nature of the remote source changes (such
   as changing from one participant in a RTP multi-participant conference
   to another). It does also appear to change on some DVB channels when
   the nature of the feed changes from pre-recorded to live (by a few
   parts-per-million (ppm). Finally it can also change when changing
   DVB channels.

   If rate == 1.0, this means that the remote provider is using a
    clock with the same exact rate as the clock locally used.

   If rate > 1.0, this means that the remote provider is using a
    clock which has a slower rate than the clock locally used.
    Buffers end up being synchronized slower (we end up with
    a target synchronization running time bigger (and therefore later).

   If rate < 1.0, this means that the remote provider is using a
    clock which has a higher rate than the clock locally used.
    Buffers end up being synchronized faster (we end up with a target
    synchronization running timer smaller (and therefore earlier).


  The offset correponds to the exact correction that needs to be applied
   for a given running time.

  Initially more corrections will be needed while the rate stabilizes, so
   this helps ensures that we can still get exact corrections instantly.

  This also helps to do one-shot adjustments quickly. This could happen
   if there is a routing/networking change between the remote device and
   the local device which would affect the travel latency (but not the
   rate).


  Rate of emission of the event is left up to the element providing them
  but an expected usage would be to:
   * Assume an initial rate of 1.0 without any correction
   * As soon as a new corrected timestamp diverges too much from the
     the previous (or assumed) correction/rate, it send an update and
     remember the new correction/rate for future values.

  Until a new correction is sent, any new running-time received will be
  corrected as such:

    T  : clock_correction.time
    C  : clock_correction.offset
    R  : clock_correction.rate
    T2 : running-time > T

    Corrected time for T2 = R * T2 + C

    (and for those following, since the default values are R=1.0 and C=0.0,
     ... no correction is applied when no clock correction event was
     received).


Clarification needed:

 What happens in the case where we have multiple clock estimation
 systems chaining each other, such as mpeg-ts over rtp ?
   1) Second one "drops" the first observations ?
   2) Second one disables its observation system ?
   3) Second one uses it to fine-tune its own observations ?

 What happens in the case where we multiplex streams with different
 clock estimation, such as several different RTP sources into one
 mpeg-ts program (with one clock/PCR) we want to transmit live ?

   (Note: in the case where we multiplex into different mpeg-ts programs,
    the problem doesn't occur since we can use different PCR streams,
    with different clocks per program).

 A new method for storing/calculating "corrected" running-time ?
 This shouldn't modify gst_segment_to_running_time() since that is
 used outside of clock-synchronized elements ?

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