Some computer hardware factors to consider for better performance are listed here:
\begin{itemize}
- \item Multi-core and more SMP processors greatly improve \CGG{} speed by making use of threads.
- \item A large amount of free memory available can help speed up operations by avoiding unnecessary disk
- swaps and keeping videos easily accessible in memory.
+ \item Multi-core and more SMP processors greatly improve speed by making use of threads. \CGG{} automatically uses the available threads, but some processes are single-threaded anyway and these become the weak link in the chain. The \textit{Project SMP cpus} parameter is used to limit the use of threads in the deconding (playback) stage only. It is better to lower the number of threads to leave some for the system and for the plugins in use.
+ \item RAM: In video editing in general, the more RAM the better. A large amount of free memory available can help speed up operations by avoiding unnecessary disk swaps and keeping videos easily accessible in memory.
+You can optimize RAM utilization with \textit{Cache size} and \textit{Seconds to preroll render} parameters. See section \ref{sec:cache_and_preroll}. If there is limited RAM you must necessarily have a large swap partition. For system swap, (2 x RAM) GB seems to be more than sufficient. If the amount of memory being used by the program is close, then swap might save you but often if swapping becomes necessary, it presents more problems and you end up killing the \CGG{} process anyway.
\item Video editing is almost always I/O intensive. To create longer running videos at high resolution
- you will want to have a lot of disk space available on fast access disks.
+ you will want to have a lot of disk space available on fast access disks. The higher the transfer rate, the less slowdowns and problems. So a modern SSD is better than an old HDD.
\item \CGG{} benefits from OpenGL hardware acceleration. A good graphics card is worthwhile to have.
\item Multiple monitors really come in handy to increase productivity as you can see more information and
in bigger windows so you do not have to keep moving windows around.
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.
\subsubsection*{Hardware decoding in \CGG{}}%
\label{ssub:hardware_decoding_cinelerra}
-
+\index{appimage!vaapi/vdpau}
There are 4 phases during \CGG{}’s handling of hardware acceleration. These first 2 steps occur just \textit{before} the first read.
\begin{enumerate}
can not convert the data, you will see the error message of \textit{Error retrieving data from GPU to CPU}.
\end{enumerate}
-AppImage does not provide this capability. Due to variations in user’s computer hardware configuration, it is often suggested that you refer to your startup window to check for error messages. Since your situation is unique, the error may not have been seen by anyone else and is probably unknown/undocumented.
+AppImage will probably not allow for either VDPAU or VA-API hardware acceler-
+ation because the 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. See \nameref{sub:built_appimage_scratch}.
+ \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}
+
+Due to these variations in user’s computer hardware configuration, it is often suggested that you refer to your startup window to check for error messages. Since your situation is unique, the error may not have been seen by anyone else and is probably unknown/undocumented.
\textcolor{red}{For debugging problems, modify in the \CGG{} ffmpeg subdirectory, the file: \texttt{decode.opts} by temporarily changing the line from \textit{loglevel =fatal} to \textit{loglevel =verbose} and restarting \CGG{}}.
\subsubsection*{Possible improvements or differences}%
-\section{Some Settings Parameter Values}%
-\label{sec:settings_parameter_values}
+\section{Cache size and Seconds to preroll render}%
+\label{sec:cache_and_preroll}
\index{cache}
-\texttt{Cache} in \texttt{Settings $\rightarrow$ Preferences, Performance} tab is used to store images on the timeline. One 1080p frame uses about 10 MB. The default setting is 256 and this is enough for testing and running. However, why not use more memory if it is available. To experiment for testing a good number tuned to the way you use your computer, set the cache to 0, start up \CGG{}, load a typical media file, play it and run \texttt{top} on the command line in another window to see how much memory is being used. In the \textit{top} display, look at \textit{free} memory. Whatever your computer is not using, is a good number to use for cache. If you start other programs, or change the design of the session so that it uses a lot of frame storage, you may need to experiment again later and resize accordingly.
+\textit{Cache size} in \texttt{Settings $\rightarrow$ Preferences, Performance} tab is used to store images on the timeline. One 1080p frame uses about 10 MB. The default setting is 256 and this is enough for testing and running. However, why not use more memory if it is available. To experiment for testing a good number tuned to the way you use your computer, set the cache to 0, start up \CGG{}, load a typical media file, play it and run \textit{top} on the command line in another window to see how much memory is being used. In the \textit{top} display, look at \textit{free} memory. Whatever your computer is not using, is a good number to use for cache. If you start other programs, or change the design of the session so that it uses a lot of frame storage, you may need to experiment again later and resize accordingly. The system keeps all requested data cached until it is replaced by other data or you reboot your PC. Reboot if you want to clear the cache.
-For system \textit{swap}, 1 GB seems to be more than sufficient. If the amount of memory being used by the program is \textit{close}, then swap might save you but often if swapping becomes necessary, it presents more problems and you end up killing the \CGG{} process anyway.
+\textit{Seconds to preroll render} in \texttt{Settings $\rightarrow$ Preferences, Performance} tab are used to increase the amount of frames (which are calculated in advance) at the time of their use. The default setting is 0.5 sec but you can increase it to 1.0 sec to improve smoothness in the timeline. Higher values are always less effective.
\section{Tips for Improving Smaller Computers Use}%
\label{sec:tips_improving_smaller_computers}
projects / goodguy / cin-manual-latex.git / blobdiff