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.
For live systems split the remote clock estimation/correction into two parts:
- Remote clock estimation is done in elements that can do it
- 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.
- Synchronization correction is only done in elements that actually wait against the clock.
GST_EVENT_CLOCK_CORRECTION (in-band, sticky)
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);
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).
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 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 ?