[FFmpeg-devel] [PATCH 1/6 v2] lavu: add av_gettime_relative()

[Reimar Döffinger]

On Tue, May 13, 2014 at 03:31:04PM -0400, Olivier Langlois wrote:
> On Tue, 2014-05-13 at 15:23 -0400, Olivier Langlois wrote:
> > On Tue, 2014-05-13 at 20:58 +0200, Reimar Döffinger wrote:
> > > On Mon, May 12, 2014 at 04:26:37PM -0400, Olivier Langlois wrote:
> > > > It is very easy to experience the issues that this patch attempt to address
> > > > by rewinding back in the past the system time while ffmpeg is running.
> > > > 
> > > > this is breaking the ffmpeg report printing (ffmepg.c:print_report()) and
> > > > the the rate emulator functionality (-re) without the patch.
> > > 
> > > I still think these should be fixed to not be so brittle and handle
> > > strange clock values more gracefully.
> > 
> > These are fixed and rock solid on platforms supporting
> > POSIX_CLOCK_MONOTONIC (Linux, maybe macos) with part 2/6 of this patch:

Definitely not "rock solid".
The monotonic clock necessarily will ignore any time adjustments done
manually by the user, so in such cases it would drift compared to the
actual real time (obviously such adjustments are a bad idea and should
be handled by NTP via gradual adjustments, but still).
There is in fact no requirement at all in the POSIX spec that
POSIX_CLOCK_MONOTONIC is at all in sync with the real time clock,
which could lead to ugly and surprising behaviour.
It is not either specified how POSIX_CLOCK_MONOTONIC should behave over
suspend.
On systems without an RTC there is no way it can continue to count time
during a suspend to disk.
Even on systems with one I think it will not be adjusted for accumulated
clock skew during the time the system was suspended.
Whether we actually _want_ it to increase at all during suspend is a
completely different question.
So sorry, but IMHO this isn't anywhere even close to "rock solid".
I'll give you "good enough for almost anyone".

> > https://ffmpeg.org/pipermail/ffmpeg-devel/2014-May/157346.html
> > 
> > If possible, someone could adapt av_gettime_relative() implementation to
> > make it monotonic on Windows or some other platforms as well.
> > 
> How about making these 2 ffmpeg features more robust even on platforms
> where av_gettime_relative() is not monotonic?
> 
> This could be done by using for the first time the new function
> av_gettime_relative_is_monotonic() and comparing that the second time is
> greater or equal before performing the substraction.

Assuming we are using 64 bit numbers I don't see why you'd need a
av_gettime_relative_is_monotonic.
Worst that can happen is that you mitigate actual bugs in the
monotonic clock implementation.