On Tuesday, July 27, 2021, Andrea paz via Cin <cin@lists.cinelerra-gg.org> 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.