<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">чт, 21 дек. 2023 г., 16:39 Andrea paz <<a href="mailto:gamberucci.andrea@gmail.com" rel="noreferrer noreferrer" target="_blank">gamberucci.andrea@gmail.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">>> I didn't understand what the 17122023 patch brings again.<br>
> Without the patch you can not render 10 or 12 bit.<br>
<br>
I meant whether the 0010 patch only served termux or changed the<br>
libraries as well, because I experienced a very high rendering speed<br>
increase (about 10/20 fps more). That's a very big jump (and<br>
welcome!).<br>
<br>
> I am trying to get 3 things all ready to test on other systems -- HDR, libaom 3.8, and x265 -- so when I do, I will check to make sure multibit compile works there too and make it a default.  Even if it takes longer for me.  At one point I thought that if you rendered 8-bit on the multibit x265, it would result in a bigger file than on the build non-multibit system.  But I did a render test today and the files were exactly the same.<br>
<br>
As you said, for me also the size of the files obtained with the<br>
multibit and std versions is identical, as is the quality (to the eye)<br>
of the video. The rendering speed is similar (just faster the std<br>
version, but by a little). I would be for eliminating the std version<br>
and using only the multibit, but on this point I would like to hear<br>
everyone's opinion.<br>
<br>
@Andrew: could you tell me again all the patches to use to test libaom?<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">0001-EXPERIMENTAL-enable-opencl-on-termux-also-libmediaco.patch<br></div><div dir="auto">0009-Update-libaom-to-3.8.0.patch<br></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">and put libaom-v3.8.0 tarball in thirdparty/src </div><div dir="auto">for testing non-compatible with ub16 update</div><div dir="auto"><br></div><div dir="auto">0011-Move-libaom-back-to-3.6.1-for-ubuntu-16-cmake-3.5.patch                                       </div><div dir="auto">0012-Add-libaom-3.6.1-patches.patch<br></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">move avay libaom-v3.8.0 tarball and patches from thirdparty/src, put in libaom-v3.6.1 tarball</div><div dir="auto">For testing Ubuntu16 compatible variant (big cmake change breaking old cmake 3.5.1 build happened in libaom-3.7.0).</div><div dir="auto"><br></div><div dir="auto">Not sure if rendering result (speed, quality) will be different on your machine or not,  by changelog 3.8.0 should be faster.</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>
@Phyllis: the build times depend only on the CPU, why don't you use<br>
the more equipped system (the Epyc)? You would do builds in 1 to 2<br>
minutes, versus 7 to 10 minutes on the laptop. You could virtualize<br>
the various distros by giving them as much CPU and RAM.<br>
</blockquote></div></div></div>