[FFmpeg-devel] a new benchmarking option for ffmpeg - patch 1 of 1

"René J.V. Bertin" rjvbertin at gmail.com
Fri Mar 8 14:01:55 CET 2013


On Mar 07, 2013, at 10:15, René J.V. Bertin wrote:

Just had a look at the macros in libavutil/*/timer.h . At least for x86 and ppc, these use the TSC register (and PPC equivalent).
While this is the cheapest and highest resolution timer available, it is not reliable without some additional logic - at least that's what I gathered from reading up on the subject. This register contains a ticker that's linked to the CPU frequency ... which thus has to be taken into account (didn't see that being done) but more importantly, that frequency is typically not constant on modern CPUs.

Thus, the STOP_TIMER macro is perfectly write to log information about the number of cycles used.

On Mac OS X, the mach_absolute_time() function does read the TSC register (or its PPC equivalent), but when diving into the kernel code one can see that an effort is made to ensure that result return does indeed reflect time, and not simply a CPU frequency ticker. From what I understand, the MS PerformanceCounter does the same thing, as do the Linux clock_gettime functions.

I agree that it is a bad idea to duplicate functionality if it can be avoided. I'd probably have modified ppc/timer.h and x86/timer.h if I had discovered their presence (I frankly didn't expect the presence of HR timers which don't seem relevant for video encoding/decoding ... though indeed more so for playback).

What do you suggest? Should I move my various init_hr_time and get_hr_time functions to the ppc/timer.h and x86/timer.h ?

R


PS: what's the BFIN architecture?


More information about the ffmpeg-devel mailing list