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

[LANGLOIS Olivier PIS -EXT]

> -----Original Message-----
> From: ffmpeg-devel-bounces at ffmpeg.org [mailto:ffmpeg-devel-
> bounces at ffmpeg.org] On Behalf Of Nicolas George
> Sent: Monday, March 31, 2014 3:32 AM
> To: FFmpeg development discussions and patches
> Cc: Olivier Langlois
> Subject: Re: [FFmpeg-devel] [PATCH] Use monotonic clock for measuring rel
> time.
>
> Le primidi 11 germinal, an CCXXII, Olivier Langlois a écrit :
> > Whenever time is requested to measure relative time, the monotonic
> > clock, when available, is superior to the system realtime clock because:
>
> Hi. Thanks for the patch. There is merit to your proposal, but I see several
> problems that need discussing before going that way.

Ok. That was expected as I realized that what I propose is a simple change that can have a deep impact. I guess that submitting a patch is a good way start a discussion.
>
> > It is not affected by discontinuous jumps in the system time
> >
> > Concretely that means that successive timestamps will never go
> > backward and time difference between 2 events will never be negative
> > because of clock setting between the 2 events.
>
> 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.

Some background about what motivated me to write that patch is that I have been playing with ticket 692 issue ( https://trac.ffmpeg.org/ticket/692) with another user on the ffmpeg-users ml.

Instead of converting v4l2 device monotonic ts inside libavdevice, I have noticed that my v4l2 cam driver (uvcvideo) had an option to configure the driver to use realtime ts instead of monotonic ones. realtime ts option was broken and I have offered a patch.

Maintainer reaction has been to wonder why it was needed and you can follow the discussion over there but my feeling is that he will prefer to ditch the realtime clock support than accept my patch.

https://lkml.org/lkml/2014/3/28/12

This and the fact that many Linux multimedia subsystems are using monotonic clock including ALSA lead me to think that issues in multimedia applications and realtime clock are not that exceptional.
>
> > Hence, this is an improvement to ffmpeg by using a more stable time
> source.
>
> You can say it is an improvement only if you discussed the drawbacks. The
> monotonic clock is not stable across reboots or between different systems.
> For that reason, people may rightfully prefer the wall time clock for some
> usages that may include synchronizing network streams and keeping
> recorded samples related to real time.

I saw that you could seek in a live stream when using ffserver by using a wall clock time value but that is the only place that I saw abs ts. Every output files that I create have a start ts close to 0. I guess this comment generally apply more to networked outputs (rtp,rtsp, etc?)

Are people desiring to use wall clock ts for network streams do so with the switch '-use_wallclock_as_timestamps'? If it is the case maybe just removing:

a10c397..37286f1 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -811,7 +811,7 @@ int ff_read_packet(AVFormatContext *s, AVPacket *pkt)

         /* TODO: audio: time filter; video: frame reordering (pts != dts) */
         if (s->use_wallclock_as_timestamps)
-            pkt->dts = pkt->pts = av_rescale_q(av_gettime(), AV_TIME_BASE_Q, st->time_base);
+            pkt->dts = pkt->pts = av_rescale_q(av_gettime_monotonic(),
+ AV_TIME_BASE_Q, st->time_base);

         if (!pktl && st->request_probe <= 0)
             return ret;

would be sufficient to address your concern.

>
> For that reason, I believe that it should be made an option, at least whenever
> it makes sense.

That sounds like a very reasonable request that I am willing to address in the patch. Please just help me to understand how to define 'whenever it makes sense'. I guess that we are talking more about output timestamps.

Here are few things that pop out of my mind that should be validated:

-copyts,
- ts type configurability for demuxers in libavdevice

anything else?

Greetings,
Olivier

Please ignore the confidentiality notice below.
It is automatically added without my consent.


________________________________
CONFIDENTIALITY : This e-mail and any attachments are confidential and may be privileged. If you are not a named recipient, please notify the sender immediately and do not disclose the contents to another person, use it for any purpose or store or copy the information in any medium.