I tried compiling with only the x265 new patch and everything works.
Applying the patch gave this result:
$ patch -p2 < 0010-Update-x265-to-git-snapshot-17122023.patch
patching file blds/termux.bld
Hunk #1 FAILED at 1.
1 out of 1 hunk FAILED -- saving rejects to file blds/termux.bld.rej
patching file configure.ac
patching file thirdparty/Makefile
I don't know if it is important.
Well, termux.bld configures cingg for termux-specific compilation :) as on my tablet. First patch in series (with EXPERIMENTAL on filename) upgrades this file so I was able to try hw encoder. Sadly, resulting file seeks strange, so I am not sure if it works in general or I must alter my preset or even our glue code ...)
Test renderings, using x265, work fine, except using the 10-bit and
12-bit presets fail indicating that those pixel formats are not
supported by x265 encoder.
Using the multibit appimage (without the new patch), the 12- and
10-bit renderings work, but the vaapi preset does not.
May be you should try to unpack appimage and remove libva so files from it, so cin binary will pick up system version?
My results are:
55 fps <== Multibit <-- preset: x265-hi --> new patch ==> 71 fps
well, its faster, but does it look good? :)
45 fps <== Multibit <-- preset x265 10-bit --> new patch ==> NO
NO <== Multibit <-- preset: hevc_vaapi --> new patch ==> 62 fps
I wonder if the separation between multibit and non-multibit versions
is still necessary.
well, I thought multilib build was slower, not at rendering but at build itself ? It up to Phyllis to decide ....