Test of x265 Stable v2.4

Test of x265 Stable v2.4

IT, VCB-Studio

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)

x265 2.3+1-7e225aefd389 x265 2.4+9-dccf02340c75 x265 2.4 Special ver
Size(KB) 137128 180286 137094
rate 100.00% 131.47% 99.98%

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.

Amefs, EFS, IT, x265
Previous Post
Test about limit-sao(x265)
Next Post
About ripping Amaama to Inazuma/Gabriel Dropout

Leave a Reply

Your email address will not be published. Required fields are marked *

Fill out this field
Fill out this field
Please enter a valid email address.

This site uses Akismet to reduce spam. Learn how your comment data is processed.

keyboard_arrow_up
Exit mobile version