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

[Phyllis Smith]

Andrea, sorry for the confusion.  See below.

2- Maybe I didn't understand correctly.  Do you intend to rename all
> the 2023/24 appimages, removing the word multibit, and deleting the
> 8-bit ones? Will only the "older-distros" be left untouched? And the
> "i386" versions are all 8-bit? I will change the dates from 20230131
> to 20240630 in the manual; however, I need the following data: Fedora
> 29/32; Ubuntu 16.04 and Debian 9/11 are changed in the latest version
> of 2024?
>

ALL appimages will now be multibit just as if we had checked these patches
into GIT originally.  None will be only 8-bit and no names will change.
Only CinGG-20230131-x86_64-multibit.AppImage will be eliminated.  Nothing
should change in the following except the date and elimination of the 1
named in the previous sentence.  We do not even need to note in the Manual
that these are now multibit -- it is just like any other modification we
make that is just noted in the Release Notes.  I still create the appimages
on those older Operating Systems of Fedora, Debian, and Ubuntu.

CinGG-20240630-x86_64.AppImage
> (currently based on Fedora 32, linux kernel 5.8.15, libc version
> 2.31)CinGG-20230131-x86_64-older-distros.AppImage
>   (currently based on Ubuntu 16.04, libc version 2.23)
> CinGG-20240630-i686.AppImage
>   (currently based on Debian 9, linux kernel 4.9, use "newer" for Debian
> 11.0)
> CinGG-20240630-i686-newer-distros.AppImage
>   (currently based on Debian 11, linux kernel 5.10)
> CinGG-20240630-x86_64-multibit.AppImage
>   (currently based on Fedora 32, libc version 2.31)
> CinGG-20240630-x86_64-older-distros-multibit.AppImage
>   (currently based on Fedora 29 -runs on RHEL8 -linux kernel 4.19.9, libc
> version
>
        → 2.28)
> CinGG-20240630-alternative_shortcuts.AppImage
> (currently based on Ubuntu 16.04, libc version 2.23)
>


> Question to developers on 8-bit / multibit: I can't find anywhere
> instructions on how to compile system ffmpeg with 10-bit x265. Is it
> not that, as std, in ffmpeg all bit-depths are compiled and it is only
> in CinGG that there is something that prevents this, reducing the
> compilation to 8-bit only (thus making the 3 patches necessary)? In
> fact, my system ffmpeg has support for all bit-depths; why doesn't
> CinGG's ffmpeg (without patches)? In short, if this impediment is
> found, there would be no more need for the 3 patches and also the
> compile time would not double (it almost seems like it builds to 8-bit
> and then overlays a new 10-bit build on top of it).


About the increased build time, I think it is due to not being able to
parallel build 8-bit, 10-bit, and 12-bit x265 so that they have to be built
sequentially -- usually "The build rule set of dependencies allows for
compiling multiple thirdparty programs simultaneously using maximum
computer resources. This parallel build speeds up the process considerably."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cinelerra-gg.org/pipermail/cin/attachments/20240718/bd195fb8/attachment.htm>