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

[Reimar Döffinger]

On 02.04.2014, at 05:59, Olivier Langlois <olivier at trillion01.com> wrote:
> 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:

Sorry, that code is not at all obvious. While highly theoretical I expect that putting a system into suspend mode, waiting 20 years and then switching it on will also make the monotonic clock jump forward.
If not, just suspending the FFmpeg process will.

> Secondly, the example that I have given, I did not say that it was
> happening in FFmpeg.

It kind of is important for people reviewing to know when you give examples that might not actually exist, otherwise it's a bit hard to make sense of the code.

> The purpose of the example was to say that issues
> with realtime clock jumping was not just theoritical. They happen. I
> have experienced them.

Clock jumping certainly happens. The problem is that both whether they cause issues and whether using the monotonic clock fixes them (which btw. either way will still leave your code broken on systems without it) is a different question.
So the details are kind of important to judge the risk/benefit of your proposal.

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

It certainly would help if you in that case can find one such player, a testcase is always a big help.
Also there are in principle other ways that can be considered for fixing it, basically applying the timestamp discontinuity filter also during encode as one example.
Not saying they are necessarily better, just that I don't see a monotonic clock as an obvious solution at least for multimedia.