Am Do., 25. März 2021 um 17:04 Uhr schrieb <julien.gib...@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... _______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
