<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small">Andrea, sorry for the confusion.  See below.</div><div class="gmail_default" style="font-size:small"><br></div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
2- Maybe I didn't understand correctly.  Do you intend to rename all<br>
the 2023/24 appimages, removing the word multibit, and deleting the<br>
8-bit ones? Will only the "older-distros" be left untouched? And the<br>
"i386" versions are all 8-bit? I will change the dates from 20230131<br>
to 20240630 in the manual; however, I need the following data: Fedora<br>
29/32; Ubuntu 16.04 and Debian 9/11 are changed in the latest version<br>
of 2024?<br></blockquote><div> </div><div><span class="gmail_default" style="font-size:small">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.<br></span></div><div><span class="gmail_default" style="font-size:small"><br></span></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail_default" style="font-size:small">CinGG-20240630-x86_64.AppImage</span><br><span class="gmail_default" style="font-size:small">(currently based on Fedora 32, linux kernel 5.8.15, libc version 2.31)CinGG-20230131-x86_64-older-distros.AppImage</span><br><span class="gmail_default" style="font-size:small">  (currently based on Ubuntu 16.04, libc version 2.23)</span><br><span class="gmail_default" style="font-size:small">CinGG-20240630-i686.AppImage</span><br><span class="gmail_default" style="font-size:small">  (currently based on Debian 9, linux kernel 4.9, use "newer" for Debian 11.0)</span><br><span class="gmail_default" style="font-size:small">CinGG-20240630-i686-newer-distros.AppImage</span><br><span class="gmail_default" style="font-size:small">  (currently based on Debian 11, linux kernel 5.10)</span><br><strike>CinGG-202<span class="gmail_default" style="font-size:small">40630</span>-x86_64-multibit.AppImage<br>  (currently based on Fedora 32, libc version 2.31)</strike><br><span class="gmail_default" style="font-size:small">CinGG-20240630-x86_64-older-distros-multibit.AppImage</span><br><span class="gmail_default" style="font-size:small">  (currently based on Fedora 29 -runs on RHEL8 -linux kernel 4.19.9, libc version</span><br><span class="gmail_default" style="font-size:small"></span></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail_default" style="font-size:small">        → 2.28)</span><br><span class="gmail_default" style="font-size:small">CinGG-20240630-alternative_shortcuts.AppImage</span><br><span class="gmail_default" style="font-size:small">(currently based on Ubuntu 16.04, libc version 2.23)</span><br><span class="gmail_default" style="font-size:small"></span></blockquote></div><div><span class="gmail_default" style="font-size:small"><br></span></div><div><span class="gmail_default" style="font-size:small"></span> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Question to developers on 8-bit / multibit: I can't find anywhere<br>
instructions on how to compile system ffmpeg with 10-bit x265. Is it<br>
not that, as std, in ffmpeg all bit-depths are compiled and it is only<br>
in CinGG that there is something that prevents this, reducing the<br>
compilation to 8-bit only (thus making the 3 patches necessary)? In<br>
fact, my system ffmpeg has support for all bit-depths; why doesn't<br>
CinGG's ffmpeg (without patches)? In short, if this impediment is<br>
found, there would be no more need for the 3 patches and also the<br>
compile time would not double (it almost seems like it builds to 8-bit<br>
and then overlays a new 10-bit build on top of it).</blockquote><div> <br></div><div><span class="gmail_default" style="font-size:small">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 "</span>The build<span class="gmail_default" style="font-size:small"> </span>rule set of dependencies allows for compiling multiple thirdparty programs simultaneously using maximum computer resources. This parallel build speeds up th<span class="gmail_default" style="font-size:small">e </span>process considerably.<span class="gmail_default" style="font-size:small">"</span><br></div><div> </div></div></div>