Re: [AVTCORE] Leap seconds

[Kevin Gross <[e-mail]>]

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.

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.
Most RTP receivers now use local data arrival time to determine playout
time. 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.

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