[FFmpeg-devel] [PATCH] Use monotonic clock for measuring rel time.
olivier at trillion01.com
Wed Apr 2 05:59:49 CEST 2014
On Tue, 2014-04-01 at 08:16 +0200, Reimar Döffinger wrote:
> 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.
You are correct when saying time jumping forward is monotonic but posix
monotonic clock also _guarantee_ that there will be no discontinuous
jumps as well. If you want to convince yourself about that that, I'm
showing the source file to look at:
Secondly, the example that I have given, I did not say that it was
happening in ffmpeg. The purpose of the example was to say that issues
with realtime clock jumping was not just theoritical. They happen. I
have experienced them. While stream RTP with ffmpeg containing realtime
clock ts while, try changing years back and forth. Maybe ffplay will not
have problem with that but I do not think that you will have a hard time
to find a player that do not like that.
More information about the ffmpeg-devel