вт, 19 дек. 2023 г., 12:17 Andrea paz via Cin <[email protected]>:
> 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 .... -- > Cin mailing list > [email protected] > https://lists.cinelerra-gg.org/mailman/listinfo/cin >
-- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
