[FFmpeg-devel] [PATCH] Runtime detection for the number of processors/cores

Roman Shaposhnik rvs
Wed May 21 22:07:48 CEST 2008

On Wed, 2008-05-21 at 11:24 +0100, M?ns Rullg?rd wrote:
> Philipp Meinen wrote:
> > Hello FFmpeg Team
> >
> > The attached patch is an attempt to allow runtime detection for the
> > number of online processors/cores instead of having to specify the
> > number of threads. The idea is to type:
> >     ffmpeg -threads 0 ....
> > to use as many threads as processors/cores are online.
> >
> > I guess cmdutils.c/h is not the right file to place the new
> > detection function. To which file should this function belong?
> >
> > Comments welcome :)
> This is the wrong way to go about it.  The number of processors in the
> machine is not interesting, the number of processors we're running on
> is.  On Linux, this information can be found from sched_get_affinity().
> Other systems have other methods.

This is a reasonable generic statement, but the nice thing about
FFmpeg's approach to multithreading is that it sort of self-schedules.
IOW, even if you create more (far more!) threads than you have actual
execution units (could be CPUs, could be cores or could even be
virtual threads -- think Hype-R-Threading) the only overhead is
at the start-up phase. Thus, using _sysconf(_SC_NPROCESSORS_ONLN)
seems quite reasonable of a compromise.

On a related note: I still don't quite understand why MPEG based
codecs don't allow for higher degree of parallelism. Unlike DV codec
which I've just tested on a nice Maramba box (2 CPUs, 16 cores, 
128 execution units) and it scaled pretty much linearly to the
# of cores, the MPEG based ones just refused to go higher than 4.


More information about the ffmpeg-devel mailing list