Re: [AVTCORE] Leap seconds

[David Singer <[e-mail]>]

On Sep 14, 2011, at 17:47 , Kevin Gross wrote:

> As is hinted there, UTC as a timebase can be made to work but it is tricky and deserves to be documented. Senders and receivers especially need to be aware of leap seconds when mapping wallclock to the media clock. This requires a level of integration between the NTP agent and the media player.
> 
> Receivers that are unaware of leap seconds will slew a second ahead of others when there's a leap second while streams are running. This is is likely to result in ongoing buffer underruns at the receiver until the stream is restarted.

Only if they calculate the NTP 'seconds since' by calculating from a calendar date and time. The number of seconds-since doesn't change (the length of a second is fairly precisely defined).  "X seconds since the zero-time" is precise; calculating that from "13:45:23 on september 10th 2011" means you have to know not only the length of a day in seconds, but what leap second adjustments to make.

> Alternatively applications can agree (through SDP?) to use a TAI timebase (e.g. IEEE 1588) and avoid the complexity and potential implementation errors leap seconds introduce.
> 
> This all only applies to receivers that use NTP to determine playout time.

, and that map between calendar date+time and seconds counts.

> Most RTP receivers now use local data arrival time to determine playout time.

Yes, true; receive data, de-jitter, play (taking into account re-ordering issues).

> The IDMS proposal (https://datatracker.ietf.org/doc/draft-brandenburg-avt-rtcp-for-idms/) relies on NTP timestamps. It would seem to be necessary to address the leap second issue as part of the IDMS project.

Only if calendar date+time mapping comes into play, I think.

> 
> Kevin
> 
> On Wed, Sep 14, 2011 at 4:18 PM, David Singer <[e-mail]> wrote:
> OK, I am not an expert, but 1305 does say:
> 
> The insertion of leap seconds in UTC and subsequently
> into NTP does not affect the UTC or NTP oscillator, only the conversion
> to conventional civil UTC time.
> 
> 
> On Sep 14, 2011, at 12:54 , Kevin Gross wrote:
> 
>> RFC 5905 indicates that the 64-bit NTP timestamps used by the NTP protocol are a bit more complex than that. Specifically, these NTP timestamps have discontinuities around leap seconds. RFC 3550 does not spell it out exactly but I assume the 64-bit NTP timestamp in the RTCP sender report sould behave according to the definition in RFC 5905.
>> 
>> Kevin
> 

David Singer
Multimedia and Software Standards, Apple Inc.