Test of x265 Stable v2.4

In the past two weeks, I did some test around x265 v2.4, I also wrote some post about some of results. (about “–limit-tu” and “–limit-sao”)

Yesterday I fond the rip, encoding with x265 v2.4, reached 130% the size of rip with v2.3. I was considered of difference parameter, so I compared the mediainfo of the two rip, then I fond the new parameter “–no-ssim-rd”. But finally I find it has nothing to do with the increment of file size.

I read the Release Note again and noticed: ”Lambda tables for 8, 10, and 12-bit encoding revised, resulting in significant enhancement to subjective visual quality.” According to experience, changes around psy-optimize will cause unpredictable file size. I find this commit in the repo of x265:

-// lambda2 = pow(lambda, 2) * scale (0.85);
+// lambda2 = 0.038 * EXP(0.234 * QP) * 256;
 double x265_lambda2_tab[QP_MAX_MAX + 1] =
 {
- 13.6000, 17.1349, 21.5887, 27.2000, 34.2699,
- 43.1773, 54.4000, 68.5397, 86.3546, 108.8000,
- 137.0794, 172.7092, 217.6000, 274.1588, 345.4185,
- 435.2000, 548.3176, 690.8369, 870.4000, 1096.6353,
- 1381.6739, 1740.8000, 2193.2706, 2763.3478, 3481.6000,
- 4386.5411, 5526.6955, 6963.2000, 8773.0822, 11053.3910,
- 13926.4000, 17546.1645, 22106.7819, 27852.8000, 35092.3291,
- 44213.5641, 55705.6000, 70184.6579, 88427.1282, 111411.2000,
- 140369.3159, 176854.2563, 222822.4000, 280738.6324, 353708.5127,
- 445644.8001, 561477.2648, 707417.0237, 891289.6000, 1122954.5277,
- 1414834.0484, 1782579.2003, 2245909.0566, 2829668.0981, 3565158.4000,
- 4491818.1146, 5659336.1938, 7130316.8013, 8983636.2264, 11318672.3923,
- 14260633.6000, 17967272.4585, 22637344.7751, 28521267.1953, 35934544.9165,
- 45274689.5567, 57042534.4000, 71869089.8338, 90549379.1181, 114085068.8008
+ 9.7280, 12.2880, 15.5136, 19.6096, 24.7808, 
+ 31.3344, 39.6032, 50.0480, 63.2320, 79.8976, 
+ 100.9664, 127.5904, 161.2544, 203.7504, 257.4848, 
+ 325.3760, 411.1616, 519.5520, 656.5376, 829.6448, 
+ 1048.3712, 1324.7744, 1674.0608, 2115.4048, 2673.1264, 
+ 3377.8944, 4268.4416, 5393.7920, 6815.8464, 8612.8128, 
+ 10883.5328, 13752.9344, 17378.8160, 21960.6528, 27750.4768, 
+ 35066.7264, 44311.8848, 55994.4704, 70757.0944, 89411.8144, 
+ 112984.7552, 142772.5824, 180413.7728, 227978.8800, 288084.2496, 
+ 364036.0960, 460012.2112, 581291.8784, 734546.3040, 928205.3888, 
+ 1172921.6256, 1482155.9552, 1872918.2208, 2366702.7968, 2990670.9504, 
+ 3779144.8832, 4775495.6288, 6034528.7424, 7625499.0080, 9635919.8464, 
+ 12176377.0368, 15386611.7888, 19443207.2448, 24569301.7344, 31046862.8224, 
+ 39232197.1968, 49575549.9264, 62645870.6176, 79162109.3632, 100032763.4688
 };
 
 #elif X265_DEPTH == 10

We can easy to notice the big change of vaults, I decided to replace the lambda table in v2.4 source code to find out if it was the reason of increment. I used the old table in v2.3 to compile executable file. After several attempt compiling source code, I finally get the exe with msvc asm optimize.

the result of testing(5000 frames sample clip)

From the result, we can see the real reason of the change.

This version of encoder is more sensitive to high-frequency information, In other words, it will keep more noise and also textures. So this change improves the effect of visual.