Re: [AVTCORE] Leap seconds

[Magnus Westerlund <[e-mail]>]

On 2011-09-19 22:07, Kevin Gross wrote:
> Yes, well, there it is in all the gory detail.
> 
> The point I'm try to get to is that any behavior that doesn't move the
> timestamp forward at a constant rate will be a problem for RTP. You
> appear to be reading it as I have. NTP time is UTC time and so there's
> non-uniform behavior around leap seconds.

Assuming that the NTP clock freezes or semi freezes during the leap
seconds I see two effect happening.

One issue is that an system reading it's clock during the leap second
itself will get different values depending on if the system uses true
NTP time or POSIX time. Thus potentially creating up to a second of
mismatch due to this.

The second issue appears to be that if the two systems are not precisely
aligned the leap second will appear to occur at different time from a
outside observer. That will result that the system that first implements
the leap second will appear to be out of sync with 1 second until the
second system also performs the leap second. Thus you suddenly see a 1
second sync correction that the receiver system might start correct for,
then that difference disappears when the other system also have had its
leap second event. Thus resulting in adjusting back again.

The above can cause different media streams to be out of sync at the
receiver for the time when only one of the media stream's SR has been
delivered.

I would note that leap seconds are rare. They have occurred 24 times
since 1970. And there has been only 2 during the 2000 decade.

>From my perspective, unless you have a really high performance
application, the leap second event will at most cause some sync
adjustments with potentially media out of sync that will be corrected as
soon as both sender and receiver has passed the leap second event and
SRs has been delivered in both cases.

I think the reasonable thing to do is simply to ignore SRs that indicate
an approximately 1 second adjustment on a media stream when in close
proximity to a leap second event. This would works fine as long as the
two involved nodes would not be more out of sync than the guard period
where this algorithm is active.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  [phone]
Färögatan 6                | Mobile [phone]
SE-164 80 Stockholm, Sweden| mailto: [e-mail]
----------------------------------------------------------------------