<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small">Andrea has convinced me that the x265 addition of 10 and 12 bit should be the default (i.e. the compile_multibit_X265.patch automatically in effect).  I have now run tests on an older operating system, ubuntu 16, and an older 32-bit 9.1debian system, with no problems.  The compile time may be longer and the cin binary is definitely larger, but the X265 8-bit is still an option so there is no loss.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">I concur that einhander binary is not the multibit version as verified by Terje (tested on Fedora 39).<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jul 12, 2024 at 2:39 AM Andrea paz <<a href="mailto:gamberucci.andrea@gmail.com">gamberucci.andrea@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I, too, wonder whether einhander binaries are 8-bit or multibit. The<br>
underlying theme is that, normally, video editing involves powerful<br>
hardware and, I think, the majority have it. However, it is also true<br>
that CinGG is suitable for non-powerful hardware and it could be that<br>
the majority of its users have dated hardware. A survey of the PCs<br>
that CinGG users have would be interesting.<br></blockquote><div><span class="gmail_default" style="font-size:small">We do not have much feedback when doing surveys.</span> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
One possible idea (not important, surely it is better to leave<br>
everything as it is now) could be to change the current default<br>
(8-bit) to multibit, for example:<br></blockquote><div style="font-size:small" class="gmail_default">So based on Andrea's work and explanation, I will add the 3 patches to GIT so they will be in the source code going forward and get built.  It should not be a problem, but if a problem arises, we can handle it accordingly.  This means that there will no longer be CinGG-20yymmdd-x86_64-multibit.AppImage from now on.  I hope that does not confuse anyone who is used to downloading that version, but it will be noted in the Release Notes and the next News on the website. Not sure if we should remove "multibit" from CinGG-20240630-x86_64-older-distros-multibit.AppImage. Any opinion on that?  I would be easier for me to type.</div><div style="font-size:small" class="gmail_default"><br></div><div style="font-size:small" class="gmail_default">And if anyone, for example "me", wants to compile faster they can just delete x265xxx.patch1, x265xxx.patch2, and x265xxx.patch3 in the thirdparty/src directory.  (It takes 13 minutes to do a full build without the patches and 21 minutes with them on my laptop.)<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Note: the 8-bit limitation only affects encoding with 10-bit x265. I<br>
have the following error:<br></blockquote><div><span class="gmail_default" style="font-size:small">Besides x265 10-bit, 12-bit x265 encoding also errors out on the current default version.</span> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
[libx265 @ 0x71dcbc0afac0] Specified pixel format yuv422p10le is not<br>
supported by the libx265 encoder.<br><span class="gmail_default" style="font-size:small">...</span><br>
</blockquote></div></div>