[FFmpeg-user] ffmpeg bottleneck, thread-safe ?

[Carl Eugen Hoyos]

Am Do., 25. März 2021 um 17:04 Uhr schrieb <julien.gibory at orange.com>:

> 76 vCPUs (Skylake Gold 6161 v5 bi-pro 2.2Ghz) | 304 GB | cc3.19xlarge.4 | OBS CentOS 7.7

> o   /home/local/ffmpeg_build/bin/ffmpeg -i /data/testjulien/iss_ep01telco_DT_video360_h265_7680x7680_10b_250Mbps_stereo_v001.mp4 -maxrate 25M -bufsize 200M  -b:v 25000k -c:v libx265 -pix_fmt yuvj420p -c:a copy  -f hls -hls_time 4 -hls_flags independent_segments -hls_list_size 5 -strftime 1 -hls_segment_filename /data/www/httpsvmmalo/test_capa/file_%m-%d_%H-%M-%S.m4s /data/www/httpsvmmalo/test_capa/stream.m3u8

When asking questions on this mailing list, you are expected to
provide the command
line you tested together with the complete, uncut console output,
attachments are
rarely useful-

> o   ffmpeg version 4.3.2

Please test current FFmpeg git head.

In general, video decoding can be parallelized (although restrictions
exist), encoding
parallelization has limitations, it is therefore likely that you found
a bottleneck of x265.
But to be able to clearly decide if this is true, you can first test
decoding speed (only),
then test encoding from testsrc2 (which should be faster than decoding
an 8k video),
and don't use hls muxing to rule out any bottleneck there.

> Ce message et ses pieces jointes peuvent contenir des informations confidentielles

Please remove this nonsense from emails sent to a public mailing list.

I wonder what "thread-safe" means in your subject...

Carl Eugen

PS:
Before you ask the x265 developers why they are not maxing out your CPUs:
There was a patch once that allowed the x265 encoder to use more cpu cycles
but since it reduced encoding speed it was decided not to merge it...