[FFmpeg-devel] [PATCH] Use monotonic clock formeasuring reltime.

Don Moir donmoir at comcast.net
Wed Apr 2 21:35:00 CEST 2014


----- Original Message ----- 
From: "Don Moir" <donmoir at comcast.net>
To: "FFmpeg development discussions and patches" <ffmpeg-devel at ffmpeg.org>
Sent: Wednesday, April 02, 2014 2:24 PM
Subject: Re: [FFmpeg-devel] [PATCH] Use monotonic clock formeasuring reltime.


>>> > Can change during daylight savings time switch over by an hour as well.
>>>
>>> Wrong.
>
>>It depends. You have the option to store the system time in the RTC (hardware clock) either as UTC or local time in Linux. Setting 
>>RTC time in local time isn't advised but >may be required if dual booting with Windows. When having DST change, you either let the 
>>other OS  correct the RTC time or you can manually fix it.
>
>>I have 0 Windows installation around me so I am not sure but I would not totally rule out that manual DST management can have 
>>effect on system time.
>
>>inspect /etc/adjtime content to find out how your RTC is configured or see
>
>>http://tldp.org/HOWTO/Clock-2.html
>
>>for more info on the topic.
>
> For windows, I went thru the RTC route, timeGetTime, QueryPerformanceCounter, and GetSystemTimeAsFileTime. Each one has some 
> degree of problem.
>
> For my own timing I use QueryPerformanceCounter. Even though it may have had issues in the past, it does not fail and very 
> accurate.
>
> timeGetTime is accurate but needs setup (as does QueryPerformanceCounter) and you also need to watch for wrap and requires link to 
> winmm.dll.
>
> Since timing can vary so much, I suggest again to allow a user settable timer function.

I think a lot of you think in the way of command line apps. I don't. Probably does not make much sense to have a user settable timer 
for command line apps. 



More information about the ffmpeg-devel mailing list