[FFmpeg-user] theoretical concurrency limitations

[Carl Eugen Hoyos]

2016-09-16 13:46 GMT+02:00 Anatol <anatol2002 at gmail.com>:
> There are ffmpeg instances/process and there are threads, although u did
> not ask about them.
> ffmpeg/x264 tends to use all existing CPU cores (Linux) to run a thread for
> every ffmpeg instance/process.
> This means that if u have 24 or 32 cores ffmpeg will run 24/32 concurrent
> x264 encoding threads.
> And this is HIGHLY un-recommended due to severe quality reduction.
> Use at most 4-5 threads (via '-threads' operand) for every ffmpeg process.
>
> According to my tests u can quite safely run number of ffmpeg processes
> that is up to twice the number of CPU cores - 48 ffmpegs for server with 24
> CPU
> For higher factor (>2) the overhead becomes more significant.
> At factor 4 and higher, the run-time is doubled and some of the processes
> crashed.
> It is possible that this kind of misbehavior was caused by disk NFS
> problems, I did not go that far to investigate those issues.
>
> There was no difference between 1 threaded and 4 threaded processes.
>
> Tested with ffmpeg 2.3.1/2.7.2.

This is old and not relevant on this mailing list.

I don't think that higher thread count implies lower quality,
at least this is not known as being an important factor.
In any case, it cannot be relevant for decoding, and is
not relevant for all encoders.

What is relevant is that most multithreaded decoders
have a gigantic overhead (and encoders may too),
so if possible, you should use one thread for decoding
and one for encoding and start as many ffmpeg processes
as possible.

Please do not top-post here, it is considered rude.

Carl Eugen