On Fri, Oct 11, 2019, 08:58 Anand Veerappan 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
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".
