<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">вт, 19 дек. 2023 г., 12:17 Andrea paz via Cin <<a href="mailto:cin@lists.cinelerra-gg.org">cin@lists.cinelerra-gg.org</a>>:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I tried compiling with only the x265 new patch and everything works.<br>
Applying the patch gave this result:<br>
<br>
$ patch -p2 < 0010-Update-x265-to-git-snapshot-17122023.patch<br>
patching file blds/termux.bld<br>
Hunk #1 FAILED at 1.<br>
1 out of 1 hunk FAILED -- saving rejects to file blds/termux.bld.rej<br>
patching file <a href="http://configure.ac" rel="noreferrer noreferrer" target="_blank">configure.ac</a><br>
patching file thirdparty/Makefile<br>
<br>
I don't know if it is important.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">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 ...)</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Test renderings, using x265, work fine, except using the 10-bit and<br>
12-bit presets fail indicating that those pixel formats are not<br>
supported by x265 encoder.<br>
Using the multibit appimage (without the new patch), the 12- and<br>
10-bit renderings work, but the vaapi preset does not.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">May be you should try to unpack appimage and remove libva so files from it, so cin binary will pick up system version?</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
My results are:<br>
<br>
55 fps <== Multibit <-- preset: x265-hi --> new patch ==> 71 fps<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">well, its faster, but does it look good? :)</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
45 fps <== Multibit <-- preset x265 10-bit --> new patch ==> NO<br>
<br>
NO <== Multibit <-- preset: hevc_vaapi --> new patch ==> 62 fps<br>
<br>
I wonder if the separation between multibit and non-multibit versions<br>
is still necessary.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">well, I thought multilib build was slower, not at rendering but at build itself ? It up to Phyllis to decide ....</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
-- <br>
Cin mailing list<br>
<a href="mailto:Cin@lists.cinelerra-gg.org" target="_blank" rel="noreferrer">Cin@lists.cinelerra-gg.org</a><br>
<a href="https://lists.cinelerra-gg.org/mailman/listinfo/cin" rel="noreferrer noreferrer" target="_blank">https://lists.cinelerra-gg.org/mailman/listinfo/cin</a><br>
</blockquote></div></div></div>