x265: Will I get smaller file size with frame-threads=1?

Question

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?

Answer 1

Not worth it

For significantly more encoding time you can have an insignificant quality improvement and almost no file size difference.

You can always perform a test

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.

Answer 2

I will note one use for frame-threads=1 though -- stability. Running ffmpeg with x265 output on Ubuntu, the first system with more than 4 cores/threads I used (Ryzen with 4C/8T) ffmpeg ran great but if you ran several copies of ffmpeg, or loaded the system down when ffmpeg was running, you'd get a ~1-5% or so failure rate, it'd segfault at some address in x265 mid-encode, rerun the same file and it'd come out fine. I cursed AMD for having some CPU bug and futzed with some Linux kernel setting or other to turn off the hyperthreading. That only slowed down encodes by about 5% anyway. But it wasn't the CPU's fault -- I've had 2 systems since (with Intel CPUs) that bail at the same spot in the code if you run like 3, 4 copies of ffmpeg.

I set it to use frame-threads=1 and all is well. On my Coffee Lake system (6C/12T) it encodes quite quickly still, and it only takes 2 encodes to fully utilize the CPU anyway. My notebook is 2C/4T so ffmpeg has no problem getting to 99-100% CPU usage on there.