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

Don Moir donmoir at comcast.net
Wed Apr 2 23:28:23 CEST 2014

----- Original Message ----- 
From: "LANGLOIS Olivier PIS -EXT" <olivier.pis.langlois at transport.alstom.com>
To: "FFmpeg development discussions and patches" <ffmpeg-devel at ffmpeg.org>
Sent: Wednesday, April 02, 2014 3:55 PM
Subject: Re: [FFmpeg-devel] [PATCH] Use monotonic clock formeasuring reltime.

>> > 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.
> It kinda does. Today the time source function is selectable at compile time with the help of defines. On Linux there is not that 
> much choices and the best available choice is picked but if in Windows there is and each have their pros/cons, then it could be 
> nice to be able to choose at runtime either with cmdline switch or from the UI on top of ffmpeg.

Yeah. It is not necessarily an end user setting and up to the code calling into ffmpeg to decide what timing is best for it's 

> That would control the time function implementation dynamically. What I am trying to propose is slightly different however.
> Offer monotonic clock function beside the actual realtime clock function and
> Categorize ffmpeg time usage:
> 1. To measure relative time interval (monotonic should be preferred in this category)
> 2. Need realtime
> 3. Make this configurable whenever it makes sense (Personally, I'm mostly interested in libavdevice input formats ts)
> 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.
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel 

More information about the ffmpeg-devel mailing list