On Tuesday, July 27, 2021, Andrea paz via Cin <[email protected]> wrote:
I did some tests with the new and old x265. I report some data, while the terminal output is attached in test-x265.txt.
I used a 5 min video in h264 4.2.0 but good quality. Size= 471 MB.
x265-10bit: CPU 50-80% (multithread) 27.5 fps file size 46 MB
x265-12bit: CPU 50-80% (multi) 25.5 fps file size 45 MB
x265-Hi: CPU 80-90% (multi) 10.6 fps file size 1.7 GB
wow, this one is big!
x265-Lo(w): CPU 40-70% (single/multi) 34 fps file size 67.5 MB
HEVC-vaapi CPU 0-50% (single) 85.8 fps file size 117 MB (I could not see the GPU engagement)
Only in x265-lo do I perceive a small decay in quality compared to the original. All others are comparable.
For me a great news (thanks Andrew!) is the exploitation of multithread; on the terminal you can read the sentence: "Thread pool created using 16 threads" I have a CPU 8c/16t.
it also seems to use assembler as planned) but a bit of concern difference between reported number of encoded frames by x265 itself and Cinelerra: encoded 7470 frames in 272.39s (27.42 fps), 1167.83 kb/s, Avg QP:32.61 Render::render_single: Session finished. ** rendered 7500 frames in 272.418 secs, 27.531 fps does this mean you lost 30 frames somewhere? was this bug/difference present in unpatched Cin?
The only thing I regret is that the new x265 drivers introduce a CinGG build delay of 15 min. Before my entire compile was 5 min, now it's 20 min.