<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">чт, 18 июл. 2024 г., 23:44 Andrea paz via Cin <<a href="mailto:cin@lists.cinelerra-gg.org" rel="noreferrer noreferrer" target="_blank">cin@lists.cinelerra-gg.org</a>>:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> The CinGG-20230131-x86_64.AppImage name will remain the same, but just will now be the multibit version.   The CinGG-20230131-x86_64-multibit.AppImage will no longer exist. I am not going to bother creating an 8-bit appimage as it just seems unnecessary.  I will just leave CinGG-20230131-x86_64-older-distros-multibit.AppImage as the same name to avoid any confusion.<br>
<br>
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>
<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. </blockquote></div></div><div dir="auto"><br></div><div dir="auto">I think at least on Arch linux x265 build all-bit-depth systemwide:</div><div dir="auto"><br></div><div dir="auto"><a href="https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=x265-mod-patman-git" rel="noreferrer noreferrer" target="_blank">https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=x265-mod-patman-git</a><br></div><div dir="auto"><br></div><div dir="auto">may be you can add "--disable-x265" switch to main cingg configure then add -lx265 to ldflags and "--enable-libx265" to FFMPEG_EXTRA_CFG ?</div><div dir="auto"><br></div><div dir="auto"><br></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">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).<br>
-- <br>
Cin mailing list<br>
<a href="mailto:Cin@lists.cinelerra-gg.org" rel="noreferrer noreferrer noreferrer" target="_blank">Cin@lists.cinelerra-gg.org</a><br>
<a href="https://lists.cinelerra-gg.org/mailman/listinfo/cin" rel="noreferrer noreferrer noreferrer noreferrer" target="_blank">https://lists.cinelerra-gg.org/mailman/listinfo/cin</a><br>
</blockquote></div></div></div>