[FFmpeg-devel] [PATCH] Use monotonic clock for measuringreltime.

[Reimar Döffinger]

On Wed, Apr 02, 2014 at 12:46:56PM -0400, Don Moir wrote:
> ----- Original Message ----- From: "Reimar Döffinger"
> <Reimar.Doeffinger at gmx.de>
> To: "FFmpeg development discussions and patches" <ffmpeg-devel at ffmpeg.org>
> Sent: Wednesday, April 02, 2014 12:46 PM
> Subject: Re: [FFmpeg-devel] [PATCH] Use monotonic clock for measuringreltime.
> 
> 
> >On 02.04.2014, at 18:18, "Don Moir" <donmoir at comcast.net> wrote:
> >>Le tridi 13 germinal, an CCXXII, Don Moir a écrit :
> >>>>The wall time can change by a second or seconds forward or backward
> >>>>depending on automated clock updates and user setting.
> >>
> >>>They are bogus settings. Modern operating systems can smooth the correction
> >>>over a period of time to update the clock by a small amount.
> >>
> >>Reality is it happens.
> >
> >As mentioned other things happen as well, for example the monotonic clock
> >not being affected by these changes, which if they are corrections is not
> >necessarily better.
> >Plus, I don't think you quite finished why it makes it unsuitable.
> >Even with those clock updates it doesn't make it worse than TS timestamps
> >(though I admit being worse would be quite an achievement).
> >Though I wasn't really arguing against using it (at least optionally), my
> >main point is I just think the underlying issues (if there are any) need
> >to be fixed either way.
> >
> >>>>Can change during daylight savings time switch over by an hour as well.
> >>
> >>>Wrong.
> >>
> >>Why is that?
> >
> >Because only the local time changes, not the system time.
> >Windows (though I think only old versions) demonstrate that you can have
> >both the same, but it also demonstrates that it is a stupid idea that
> >doesn't work properly even after adding hacks on top of hacks to make it
> >somewhat work.
> 
> Not to big a deal because it is somewhat rare, but the time can fluctuate
> like I said on windows at least with the use of GetSystemTimeAsFileTime
> which is what av_gettime maps to under windows. Don't know for linux.

You are aware that this part was about summer time changes?
GetSystemTimeAsFileTime specifically is _not_ affected by that.

> The resolution of GetSystemTimeAsFileTime is 15ms and work arounds are not that elegant.

As far as I can find out that is only true on XP and similarly old
systems (though maybe not, because if it was there would be no reason
for GetSystemTimePreciseAsFileTime, the documentation of both is quite
useless).
Also Windows was just an example for doing summer time the wrong way.
I don't think the POSIX monotonic clock is available there anyway? If not
it's not affected by the proposed patch, for better or worse.