From ebf66970ed8f2c8c9a8b247875ebf42275dc5de1 Mon Sep 17 00:00:00 2001 From: Good Guy Date: Sat, 12 Feb 2022 11:32:32 -0700 Subject: [PATCH 1/1] minor improvements from Andrea --- parts/Developer.tex | 13 +++++++------ parts/Installation.tex | 7 ++++--- parts/Tips.tex | 7 ++++++- 3 files changed, 17 insertions(+), 10 deletions(-) diff --git a/parts/Developer.tex b/parts/Developer.tex index c8c3f89..f8939cc 100644 --- a/parts/Developer.tex +++ b/parts/Developer.tex @@ -664,7 +664,7 @@ You can work on the appimage file to make changes and fix errors, or you can cre \subsection{Managing AppImage} \label{sub:managing_appimage} - +\index{appimage!management} A limitation of using AppImage instead of installing the binary or compiling from git, is that there is only a single file without the ability to browse the directory structure or to look for files to edit or check. So if using \CGG{} leads to some errors, it is not possible to investigate and fix the problem. Which means if you want to add the most up-to-date Context-Help or want to introduce some custom presets, that can not be done. Because the appimage file is nothing more than a compressed file containing the same structure as the installed program plus other libraries that allow the program to run independently from the system, the content can be extracted so that you can work on it as you would have on the normally installed program. To do this you will need the appimage management program. @@ -673,7 +673,7 @@ Many Linux distros come with this managment program by default, but others may n To work on the appimage, first unpack it using the command\protect\footnote{Example provided by Glitterball3}: \begin{lstlisting}[numbers=none] - /{path to appimage}/CinGG-20220131-x86_64.AppImage --appimage-extract + /{path to appimage}/CinGG-yyyymmdd.AppImage --appimage-extract \end{lstlisting} You will now have a \texttt{squashfs-root} folder containing \texttt{/usr/bin/} as well as other files and directories such as \texttt{/usr/lib} and \texttt{/usr/share}. \texttt{Bin} is the folder similar to the one installed with \CGG{} and contains the files that you can work on. Now it is possible to make changes like adding a custom preset in \texttt{/ffmpeg/video} or replacing a library that no longer works with a more recent version by working in \texttt{/squashfs-root/usr/lib}. @@ -702,13 +702,14 @@ A new appimage will be created like the original but containing the changes. Alternatively, download the \texttt{appimagetool} version from \url{https://github.com/AppImage/AppImageKit/releases} if available for your distro and use the command: \begin{lstlisting}[numbers=none] - ./appimagetool --comp /{path to appimage}/squashfs-root /tmp/my-appimage.appimage + ./appimagetool --comp /{path to appimage}/squashfs-root /tmpCinGG-yyyymmdd.AppImage \end{lstlisting} -Now there will be an appimage called \textit{my-appimage.appimage} with the changes that were made. +Now there will be an appimage called \textit{CinGG-yyyymmdd.AppImage} with the changes that were made. -\subsection{Build the \CGG{} AppImage from scratch} +\subsection{Build the CinGG.AppImage from scratch} \label{sub:built_appimage_scratch} +\index{appimage!creating} If a developer wants to create an appimage from git, follow these next few steps. An existing automated script is available, \texttt{bld\_appimage.sh}, in the directory \texttt{/\{path to cinelerra-5.1\}/blds}. @@ -726,7 +727,7 @@ Now copy \texttt{/\{path to cinelerra-5.1\}/blds/bld\_appimage.sh} to \texttt{/\ chmod x+u bld_appimage.sh \end{lstlisting} -Download linuxdeploy appimage from \url{https://github.com/linuxdeploy/linuxdeploy/releases/continuous} and copy it to \texttt{/\{path to cinelerra-5.1\}/} and make it executable. +Download linuxdeploy appimage from \url{https://github.com/linuxdeploy/linuxdeploy/releases/continuous} and copy it to \texttt{\{path to cinelerra-5.1\}} and make it executable. You can make additions or changes in this script if you want to customize the appimage. Then run the command: \begin{lstlisting}[numbers=none] diff --git a/parts/Installation.tex b/parts/Installation.tex index 0be18e3..6b64974 100644 --- a/parts/Installation.tex +++ b/parts/Installation.tex @@ -4,16 +4,15 @@ \section{\CGG{} AppImage}% \label{sec:cin_gg_appimage} +\index{appimage} The main way to install \CGG{} is to use the AppImage. This is updated regularly and works for every distro, since it already contains the necessary dependencies. A big advantage of using the AppImage format is that it is only 1/3 the size of the normal install, and since each release is named differently, you can keep a number of versions in a directory, and when testing from a terminal you just have to type CinGG, then hit tab, and complete it to the desired date release. - For 64-bit systems you can choose between an image with up-to-date libraries or one that supports older libraries, which you should use only if the first image gives you problems with unsupported libs. There is also a 32-bit older distro available that has \textit{i686} as part of the filename that currently works on older distros but may not work on the newest distros -(most of the popular Linux distributions such -as Arch, Ubuntu, and Fedora have dropped support for this older architecture). In any case, if you are using a 32-bit Linux distro, you should compile your sources from git or use a precompiled binary\protect\footnote{Remember that a 32-bit distro does not address more than 4GB of memory, so you may have stability and performance problems with large, high-resolution mediafiles.}. And there is a 8/10/12 bit newer distro that handles 8 or 10 or 12 bits that has \textit{multibit} as part of the filename. Installing the appimage is simple: +(most of the popular Linux distributions such as Arch, Ubuntu, and Fedora have dropped support for this older architecture). In any case, if you are using a 32-bit Linux distro, you should compile your sources from git or use a precompiled binary\protect\footnote{Remember that a 32-bit distro does not address more than 4GB of memory, so you may have stability and performance problems with large, high-resolution mediafiles.}. And there is a 8/10/12 bit newer distro that handles 8 or 10 or 12 bits that has \textit{multibit} as part of the filename. Installing the appimage is simple: Download the file from: @@ -69,6 +68,8 @@ In addition, if you are using the OpenGL video driver, you will need to install drivers for your Operating System graphics board because libGLU.so and other OpenGL libraries are not included in the AppImage. +Using AppImage means you can't have the installation folder and work on the files. To unpack the AppImage and get its structure in folders and files see \nameref{sub:managing_appimage} To create, edit and manage appimages see \nameref{sub:built_appimage_scratch}. + \section{Download Already Built \CGG{}}% \label{sec:download_already_built_cinelerra_gg} diff --git a/parts/Tips.tex b/parts/Tips.tex index df44161..a9c8604 100644 --- a/parts/Tips.tex +++ b/parts/Tips.tex @@ -33,7 +33,12 @@ VDPAU, Video Decode and Presentation API for Unix, is an open source library to VA-API, Video Acceleration API, is an open source library which provides both hardware accelerated video encoding and decoding for use mostly with Intel (and AMD) graphics boards. AppImage will probably not allow for either VDPAU or VA-API hardware acceleration because the -computer where AppImage is created will not have the same graphics card as yours. +computer where AppImage is created will not have the same graphics card and/or vaapi/vdpau +libraries as yours. In other words: +\begin{itemize} + \item Hardware acceleration, vaapi or vdpau, works the same running either the created binary or the created AppImage from that binary on that same computer. + \item Hardware acceleration using an AppImage created on another computer running a different Operating System or even just a different level of Operating System, most likely will not work unless the user's computer just happens to have the same characteristics with respect to vaapi/vdpau as the computer where the AppImage was created. +\end{itemize} Currently only the most common codecs, such as MPEG-1, MPEG-2, MPEG-4, H.264 /MPEG-4 and h265 (hevc), are accelerated/optimized by the graphics card to play these particular video formats efficiently. The other formats are not optimized so you will see no performance improvement since the CPU will handle them as before, just as if no hardware acceleration was activated. There are many different graphics cards and computer systems setup, so you will have to test which specific settings work best for you. So far this has been tested at least with Nvidia, Radeon, and Broadwell graphics boards on some AMD and Intel computers; depending on the graphics card, two to ten times higher processing speeds can be achieved. However, most graphic operations are single-threaded so that performing the operations in the hardware may actually be slower than in software making use of multiple CPUs, which frequently multi-thread many operations simultaneously. -- 2.26.2