Clock estimation (aka: Forward QoS)
Submitted by Edward Hervey
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.
New event GST_EVENT_CLOCK_CORRECTION (in-band, sticky)
GstClockTime time : The running-time of the clock to which this
GstClockTimeDiff offset : The correction to apply to 'time' (can
gdouble rate : The long-term rate correction.
GstEvent *gst_event_new_clock_correction (GstClockTime time,
gboolean gst_event_parse_clock_correction (GstEvent *event,
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
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 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).
What happens in the case where we have multiple clock estimation
systems chaining each other, such as mpeg-ts over rtp ?
- Second one "drops" the first observations ?
- Second one disables its observation system ?
- 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 ?