[Cin] How to identify if a running CinGG is the Regular or Multibit version?

[Phyllis Smith]

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.

I concur that einhander binary is not the multibit version as verified by
Terje (tested on Fedora 39).

On Fri, Jul 12, 2024 at 2:39 AM Andrea paz <gamberucci.andrea at gmail.com>
wrote:

> I, too, wonder whether einhander binaries are 8-bit or multibit. The
> underlying theme is that, normally, video editing involves powerful
> hardware and, I think, the majority have it. However, it is also true
> that CinGG is suitable for non-powerful hardware and it could be that
> the majority of its users have dated hardware. A survey of the PCs
> that CinGG users have would be interesting.
>
We do not have much feedback when doing surveys.

>
> One possible idea (not important, surely it is better to leave
> everything as it is now) could be to change the current default
> (8-bit) to multibit, for example:
>
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.

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.)

>
> Note: the 8-bit limitation only affects encoding with 10-bit x265. I
> have the following error:
>
Besides x265 10-bit, 12-bit x265 encoding also errors out on the current
default version.

>
> [libx265 @ 0x71dcbc0afac0] Specified pixel format yuv422p10le is not
> supported by the libx265 encoder.
> ...
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cinelerra-gg.org/pipermail/cin/attachments/20240715/df4e42b0/attachment.htm>