And even then they don’t know how to correctly interpret performance data they’re seeing. Also, they don’t really know how to analyze running processes and monitor system performance, and just run top. Why so many people are reporting such different results? Probably because they’re using different versions of ffmpeg on vastly different hardware. The conclusion here is obvious: ffmpeg does a decent job identifying the available CPU resources and distributing the load correspondingly. And setting -threads to 1.5, as so many suggest, does nothing but increases execution time. Once again, I ran this process a couple of dozen times and the average processing time was 5m22.466s. This here is as if you were running the commands sequentially by hand, minus any delays due to you. The first run is just a basic loop, running one ffmpeg instance at a time with -threads option set to 0. Thus, the first file will contain frames for 0-15s, the second file – 15-30s, and so on. The task was to split this video into multiple files of 15-second duration each. The ffmpeg version is 4.1.3-static.įor the first test, I picked an h264-encoded GoPro video just under 300MB in size and play time of about 2m 42s. The laptop is running Windows 10 Pro with Ubuntu 18.04 LTS installed via Microsoft store. The few tests below were ran on my Dell XPS 15 (9570) with an 8th-gen Intel Core i7-8750H processor having 6 cores and 12 threads. While the -threads argument rages on, I decided to do some basic testing The most common choice for this option is the default 0 that means letting ffmpeg figure out what to do. I’ve seen suggestions to set the -threads option to 1.5 the number of cores, which doesn’t make any sense.
While ffmpeg has multithreading capability, getting the best performance on multi-core systems calls for something more than just playing with the -threads option.
0 kommentar(er)
