\texttt{make install}
\end{enumerate}
-A lot of things can be tweaked to change the results. Mostly these changes are parameters to the configure step, which can change important build related items, like the application name, or where and what the target system directories should be. This makes it possible to have several versions at the same time on the same computer if needed. To see what it is that the makefiles use to build Cinelerra, look at the resulting top-level global\_config file which is created by the ./configure step.
+A lot of things can be tweaked to change the results. Mostly these changes are parameters to the configure step, which can change important build related items, like the application name, or where and what the target system directories should be. This makes it possible to have several versions at the same time on the same computer if needed. To see what it is that the makefiles use to build \CGG{}, look at the resulting top-level global\_config file which is created by the ./configure step.
-Building Cinelerra requires many thirdparty libraries, and it is recommended that you use the static build version included in the git repo. Some of them are patched, and fix significant bugs. It is important to note that because system installation historically has been with as many shared objects as possible, the defaults are that any system library detected during configuration setup will be used, when the package is built \textit{-{}-without-single-user}, which is the default build. To build with static thirdparty libraries for system install to the system /usr area, use:
+Building \CGG{} requires many thirdparty libraries, and it is recommended that you use the static build version included in the git repo. Some of them are patched, and fix significant bugs. It is important to note that because system installation historically has been with as many shared objects as possible, the defaults are that any system library detected during configuration setup will be used, when the package is built \textit{-{}-without-single-user}, which is the default build. To build with static thirdparty libraries for system install to the system /usr area, use:
\hspace{2em}\texttt{.configure -{}-enable-static-build --prefix=/usr}
-{}-enable-libname=no & this forces no thirdparty build\\
\end{tabular}
-FFmpeg is a \textit{strongly connected} component in the build linkage and widely influences the Cinelerra library demands. It is possible to make small additions to the ffmpeg configuration step using the environment variable \texttt{FFMPEG\_EXTRA\_CFG}. For example, to eliminate the use of libvdpau (an nvidia support library) in the ffmpeg configuration step after you have determined that it is causing an error, use:
+FFmpeg is a \textit{strongly connected} component in the build linkage and widely influences the \CGG{} library demands. It is possible to make small additions to the ffmpeg configuration step using the environment variable \texttt{FFMPEG\_EXTRA\_CFG}. For example, to eliminate the use of libvdpau (an nvidia support library) in the ffmpeg configuration step after you have determined that it is causing an error, use:
\begin{itemize}[label={},nosep]
\item \texttt{make clean}
cp Makefile.devel Makefile
\end{lstlisting}
-Since the procedure for obtaining the latest ffmpeg version is not always kept up-to-date and the line numbers will always change, you may have to create that patch first. Generally those line numbers are only updated by a developer when a new stable version with worthwhile features is actually included in the Cinelerra build. FFmpeg is constantly changing and many times the git version is not as stable as desired.
+Since the procedure for obtaining the latest ffmpeg version is not always kept up-to-date and the line numbers will always change, you may have to create that patch first. Generally those line numbers are only updated by a developer when a new stable version with worthwhile features is actually included in the \CGG{} build. FFmpeg is constantly changing and many times the git version is not as stable as desired.
\section{Configuration Features}
\label{sec:configuration_features}
\fontsize{10pt}{12pt}\selectfont
\begin{verbatim}
-`configure' configures Cinelerra to adapt to many kinds of systems.
+`configure' configures \CGG{} to adapt to many kinds of systems.
Usage: ./configure [OPTION]... [VAR=VALUE]...
\hspace{2em}\texttt{make -C thirdparty <pkg>-clean; make -C thirdparty <pkg>}
-The rule targets create the set of thirdparty packages which are built from local source archive copies of thirdparty source code and patches, if needed. The build rule set of dependencies allows for compiling multiple thirdparty programs simultaneously using maximum computer resources. This parallel build speeds up the process considerably. For example, these are full static build timings on the production build machine (full build includes building all thirdparty programs as well as all of Cinelerra):
+The rule targets create the set of thirdparty packages which are built from local source archive copies of thirdparty source code and patches, if needed. The build rule set of dependencies allows for compiling multiple thirdparty programs simultaneously using maximum computer resources. This parallel build speeds up the process considerably. For example, these are full static build timings on the production build machine (full build includes building all thirdparty programs as well as all of \CGG{}):
\hspace{2em}
\begin{tabular}{@{}rcr}
24 cpus & = & 2 mins\\
\end{tabular}
+\section{Using the very latest Libraries}
+\label{sec:latest_libraries}
+
+Using the most current libraries can be a challenge for some of the Operating System distros that use
+stable compilers, assemblers, and their own libraries. Because they are stable, they frequently do
+not keep up with the very latest of thirdparty libraries. Consequently, some program constructs may
+not yet be implemented. \CGG{} tries to maintain stability since it is better to have less features
+and no crashes. The goal is to make \CGG{} widely available on many platforms rather than
+dependent on advanced tools that are not supported on some distros.
+
+\CGG{} attempts to upgrade to the latest releases of many thirdparty libraries about every 3-4
+months. But it is often difficult to keep some of these thirdparty libraries up to date as their
+developers switch from tried and true standard tools to newer, less standard tools. As a result
+in order to build \CGG{} on 2-3 versions of any distro rather than only the most current version,
+some thirdparty libraries can not be kept up to date and may even be to the point of no further
+updates. In a lot of cases, the updated releases provide little new capabilities but rather
+are bug fixes that may not even be relevant to \CGG{}'s use.
+
+So as a computer savvy user or a developer, if you would like to build \CGG{} with the latest
+thirdparty releases for some of the packages here are a few suggestions based on other
+developer's feedback and experimentation.
+
+\textbf{dav1d}
+\begin{description}[noitemsep]
+ \item Status - currently \CGG{} is staying at 0.5. This is disappointing because there
+may be speed gains in version 0.6 that would be beneficial. However, it is usable for decoding
+whereas libaom is just too slow. Unfortunately, it has no effective encoder.
+ \item Problem - 0.6 dav1d requires NASM 2.14 and uses instructions like vgf2p8affineqb,
+not exactly an "add" instruction. It also uses meson which is not widely available on all
+distros. The only distros that are built for \CGG{} that are at 2.14 are the latest version
+of Arch, Debian(10), Gentoo, Tumbleweed, and Fedora(31). The rest are at 2.12 and 2.13 including
+the most widely used Ubuntu. The NASM requirement apparently provides for using AVX-512
+instructions (like vgf2p8affineqb, which is more like a whole routine than a simple instruction).
+ \item Workaround already in use by \CGG{} - a Makefile was generated to replace Meson usage
+but has to be continuously updated for new releases. Dav1d 0.5 requires NASM 2.13 so at this level
+the newer distros mostly work. The availability of meson and nasm are a significant problem on
+many systems which are still in wide use.
+ \item Your workaround - Because a request to dav1d developers to consider changes to
+ensure their library is more widely usable does not appear to be in their future, since it works
+for them, you can upgrade NASM to 2.14 to stay up to date. Of course, install meson also.
+\end{description}
+
+\textbf{OpenExr}
+\begin{description}[noitemsep]
+ \item Status - currently at latest version
+ \item Problem - the OpenExr tarball is not a single package but is 2 packages instead
+ \item Workaround already in use by \CGG{} - reworked the packages so that it looks like
+one package with 2 stubs
+ \item Your workaround - perhaps use the same workaround
+\end{description}
+
+\textbf{OpenCV}
+\begin{description}[noitemsep]
+ \item Status - 2 different versions specific for O/S but none for Ubuntu 14, 32 or 64 bit
+ \item Problem - There are really 2 problems here. The first is OpenCV is not really
+"Open" in that Surf is patented/non-free and there is no actual source available for certain
+capabilities. The second is that cmake 3.5.1 is required for OpenCV 4.2.
+ \item Workaround already in use by \CGG{} - using 3.4.1 for older distros and 4.2 for newer
+ \item Your workaround - upgrade cmake to 3.5.1 for upgrade to 4.2; add non-free to the
+compile; and use binaries that you do not know what they contain since no source code to compile.
+Look into opencv4/opencv2/core/types.hpp:711;27
+\end{description}
+
+\textbf{webp}
+\begin{description}[noitemsep]
+ \item Status - currently at version 1.1.0
+ \item Problem - requires cmake 3.5
+ \item Workaround already in use by \CGG{} - leaving out of Ubuntu14, Ubuntu, Centos7
+ \item Your workaround - upgrade on those systems to cmake 3.5
+\end{description}
+
+\textbf{libaom}
+\begin{description}[noitemsep]
+ \item Status - currently at version 1.0.0
+ \item Problem - requires cmake 3.5
+ \item Workaround already in use by \CGG{} - leaving out of Ubuntu14, Ubuntu, Centos7
+ \item Your workaround - upgrade on those systems to cmake 3.5
+\end{description}
+
+\textbf{x10tv}
+\begin{description}[noitemsep]
+ \item Status - this is the x10 TV remote control
+ \item Problem - INPUT\_PROP\_POINTING\_STICK not defined error on older distros
+ \item Workaround already in use by \CGG{} - leaving out of Ubuntu14, Ubuntu, Centos7
+ \item Your workaround - look into /usr/include/linux/input-event-codes.h
+\end{description}
+
+\textbf{libvpx}
+\begin{description}[noitemsep]
+ \item Status - currently at version 1.8.1
+ \item Problem - when decoding a test file, it failed to correctly load to the timeline
+ \item Workaround already in use by \CGG{} - not upgrading to 1.8.2
+ \item Your workaround - no analysis for a solution has been performed yet
+\end{description}
+
\section{Find Lock Problems with Booby Trap}
\label{sec:find_lock_problems_booby_trap}
\section{Valgrind Support Level}
\label{sec:valgrind_support_level}
-Valgrind is a memory mis-management detector. It shows you memory leaks, deallocation errors, mismanaged threads, rogue reads/writes, etc. Cinelerra-GG memory management is designed to work with Valgrind detection methods. This assists in developing reliable code. Use of Valgrind points out problems so that they can be fixed. For example, when this version of Cinelerra shuts down, it deallocates memory instead of just stopping, thus making memory leak detection possible.
+Valgrind is a memory mis-management detector. It shows you memory leaks, deallocation errors, mismanaged threads, rogue reads/writes, etc. \CGG{} memory management is designed to work with Valgrind detection methods. This assists in developing reliable code. Use of Valgrind points out problems so that they can be fixed. For example, when this version of \CGG{} shuts down, it deallocates memory instead of just stopping, thus making memory leak detection possible.
The best way to compile and run valgrind is to run the developer static build. This takes 2 steps and you must already have gdb and valgrind installed:
\texttt{CFLAGS=-ggdb make -j8 rebuild\_all}
\end{enumerate}
-Now your Cinelerra obj has all of the debug stuff. Next run valgrind as root for the most useful results:
+Now your \CGG{} obj has all of the debug stuff. Next run valgrind as root for the most useful results:
\hspace{2em}\texttt{cd /path/cinelerra-5.1/cinelerra}
\hspace{2em}\texttt{valgrind -{}-log-file=/tmp/log -{}-leak-check=full\\
-{}-num-callers=32 ./ci}
-This runs Cinelerra under the control of valgrind, and produces a log file in /tmp which will list information about any leaks, usually clearly identifiable. Be sure to Quit out of Cinelerra normally instead of Ctrl-C or a SEGV otherwise the program does not have a chance to cleanup and there will be some false alarms. But it runs very slowly, and is basically single threaded, which means that race conditions may be impossible to catch$\dots$ like one thread deletes memory that another thread is currently using. But overall it is a big help and if you test any new features, please email the log output. A lot of effort when writing the code was put into trying to be sure that all of the object constructors have matching destructors so that the leaks can be identified. There are already several libraries that create predictable memory leaks and valgrind does a good job for most of these.
+This runs \CGG{} under the control of valgrind, and produces a log file in /tmp which will list information about any leaks, usually clearly identifiable. Be sure to Quit out of \CGG{} normally instead of Ctrl-C or a SEGV otherwise the program does not have a chance to cleanup and there will be some false alarms. But it runs very slowly, and is basically single threaded, which means that race conditions may be impossible to catch$\dots$ like one thread deletes memory that another thread is currently using. But overall it is a big help and if you test any new features, please email the log output. A lot of effort when writing the code was put into trying to be sure that all of the object constructors have matching destructors so that the leaks can be identified. There are already several libraries that create predictable memory leaks and valgrind does a good job for most of these.
-It is impossible to test everything with valgrind because some things are just too big and slow for a practical test. Occasionally you can find a leak or an illegal memory access. There are several false alarms that are difficult to avoid \textit{Conditional jump} messages, and \textit{unhandled DW\_OP\_}, but anything with the word \textit{illegal} in the message is important. Memory leaks that originate in Cinelerra are good to find and fix, but are usually not deadly.
+It is impossible to test everything with valgrind because some things are just too big and slow for a practical test. Occasionally you can find a leak or an illegal memory access. There are several false alarms that are difficult to avoid \textit{Conditional jump} messages, and \textit{unhandled DW\_OP\_}, but anything with the word \textit{illegal} in the message is important. Memory leaks that originate in \CGG{} are good to find and fix, but are usually not deadly.
\section{CFLAGS has -Wall}
\label{sec:cflags_has_-wall}
-When compiling Cinelerra-GG Infinity a CFLAGS option used is \textit{Wall} where the "W" represents warnings and "all" means all. This causes the compile to check for simple mistakes that can be detected automatically and issue warnings when the code is questionable. It can also detect situations where the compiler will generate incorrect code, like type-punned pointer. By turning on this flag, when new code is vetted for predictable mistakes, the code can be corrected before becoming manifested in the application.
+When compiling \CGG{} Infinity a CFLAGS option used is \textit{Wall} where the "W" represents warnings and "all" means all. This causes the compile to check for simple mistakes that can be detected automatically and issue warnings when the code is questionable. It can also detect situations where the compiler will generate incorrect code, like type-punned pointer. By turning on this flag, when new code is vetted for predictable mistakes, the code can be corrected before becoming manifested in the application.
\section{Prof2 -- A Profiler}
\label{sec:prof2_profiler}
This profiler works on x86\_64 systems and you must be root to compile and run it. Also, you must install your operating system's \textit{iberty} -- for example, which would be binutils-devel for Fedora or libiberty-dev for Ubuntu 18.
-Go to the top level Cinelerra directory.
+Go to the top level \CGG{} directory.
Key in: \qquad \texttt{prof2}
Key in: \qquad \texttt{make clean all install}
-Later, if you wanttitle to remove this from the system,
+Because \textit{smap} may have to be found in the system if \textit{How to use} below does not work, you will have to do the following:
+\newline
+\newline
+Key in: \qquad \texttt{cp -a smap /usr/local/bin}
+
-key in: \qquad \texttt{make uninstall}
+Later, if you want to remove this from the system,
+
+Key in: \qquad \texttt{make uninstall}
\subsection{How to use}
\label{sub:how_to_use}
\hspace{2em}\texttt{prof -o /tmp/prof\_list.txt ./cin}
-where \texttt{/tmp/prof\_list.txt} is the output file and in this case \texttt{cin} is the Cinelerra binary file. The pid of this command will be displayed on the startup window. This comes in handy in the use case where there is a lot of initial load and possible configuration setup inside of Cinelerra and you want to profile plugins and not necessarily all of the setup steps. Then you can use the following command in another window to continue running Cinelerra and obtain the more useful information:
+where \texttt{/tmp/prof\_list.txt} is the output file and in this case \texttt{cin} is the \CGG{} binary file. The pid of this command will be displayed on the startup window. This comes in handy in the use case where there is a lot of initial load and possible configuration setup inside of \CGG{} and you want to profile plugins and not necessarily all of the setup steps. Then you can use the following command in another window to continue running \CGG{} and obtain the more useful information:
\hspace{2em}\texttt{kill -USR1 pid}
\textbf{10.200t 0.001u+0.000s 21.566r 47.3\%}\\
\textit{--- profile end ---}
-The summary line above in Bold represents the User time, System time, Real time and the percentage is how much Timer time elapsed over Real time so in this case the measurement covers 47.3\% of time.\\
+The summary line above in Bold represents the User time, System time, Real time and the percentage is how much Timer time elapsed over Real time so in this case the measurement covers 47.3\% of time.
+
So why use a Profiler? Because it is the ``ls'' for executable functions!!
projects / goodguy / cin-manual-latex.git / blobdiff