There are now 4 newly created AppImage's for CinGG as follows: https://cinelerra-gg.org/download/images/CinGG-20210731-x86_64.AppImage - for newer distros https://cinelerra-gg.org/download/images/CinGG-20210731-x86_64-older_distros... https://cinelerra-gg.org/download/images/CinGG-20210731-i386.AppImage - for 32 bit https://cinelerra-gg.org/download/images/CinGG-20210731-multibit.AppImage - for extra 10 and 12 bit The "multibit" AppImage was created on Mint 20 using the patch supplied by Andrew_R (which will be checked into GIT as a patch after I get the manual wording done to match). I tested this by rendering using the h265_10bit and h265_12bit formats -- which will not work without the 10 and 12 bit compiled version. But it is important to note that the multibit AppImage will only work on the appropriate Operating Systems which have all of the needed libraries installed. In other words, it worked on the Mint 20 system here as well as my laptop running Fedora 32 BUT did not work on the big desktop computer. And the HTML and pdf versions of the manuals have been updated: https://cinelerra-gg.org/download/CinelerraGG_Manual.pdf https://cinelerra-gg.org/download/CinelerraGG_Manual/ One more note -- the upgrade of ffmpeg from 4.3 to 4.4 is still awaiting a patch for the bluray. A "freelancer" was working on this and said he had a "fix", but then he disappeared so maybe he got sick or has some problem. Who knows these days but I hope a solution is available in August. Notes from the releasenote.pdf file: **************************************** *GIT for Cinelerra-GG has the following changes from 07/01/2021-07/31/2021* Workaround for “attach effect” bug when using In/Out pointers as *discovered by DeJay* and discussed in the forum is to use drag from the Resources window instead. Bug was introduced with the mods checked into GIT on 6/26/2020 in the track.C program. Fix not yet available but would be easy for someone who knows c++ and a little about CinGG. *Andrew R *has contributed all of the following upgrades/fixes with *Andrea doing additional tests*: Upgrade of x264 to 2021-06-15 master version from 20191217-2245-stable version. Upgrade of x265 from 3.4 to 3.5. Upgrade libaom from 3.0.0 to 3.1.1 and modified the build parameters to eliminate unnecessary docs. YUV Color Space has had 601 and 2020 split into 601-NTSC/601-PAL and BT2020-NCL/BT202/CL. Old projects will not be affected because 601-NTSC and BT2020-NCL are the old defaults. Updated or new profile formats of h265-10bit and h265-12bit. Export EDL option for CMX3600 formatted output has been re-instated and proven to work in at least one other application - Final Cut Pro for PPC Mac and also OpenShot with possible caveats. Changes may need to be made if there is a reason to do so for a specific case. *Rafa Mar* updated the Spanish translations.
and i updated my patchset (attached) on top of this.. full rebuild takes like 2660 seconds... not much changed, just added 0065-libvpx-disable-examples-and-unit-tests.patch and spend some time with x265_3.5.patch3 and my_configure On Sunday, August 1, 2021, Phyllis Smith via Cin <[email protected]> wrote:
There are now 4 newly created AppImage's for CinGG as follows:
https://cinelerra-gg.org/download/images/CinGG-20210731-x86_64.AppImage - for newer distros https://cinelerra-gg.org/download/images/CinGG- 20210731-x86_64-older_distros.AppImage https://cinelerra-gg.org/download/images/CinGG-20210731-i386.AppImage - for 32 bit https://cinelerra-gg.org/download/images/CinGG-20210731-multibit.AppImage - for extra 10 and 12 bit
The "multibit" AppImage was created on Mint 20 using the patch supplied by Andrew_R (which will be checked into GIT as a patch after I get the manual wording done to match). I tested this by rendering using the h265_10bit and h265_12bit formats -- which will not work without the 10 and 12 bit compiled version. But it is important to note that the multibit AppImage will only work on the appropriate Operating Systems which have all of the needed libraries installed. In other words, it worked on the Mint 20 system here as well as my laptop running Fedora 32 BUT did not work on the big desktop computer.
And the HTML and pdf versions of the manuals have been updated:
https://cinelerra-gg.org/download/CinelerraGG_Manual.pdf https://cinelerra-gg.org/download/CinelerraGG_Manual/
One more note -- the upgrade of ffmpeg from 4.3 to 4.4 is still awaiting a patch for the bluray. A "freelancer" was working on this and said he had a "fix", but then he disappeared so maybe he got sick or has some problem. Who knows these days but I hope a solution is available in August.
Notes from the releasenote.pdf file: **************************************** *GIT for Cinelerra-GG has the following changes from 07/01/2021-07/31/2021*
Workaround for “attach effect” bug when using In/Out pointers as *discovered by DeJay* and discussed in the forum is to use drag from the Resources window instead. Bug was introduced with the mods checked into GIT on 6/26/2020 in the track.C program. Fix not yet available but would be easy for someone who knows c++ and a little about CinGG.
*Andrew R *has contributed all of the following upgrades/fixes with *Andrea doing additional tests*:
Upgrade of x264 to 2021-06-15 master version from 20191217-2245-stable version. Upgrade of x265 from 3.4 to 3.5. Upgrade libaom from 3.0.0 to 3.1.1 and modified the build parameters to eliminate unnecessary docs. YUV Color Space has had 601 and 2020 split into 601-NTSC/601-PAL and BT2020-NCL/BT202/CL. Old projects will not be affected because 601-NTSC and BT2020-NCL are the old defaults. Updated or new profile formats of h265-10bit and h265-12bit. Export EDL option for CMX3600 formatted output has been re-instated and proven to work in at least one other application - Final Cut Pro for PPC Mac and also OpenShot with possible caveats. Changes may need to be made if there is a reason to do so for a specific case.
*Rafa Mar* updated the Spanish translations.
The new AppImage does not start on Arch and gives the following error: dlopen(): error loading libfuse.so.2 AppImages require FUSE to run. You might still be able to extract the contents of this AppImage if you run it with the --appimage-extract option. See https://github.com/AppImage/AppImageKit/wiki/FUSE for more information I use fuse2 which contains usr/lib/libfuse.so.2 and usr/lib/libfuse.so.2.9.9. I can also install fuse3 but it is incompatible with fuse2 and has different libraries.
@Andrea, I have this error when I run the i386 image on a 64 bit Mint 20.2 (required installing lib32z1 first, so far, I have not yet done 32 bit testing on this Mint 20.2 partition). MatN On Sun, 1 Aug 2021 13:21:56 +0200 Andrea paz via Cin <[email protected]> wrote:
The new AppImage does not start on Arch and gives the following error:
dlopen(): error loading libfuse.so.2 AppImages require FUSE to run. You might still be able to extract the contents of this AppImage if you run it with the --appimage-extract option. See https://github.com/AppImage/AppImageKit/wiki/FUSE for more information
I use fuse2 which contains usr/lib/libfuse.so.2 and usr/lib/libfuse.so.2.9.9. I can also install fuse3 but it is incompatible with fuse2 and has different libraries.
#MatN How stupid I am! I thought I downloaded the multibit appimage and not the line above. However even the multibit version gives me an error: /home/paz/Desktop/CinGG-20210731-multibit.AppImage: error while loading shared libraries: libjbig.so.0: cannot open shared object file: No such file or directory I don't actually have these libraries. I have the jbigkit package that provides the libraries: usr/lib/libjbig.a usr/lib/libjbig85.a The x86_64 version, on the other hand, starts without any problems. @Andrew Any indications on how I should put randrik14 patches? All together with --whitespace=fix? Other?
Andrea, Thank you for testing the multibit AppImage. I suspected there would be problems with multibit. I will see what I can find today and will recreate it on the Fedora desktop where the AppImage did not work (instead of Mint 20) to see if that produces a more usable version. *Does the normal AppImage work?* That is my biggest concern and I was worried that that is what you were talking about in your initial email since you did not specify. How stupid I am! I thought I downloaded the multibit appimage and not
the line above. However even the multibit version gives me an error:
/home/paz/Desktop/CinGG-20210731-multibit.AppImage: error while loading shared libraries: libjbig.so.0: cannot open shared object file: No such file or directory
Andrea, I recreated the multibit AppImage so you will have to download the new one which replaced the old (when/if you have time). It was tested on Arch of 2020/10/30 and worked just fine there as well as both laptop and desktop Fedora. Not sure what the problem was -- I should stick to what I know so I created it on Fedora instead of the original of Mint 20 but I was trying to be versatile.
/home/paz/Desktop/CinGG-20210731-multibit.AppImage: error while loading shared libraries: libjbig.so.0: cannot open shared object file: No such file or directory
When it did not work on my desktop, instead of libjbig, I got libbz2.so.1.0 with the same error message.
On Sunday, August 1, 2021, Phyllis Smith via Cin <[email protected]> wrote:
Andrea, I recreated the multibit AppImage so you will have to download the new one which replaced the old (when/if you have time). It was tested on Arch of 2020/10/30 and worked just fine there as well as both laptop and desktop Fedora. Not sure what the problem was -- I should stick to what I know so I created it on Fedora instead of the original of Mint 20 but I was trying to be versatile.
/home/paz/Desktop/CinGG-20210731-multibit.AppImage: error while loading shared libraries: libjbig.so.0: cannot open shared object file: No such file or directory
When it did not work on my desktop, instead of libjbig, I got libbz2.so.1.0 with the same error message.
isn't this a bit strange? appimage supposed to sidestep this problem by packaging all libs into.. image, no?
On Sunday, August 1, 2021, Andrew Randrianasulu <[email protected]> wrote:
On Sunday, August 1, 2021, Phyllis Smith via Cin < [email protected]> wrote:
Andrea, I recreated the multibit AppImage so you will have to download the new one which replaced the old (when/if you have time). It was tested on Arch of 2020/10/30 and worked just fine there as well as both laptop and desktop Fedora. Not sure what the problem was -- I should stick to what I know so I created it on Fedora instead of the original of Mint 20 but I was trying to be versatile.
/home/paz/Desktop/CinGG-20210731-multibit.AppImage: error while loading shared libraries: libjbig.so.0: cannot open shared object file: No such file or directory
When it did not work on my desktop, instead of libjbig, I got libbz2.so.1.0 with the same error message.
isn't this a bit strange? appimage supposed to sidestep this problem by packaging all libs into.. image, no?
found this article, may be tool(s) used for creating our appimage or their blacklist need some tweaking? https://discourse.appimage.org/t/does-appimage-include-all-shared-library-de...
On Sunday, August 1, 2021, Andrea paz via Cin <[email protected]> wrote:
#MatN How stupid I am! I thought I downloaded the multibit appimage and not the line above. However even the multibit version gives me an error:
/home/paz/Desktop/CinGG-20210731-multibit.AppImage: error while loading shared libraries: libjbig.so.0: cannot open shared object file: No such file or directory
I don't actually have these libraries. I have the jbigkit package that provides the libraries: usr/lib/libjbig.a usr/lib/libjbig85.a
The x86_64 version, on the other hand, starts without any problems.
@Andrew Any indications on how I should put randrik14 patches? All together with --whitespace=fix? Other?
well, you can try without --whitespace=fix first.. i hope all new patches should be free from those errors. if it still fail to build - you can try to not apply (move aside, rename) patch adding ffmpeg-4.4 mpegts patch2. i hope other patches will work for you...
-- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
@Phyllis Now the multibit appimage works without error; thanks, Phyllis. @Andrew OK, I'll try tomorrow. Can I add the proxy patch to the others or do I have to apply it after a make?
On Sunday, August 1, 2021, Andrea paz <[email protected]> wrote:
@Phyllis Now the multibit appimage works without error; thanks, Phyllis. @Andrew OK, I'll try tomorrow. Can I add the proxy patch to the others or do I have to apply it after a make?
i think idea behind this patch was considered unneded? you can still apply it (at very end of patching, via git apply) if you want to test idea about putting proxies in sub-folders and not alongside media..
participants (4)
-
Andrea paz -
Andrew Randrianasulu -
mnieuw＠zap.a2000.nl -
Phyllis Smith