According to the x265 Command Line Options Documentation about the -F
/ --frame-threads
option:
Using a single frame thread gives a slight improvement in compression, since the entire reference frames are always available for motion compensation, but it has severe performance implications.
Will this affect file size significantly?
For significantly more encoding time you can have an insignificant quality improvement and almost no file size difference.
Encode with x265. Command #1 is using default --frame-threads
. The value is auto-determined by core count. With my geriatric hardware it is using --frame-threads 3
.
time x265 input.y4m -o default.hevc
real 0m58.430s
user 6m34.437s
sys 0m2.409s
time x265 --frame-threads 1 input.y4m -o frame-threads1.hevc
real 1m29.684s
user 5m38.404s
sys 0m2.992s
Size is basically the same:
24858360 (24M) default.hevc
24859280 (24M) frame-threads1.hevc
Using --frame-threads 1
is significantly slower. In my case 3x slower, but my CPU is ancient so it may be a much bigger difference for you.
Compare visually and via VMAF, PSNR, SSIM, or whatever prefer to determine quality.
ffmpeg -v error -i input.y4m -i default.hevc -lavfi "[0:v]settb=AVTB,setpts=PTS-STARTPTS[main];[1:v]settb=AVTB,setpts=PTS-STARTPTS[ref];[main][ref]libvmaf" -f null -
VMAF score: 82.979207
ffmpeg -v error -i input.y4m -i frame-threads1.hevc -lavfi "[0:v]settb=AVTB,setpts=PTS-STARTPTS[main];[1:v]settb=AVTB,setpts=PTS-STARTPTS[ref];[main][ref]libvmaf" -f null -
VMAF score: 82.986954
A higher VMAF score is better, but it's only a difference of 0.007747 and I can't tell by looking at it.