[Cin] Updated CinGG release for downloading the AppImage
randrianasulu at gmail.com
Fri Nov 5 13:02:44 CET 2021
On Friday, November 5, 2021, Andrea paz via Cin <cin at lists.cinelerra-gg.org>
> If I understand correctly, you used only the h264.mp4 and h265.mp4
> presets, changing the "Pixels" option from "420 8-bit" to "422 10-bit"
> each time. Also, try using the 8, 10 and 12-bit h265 presets; they are
> Andrew's new ones that work for me in the non-multibit version.
> I've tried non-multibit and I can render h264.mp4 at 8 and 10-bit and
> h265.mp4 at 8 and 10-bit. In short, in my case the non-multibit
> version always behaves as a sum of multibit and non-multibit.
> I'm thinking that it's the fault of my system that "gets" the 10-bit
> even when it shouldn't....
you can see use of LD_DEBUG=libs, where appimage apparently tries to
initialize libx265_main10/12.so system files lately (at encodiing stage?),
so may be it was not visible to initial ldd?
I wonder if those files come from appimage or real system?
you and Terje can try to compare output of this LD_DEBUG=libs path_to_cin
command for 10/12 bit h265 encoding..
Not sure if package manager will allow you to delete system-wide x265
development files (so Cin will have nothing but her own x265.a lib to use
at least after self-build).
It seems even with static switch some shared system libs are used (may be
because there was no static a archives in some distro packages?)..
> When I compile a new CinGG I usually delete the old cinelerra5
> directory and then do a git clone. That way it shouldn't encounter any
> residue from the previous installation. Am I wrong? Maybe the fact
> that I compile not as root (except few times I use Valgrind or other
> tests) can be the cause of the behavior of my CinGGs?
> Cin mailing list
> Cin at lists.cinelerra-gg.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Cin