On Fri, Oct 11, 2019, 08:58 Anand Veerappan <[email protected]> wrote:
> Hi > > While encoding a video file using FFmpeg we have option to handle thread > parameter. I used Quad Core Processor and find below my observations. > > *Case 1: Default thread usage* > By default if we didn't specify thread value FFmpeg internally adjusts > thread count usage based on the core architecture of the deployment > machine. > > Example: > > ffmpeg -i football_1080p.mp4 -c:v libx264 -b:v 3M -bufsize 6M -maxrate > 4.5M -g 120 -tune psnr -report football_1080p_3M_threads_1_p.mp4 > > If I repeat this command n times for encoding always the encoded file size > is similar in all iterations. > > *Case 2: Manually forced thread count usage* > > > * Example 1: Thread count 1* > > ffmpeg -i football_1080p.mp4 -c:v libx264 -b:v 3M -bufsize 6M -maxrate 4.5M > -*threads 1* -g 120 -tune psnr -report football_1080p_3M_threads_1_p.mp4 > > > *Example 2: Thread count 6* > > ffmpeg -i football_1080p.mp4 -c:v libx264 -b:v 3M -bufsize 6M -maxrate 4.5M > -*threads 6* -g 120 -tune psnr -report football_1080p_3M_threads_1_p.mp4 > > *Example 3: Thread count 9* > > ffmpeg -i football_1080p.mp4 -c:v libx264 -b:v 3M -bufsize 6M -maxrate 4.5M > -*threads 9* -g 120 -tune psnr -report football_1080p_3M_threads_1_p.mp4 > > *Example 4: Thread count 20* > > ffmpeg -i football_1080p.mp4 -c:v libx264 -b:v 3M -bufsize 6M -maxrate 4.5M > -*threads 20* -g 120 -tune psnr -report football_1080p_3M_threads_1_p.mp4 > > If I repeat this command 4 times for encoding the encoded file size differs > with few KB in all iterations. Why is this difference ? > > That implies that if I put the thread count at 0 on two different machine > architectures, I will again get two different output file sizes for the > same thread count (0, in this case) and same input file. > > Also I am curious to know the below mentioned quires > > 1. What does the threads command do? > 2. What does FFmpeg do if you don’t specify a threads value? > 3. How does the threads settings impact performance? > 4. How does the threads setting impact quality? > > Please clarify. > > Regards > Anand V > To answer your questions: 1. The threads argument simply controls the number if threads the underlying encoders, decoders and filters can use *if* threading is supported. 2. If no thread value is specified, then FFmpeg will allocate , on a per stream specific basis (video and audio encoders) and filters (if they are capable of threading) a thread group equal to the number of logical processors present on the host. 3. When the underlying filter chains, encoders and decoders are capable of threading (and not all of them are), expect a reasonable performance gain with diminishing returns on higher thread counts. This is the case with slice based threading as there are only so many partitions of an encode or decode process that can be spawned, regardless of the thread count. Secondly, in many cases involving hardware accelerated encoders and decoders , very high thread counts will definitely cause issues. This is the case with the likes of nvdec where 16+ threads will trigger a warning from the decoder. 4. With quality: If the underlying encoder relies on a VBV (video buffer verifier) being constant and predictable, a very high thread count may cause it to undershoot or overflow, resulting in target bitrates not being hit. It's something you'd need to test on a per encoder basis, but it's been observed with the likes of libx264, among other wrappers. For this reason , it's best to manually limit the thread count to a reasonable number (not greater than 8 in most cases) especially if you're running multiple FFmpeg sessions on the same host. You can confirm threading capability in a filter or encoder by running: ffmpeg -h encoder=encoder name Or ffmpeg -h filter=filter name , Etc, and the same will be listed under the capability field. Good luck! > _______________________________________________ ffmpeg-user mailing list [email protected] https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email [email protected] with subject "unsubscribe".
