[FFmpeg-devel] flag naming conventions?

"René J.V. Bertin" rjvbertin at gmail.com
Sat Mar 9 14:14:03 CET 2013

On Mar 09, 2013, at 13:22, Carl Eugen Hoyos wrote:

> René J.V. Bertin <rjvbertin <at> gmail.com> writes:
> If START_TIMER / STOP_TIMER are not sufficient for 
> your needs (are they really?), why don't you extend 
> them?

Those macros use/return cpu cycles, based on the TSC register, PPC equivalent or something I haven't looked at for ARM or BFIN (whatever that is). I want to have time in SI units, i.e. seconds.
As reasoned in my message yesterday, it is not a very good idea to use the TSC for reliable time measurement. It ticks with the CPU frequency which is highly variable on modern CPUs. Also, on systems with multiple TSCs (multi CPU or even mono-cpu, multi core systems), there is no way of knowing which of the ones you're reading at a given time (or at least that used to be the case).
Now you can argue that all that might not be relevant for the use in ffmpeg and that START_TIMER/STOP_TIMER give good enough compromises, but I don't like that kind of approach. For all I know, somebody someday will reuse the code for a case where the compromise is NOT good enough, so just as well do things right the first time. Also see the explanation below on the normalising factor.

Also, I don't know what the existing macros are used for, so I'm hesitant to touch them. And finally ... I'd introduce a platform dependency, as I have no information on how to achieve what I want on ARM of BFIN, meaning the existing macros would have different behaviour on those platforms.

NB: my own first attempts to get access to a highres timer were based on what fftw does, and maybe yours are too. That library is concerned only in finding the least expensive way to calculate an fft, so cpu cycles should be appropriate (though the multi-core issue should still apply, and of course it might lead to unexpected pitfalls).

> I may misunderstand but I think you should not add 
> global variables to a library.

Indeed, which is exactly why I'm using the approach I described. OS X and MS Windows require a normalising factor to convert the value(s) returned by mach_absolute_time or QueryPerformanceCounter to seconds. One has to initialise that value once and it'd be overkill to do that each time one reads the timer. Which is why I propose to use a static variable, à la ff_log2_tab as discussed recently. It'd also be overkill to define that variable statically in each of the numerous files that includes timer.h, and undesirable to define a single instance in (say) libavutil.
So I propose an activation switch that includes my code only upon demand in files where it is required.

> I suggest you send what you have so far ("RFC"), the 
> name of possible defines can still be discussed.

How, the usual way as a patch?


More information about the ffmpeg-devel mailing list