[FFmpeg-devel] [PATCH] Use monotonic clock for measuring reltime.

[Don Moir]

----- Original Message ----- 
From: "Reimar Döffinger" <Reimar.Doeffinger at gmx.de>
To: "FFmpeg development discussions and patches" <ffmpeg-devel at ffmpeg.org>
Sent: Tuesday, April 01, 2014 2:16 AM
Subject: Re: [FFmpeg-devel] [PATCH] Use monotonic clock for measuring reltime.


> On 01.04.2014, at 00:19, LANGLOIS Olivier PIS -EXT <olivier.pis.langlois at transport.alstom.com> wrote:
>>> On a properly configured system, the wall time clock should not go back:
>>> AFAIK, we do not know how to transport anything through a wormhole. But
>>> yes, of course in practice it happens.
>>
>> I work on IVI systems that lack a CMOS battery that boot up several years in the past every morning that will have their time 
>> jumps to present when the NTP updates start to be received.  On such systems we have seen video playback freeze because of the 
>> multi year gaps between 2 frames. Flipping gettimeofday() to clock_gettime() did fix this issue.
>
> Uh, time jumping forward is monotonic, and there is no reason for FFmpeg to hang on jumps in that direction.
> This sounds like some calculations are done the wrong way.
> Not to mention that switching to a monotonic clock does not actually _guarantee_ this won't happen, since as said jumps forward 
> are monotonic and as such possible even with it.
> Thus I'd claim for this specific issue I'd say your patch hides the bug instead of fixing it.

The wall time can change by a second or seconds forward or backward depending on automated clock updates and user setting. Can 
change during daylight savings time switch over by an hour as well.

The wall time is just a poor way to govern time for media playback.