MatN has provided all of the ground work to make an AppImage for CinelerraGG. I have followed the instructions he provided and there are now 2 versions for testing. I only did very minimal testing to load a file. Files are at: https://cinelerra-gg.org/download/testing/ cin_for_older_distros.AppImage - built on Ubuntu 16 (kernel 4.4, I think) cin_for_newer_distros.AppImage - built on Fedora 32 (kernel 5.8, I think) After downloading you will have to change the mode for execution (chmod +x cin_for_older_distros.AppImage) For appimage, the build is supposed to be done on the lowest version distro because otherwise newer libraries might be missing. For example, I tried running cin_for_newer_distros.AppImage on ubuntu 16 and GLIBC version xxx.xxx was not available.
I use Arch Linux KDE (Rolling always updated, now with kernel 5.10.13 and glibc 2.33) I tested effects, transitions, Cuts with drag and drop, videoscopes, OpenEDL, Nested clip and proxies. All OK for both "newer" and "older".
From now on I will use only the newer. Great job! Thanks MatN.
Stupid question: The sources size is 137MB, the AppImage is 79MB; shouldn't the size of the AppImage be much larger?
On Mon, 8 Feb 2021 10:43:00 +0100 Andrea paz via Cin <[email protected]> wrote:
I use Arch Linux KDE (Rolling always updated, now with kernel 5.10.13 and glibc 2.33) I tested effects, transitions, Cuts with drag and drop, videoscopes, OpenEDL, Nested clip and proxies. All OK for both "newer" and "older". From now on I will use only the newer. Great job! Thanks MatN.
Stupid question: The sources size is 137MB, the AppImage is 79MB; shouldn't the size of the AppImage be much larger?
The source size is typically (much) bigger that the resulting program, a CinGG distribution is like 60 MByte. The beauty of AppImage is that increases portability at the expense of some size. The various portability versus size solutions, in order of size (as per my current understanding): - Executable set up for dynamic linking (external libraries (.so files, in Windows these are .dll files) linked at startup time. Smallest executable, but dependent on (versions of) libs available on the platform. So older/newer platforms could have different versions of libraries, with slightly different functionality. In Windows this used to be known as DLL hell. - Executable set up for static linking, including much of the external libraries, so less dependent on platform-specific versions of availability. Because CinGG already does this anyway, a dynamic or static build does not have a difference in size as far as I know, but I have not looked at that in detail. - AppImage. This includes the executable, plus an environment of even more external libraries, reducing the dependence of the underlying system even further. It does not include the graphical environment. Because CinGG already includes so many, the increase in size is not too bad. The disadvantage is that it might not be able to use the newest versions of system libraries, but it is much more portable. An AppImage is a specialised .zip file, if you add the extension .zip you can see what is inside with your archive manager. - Docker containers. These are interesting. Basically they are a whole Linux system with the exception of the lowest layers. When you make one of the existing ones, you specify what they should be based on (like Fedora version xxx), and it builds a specialised image as a container. This large file is stored somewhere locally, but afterwards can be started VERY quickly. I think they are smaller that a Flatpack. For instance, two containers for testing Joomla (that is an Apache webserver + Joomla, and MySql) together take 750 MByte. Containers are very handy for testing an AppImage, and I used them for that. But if you use a not-already-constructed container, it is more work. For some overview, see https://www.docker.com/resources/what-container . - Flatpack/Snap. These includes much more, like parts of the graphical environment, so the application using this can look different from those "native" of the platform. These are easily 700 or more MByte in size, yesterday I cam across one that would take 2.2 GByte of disk space! - A special case is Microsoft's Windows Subsystem for Linux version 2 (WSL2). This is like a container, but the lowest layers are implemented by a software layer (Hyper-V) that maps them to low-level Windows services. These require specialised versions of Linux distro's like Ubuntu to be installed, without the kernel things. I don't know if you can make an "application" like thing out of it. Don't know how big such a WSL2 instance is. But because you have to install an almost complete Linux first, it is not likely small nor quick to start. - Virtual machines (VMs). These emulate the hardware of a whole computer, and you install a complete OS in a ¨instance" of it. They are slightly slower to start than native on the hardware, but because their storage is a file and not a partition on a hard disk, you don't need more storage space than it actually takes. For instance, A VirtualBox VM of Mint 19.3 XFCE takes < 8G. Very handy for trying different distributions, e.g. if CinGG works well on some distributions. They are much more flexible than containers. In theory, you can make an application specific VM, which then could be distributed, but when I tried that with CinGG it didn't work well (I forgot what it was, and they are too big, 8G or more). There are virtual machines that can emulate other hardware, like QEMU. VirtualBox only does x86 32 or 64 bit hardware. And special interfaces like VAAPI, OpenGL, OpenCL or CUDA might not be supported, so a program running inside a VM cannot use such features. Note 1: There might be some limitations with AppImages as compared to a native executable, like command line interfaces. Have not looked at that yet. Note 2: I just noticed that my Synaptic package manager lists CinGG as taking up 179 MByte storage space. The AppImage is half the size, although slightly larger to download, and slower to start. Interesting. Mat Nieuwenhoven
@MatN Thanks for the explanations. Calf plugins are read only at the first start of CinGG compiled, no more in subsequent sessions. AppImage are read every time. Maybe this is the reason for the slightly longer start? I didn't understand Note1, what shell commands should I test? @Phyllis
"BUT, I hope you continue to do your builds and GIT checkout..." Yes, of course.
El lunes, 8 de febrero de 2021 09:58:06 -03 mat via Cin escribió:
- Virtual machines (VMs). These emulate the hardware of a whole computer, and you install a complete OS in a ¨instance" of it. They are slightly slower to start than native on the hardware, but because their storage is a file and not a partition on a hard disk, you don't need more storage space than it actually takes. For instance, A VirtualBox VM of Mint 19.3 XFCE takes < 8G. Very handy for trying different distributions, e.g. if CinGG works well on some distributions. They are much more flexible than containers. In theory, you can make an application specific VM, which then could be distributed, but when I tried that with CinGG it didn't work well (I forgot what it was, and they are too big, 8G or more). There are virtual machines that can emulate other hardware, like QEMU. VirtualBox only does x86 32 or 64 bit hardware. And special interfaces like VAAPI, OpenGL, OpenCL or CUDA might not be supported, so a program running inside a VM cannot use such features
Hi Mat. we can have graphics acceleration in virtual machines. it just takes a little more work and also the type of hardware to use. example. PCI GPU passthrough in the excellent arch wiki there is good information https://wiki.archlinux.org/index.php/QEMU/Guest_graphics_acceleration https://wiki.archlinux.org/index.php/PCI_passthrough_via_OVMF Thanks for the AppImage -- - | Walter Casanova | - - | Gnu / Linux - SysAdmin | -
All, Phyllis makes the AppImage. I only did some finding out how to do it and test it. Different from the method used in BT261. Walter, thanks about the PCI passthrough tip. The Arch wiki indeed is very good, I've used it several times. Andrey, I didn't know about the lxc container, thanks. I'll read up on them. Mat Nieuwenhoven
Andrea, I use Arch Linux KDE (Rolling always updated, now with kernel 5.10.13
and glibc 2.33) I tested effects, transitions, Cuts with drag and drop, videoscopes, OpenEDL, Nested clip and proxies. All OK for both "newer" and "older".
Thanks for a much more inclusive test than what I did.
From now on I will use only the newer.
BUT, I hope you continue to do your builds and GIT checkout because that is where the early testing is most needed to find bugs before they go into appimage (which will only be created maybe monthly so will not have latest mods).
A little more testing has been done so I updated on the website, the README.txt to notify users who might read this: https://cinelerra-gg.org/download/README.txt and added a subdirectory "images" to complement the "tars" and "pkgs" for versions. I called it images in case flatpak shows up too. Images contains the newer and older appimages and another README.appimage based on the note from Andrea in the forum about usage and possibility of having to install another library for Arch and others. Interesting test results for a 1 minute 30 second video rendered as h265 hi quality: binary build -- 50.458 seconds / 53.767 fps older image -- 50.387 seconds / 53.843 fps newer image -- 38.408 seconds / 56.044 fps
MatN, thank you for AppImage versions. I tested launch in normal and daemon (-d) mode, both versions worked ok. Debian testing (amd64). In your last email you missed lxc containers, it's somewhere between docker and vm. Lxc containers have separate ip addresses like VM, but but takes less space on disk and in ram. Best regards, Andrey пн, 8 февр. 2021 г. в 00:50, Phyllis Smith via Cin < [email protected]>:
MatN has provided all of the ground work to make an AppImage for CinelerraGG. I have followed the instructions he provided and there are now 2 versions for testing. I only did very minimal testing to load a file. Files are at:
https://cinelerra-gg.org/download/testing/
cin_for_older_distros.AppImage - built on Ubuntu 16 (kernel 4.4, I think) cin_for_newer_distros.AppImage - built on Fedora 32 (kernel 5.8, I think)
After downloading you will have to change the mode for execution (chmod +x cin_for_older_distros.AppImage) For appimage, the build is supposed to be done on the lowest version distro because otherwise newer libraries might be missing. For example, I tried running cin_for_newer_distros.AppImage on ubuntu 16 and GLIBC version xxx.xxx was not available. -- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
participants (5)
-
Andrea paz -
mat -
Phyllis Smith -
Walter Casanova -
Андрей Спицын