Possible speed drop in x264 v161

[dev-null]

Is it normal that the current version runs way slower than older versions?

Today I build the latest 161 version (via the tar archive) here on an old Mac OS X box. I built it exactly the same way as the 159 version I was using. Same build command, same compiler, same libs, except ffms slightly newer. Both executables create the very same exact output from the same test file, but 161 performs consistently slower than 159 (~13s/14fps vs. ~9.7s/19fps for 181 frames). I used an .y4m input file to void out ffms and multiple runs to average disk access times.

Just wondering, if that's really normal?

[LoRd_MuldeR]

Is it normal that the current version runs way slower than older versions?

I don't think so. In a quick test, I cannot see much speed difference on my system between x264 r3027 (API v161) and r2991 (API v159):

x264_x64.exe --version
x264 0.161.3027 4121277
(libswscale 5.8.100)
(libavformat 58.64.100)
(ffmpegsource 2.40.0.0)
(lsmash 2.16.1)
built on Nov 16 2020, gcc: 10.2.0

x264_x64.exe --crf 20 --preset slower --tune film --output test.h264 E:\Samples\foreman_4K.y4m
y4m [info]: 3840x2160p 1:1 @ 24000/1001 fps (cfr)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2
x264 [info]: profile High, level 6.0, 4:2:0, 8-bit
[...]
encoded 248 frames, 1.74 fps, 45835.42 kb/s__old__\x264_x64.exe --version
x264 0.159.2991 1771b55
(libswscale 5.6.100)
(libavformat 58.35.101)
(ffmpegsource 2.31.0.0)
built on Jan 2 2020, gcc: 9.2.0

__old__\x264_x64.exe --crf 20 --preset slower --tune film --output test.h264 E:\Samples\foreman_4K.y4m
y4m [info]: 3840x2160p 1:1 @ 24000/1001 fps (cfr)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2
x264 [info]: profile High, level 6.0, 4:2:0, 8-bit
[...]
encoded 248 frames, 1.75 fps, 45836.30 kb/s

[dev-null]

I don't think so. In a quick test, I cannot see much speed difference on my system between x264 r3027 (API v161) and r2991 (API v159):


With the slower/ higher quality presets (I used the default before for my tests) the difference in performance becomes way smaller, so there's only a slight hit in performance then. The newer version is still slower though. I wonder what makes the difference… need to check some in-between versions/builds for that.

But I guess I'll stick with the old version for now. My encodes usually take a day already. :)

Thanks for the feedback.

[benwaggoner]

With the slower/ higher quality presets (I used the default before for my tests) the difference in performance becomes way smaller, so there's only a slight hit in performance then. The newer version is still slower though. I wonder what makes the difference… need to check some in-between versions/builds for that.
I'd look at something in how the sources are being read if the problems are much less in slower presets. That suggests something that's adding a fixed slowdown per source frame. Maybe check if you're saturating all cores with both builds?

My encodes usually take a day already. :)
What are you encoding and how old a box? I don't think I've had anything that took a day to encode in x264...ever? Even a full 3-pass 1080p placebo of a feature film was less than 24 hours on my circa 2008 encoding system.

[LoRd_MuldeR]

With the slower/ higher quality presets (I used the default before for my tests) the difference in performance becomes way smaller, so there's only a slight hit in performance then.

Still cannot confirm. I tried again, but this time with a "fast" preset:

x264_x64.exe --preset fast --output NUL E:\Samples\foreman_4K.y4m

Median results of 5 runs:

x264 0.159.2991 1771b55
27.37 secx264 0.161.3027 4121277
27.00 sec

I'd say the differences are negligible (within the measurement error).