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 and/or vaapi/vdpau
+libraries as yours.
+It is recommended for best results that you build \CGG{} on your specific computer as described in \ref{sec:single-user-build}.
+So in summary:
+\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.
export CIN_HW_DEV=vaapi
\end{lstlisting}
+In addition for a computer with dual graphics cards, you can select your specific device with an environment variable
+to decode and encode. For example:
+\begin{lstlisting}[numbers=none]
+CIN_DRM_DEC=/dev/dri/renderD129 CIN_DRM_ENC=/dev/dri/renderD128 ./cin
+\end{lstlisting}
+and substituting your specific location instead of /dev/dri/renderD129 or D128.
+
It might be more difficult to analyze problems as a result of using the GPU because of the wide variation in hardware. When you do not set the \texttt{CIN\_HW\_DEV} environment variable, the code will work exactly as before since this feature is self-contained.
There is also a \texttt{Settings $\rightarrow$ Preferences, Performance} tab, \textit{Use HW device} flag
\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}%
\item downgrade the cuda development package to a version that works for your board.
\end{enumerate}
-\subsection{Final Note}%
+\subsection{Additional topics on hardware acceleration}%
\label{sub:final_note_on_acceleration}
In wrapping up this Hardware Acceleration section, you may want to refer to the following to determine the current supported formats:
-\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}
\item For large media files, use proxy to do your main editing.
\item In \texttt{Settings $\rightarrow$ Preferences, Appearance} tab, uncheck \textit{Use thumbnails in resource window}.
\item In \texttt{Settings $\rightarrow$ Preferences, Appearance} tab, uncheck \textit{Autocolor assets}.
- \item Speed-up certain time-consuming FFmpeg plugins through use of a carefully selected \texttt{.opts} file.
+ \item Speed-up certain time-consuming FFmpeg plugins through use of a carefully selected \texttt{.opts} file. See \nameref{sub:speedup_ffmpeg_plugin_opts}
\item For large media files, in \texttt{Settings $\rightarrow$ Preferences, Playback A}, Video Driver set \textit{use direct X11 render if possible}.
\item For the Video Driver in \texttt{Settings $\rightarrow$ Preferences, Playback A}, if using a good graphics card, choose \textit{X11-OpenGL}.
\item Set \textit{CIN\_HW\_DEV=vdpau} or \textit{vaapi} to use the graphics GPU for certain ffmpeg media decoding.
\begin{description}
\item[F\_lut:] Compute and apply a lookup table to the RGB/YUV input video.
- \item[F\_lut1d:] Adjust colors using a 1D LUT.
- \item[F\_lut3d:] Apply a 3D LUT to an input video.
+ \item[F\_lut1d:] Adjust colors using a 1D LUT "file" input.
+ \item[F\_lut3d:] Apply a 3D LUT "file" to an input video.
\item[F\_lutrgb:] Compute and apply a lookup table to the RGB input video.
\item[F\_lutyuv:] Compute and apply a lookup table to the YUV input video.
\end{description}
-For example, to use a 3dlut simply load your video, drop the F\_lut3d plugin on that track, and bring up the lut3d controls window, highlight the \textit{file} option, key in your file name (whit path), and hit apply to have the lut take effect. To easily adjust, move the \textit{fader} slider in the patchbay for that video track.
+For example, to use a 3dlut simply load your video, drop the F\_lut3d plugin on that track, and bring up the lut3d controls window, highlight the \textit{file} option, key in your file name (with path), and hit Apply to have the lut take effect. To easily adjust, move the \textit{fader} slider in the patchbay for that video track. Only F\_lut1d and F\_lut3d allow for a file input and these usually are files with the .cube extension.
\subsection{Encoding into Dolby Pro Logic}%
\label{sub:encoding_dolby_pro_logic}
\begin{description}
\item[Line Doubling:] done by the \textit{Deinterlace} effect when set to \textit{Odd} lines or \textit{Even} lines. When applied to a track it reduces the vertical resolution by $\frac{1}{2}$ and gives you progressive frames with stairstepping. This is only useful when followed by a scale effect which reduces the image to half its size.
\item[Line averaging:] the \textit{Deinterlace} effect when set to \textit{Average even} lines or \textit{Average odd} lines does exactly what line doubling does except instead of making straight copies of the lines, it makes averages of the lines. This is actually useful for all scaling.
- \item[Inverse Telecine:] this is the most effective deinterlacing tool when the footage is an NTSC TV broadcast of a film. It is described in Effect Plugins (\ref{sub:inverse_telecine}), chapter 10.
+ \item[Inverse Telecine:] this is the most effective deinterlacing tool when the footage is an NTSC TV broadcast of a film. It is described in Effect Plugins (\ref{sub:inverse_telecine}).
\item[Time base correction:] the previously discussed three tools either destroy footage irreversibly or do not work at times. Time base correction may be a better tool to use because it leaves the footage intact. It does not reduce resolution, perceptually at least, and does not cause jittery timing.
- \item[Frames to Fields effect:] converts each frame to two frames, so it must be used on a timeline whose project frame rate is twice the footage's frame rate. In the first frame it puts a line-averaged copy of the even lines. In the second frame it puts a line-averaged copy of the odd lines. When played back at full framerate it gives the illusion of progressive video with no loss of detail. This effect can be reversed with the \textit{Fields to Frames} effect, which combines two frames of footage back into the one original interlaced frame at half the framerate. However, keep in mind that Frames to Fields inputs frames at half the framerate as the project. Effects before Frames to Fields process at the reduced framerate. The output of Frames to Fields can not be compressed as efficiently as the original because it introduces vertical twitter and a super high framerate. Interlaced $29.97$ fps footage can be made to look like film by applying Frames to Fields and then reducing the project frame rate of the resulting $59.94$ fps footage to $23.97$ fps. This produces no timing jitter and the occasional odd field gives the illusion of more detail than there would be if you just line averaged the original. It is described in Effect Plugins (\ref{sub:frames_to_fields}), chapter 10.
+ \item[Frames to Fields effect:] converts each frame to two frames, so it must be used on a timeline whose project frame rate is twice the footage's frame rate. In the first frame it puts a line-averaged copy of the even lines. In the second frame it puts a line-averaged copy of the odd lines. When played back at full framerate it gives the illusion of progressive video with no loss of detail. This effect can be reversed with the \textit{Fields to Frames} effect, which combines two frames of footage back into the one original interlaced frame at half the framerate. However, keep in mind that Frames to Fields inputs frames at half the framerate as the project. Effects before Frames to Fields process at the reduced framerate. The output of Frames to Fields can not be compressed as efficiently as the original because it introduces vertical twitter and a super high framerate. Interlaced $29.97$ fps footage can be made to look like film by applying Frames to Fields and then reducing the project frame rate of the resulting $59.94$ fps footage to $23.97$ fps. This produces no timing jitter and the occasional odd field gives the illusion of more detail than there would be if you just line averaged the original. It is described in Effect Plugins (\ref{sub:frames_to_fields}).
\item[HDTV exceptions:] $1920\times1080$ HDTV is encoded in a special way. If it is a broadcast of original HDTV film, an inverse telecine works. But if it is a rebroadcast of a $720\times480$ source, you need to use a time base and line doubling algorithm to deinterlace it.
\end{description}
the original media, you can alleviate the lag between the Audio and Video by disabling
\textit{Play every frame} in \texttt{Settings $\rightarrow$ Preferences, Playback A} tab. Now frames
will be skipped in order to keep the audio/video in synch.
+
+\subsection{How to remove letterbox/pillarbox bands}%
+\label{sub:remove_letterbox}
+
+To remove the horizontal black bands of the letterbox or the vertical
+black bands of the pillarbox we need to change the \textit{size} and
+\textit{aspect ratio} of the source by cropping.
+For example, if we want to remove the letterbox from a $4:3$ frame to
+leave only the content with aspect ratio $3:2$, We have to change the
+project format by doing the following steps:
+
+\begin{enumerate}
+ \item Check the size of the base W of the original frame in pixels:
+
+ \texttt{Resource} window $\rightarrow$ \texttt{RMB} on Asset
+$\rightarrow$ \texttt{Info} $\rightarrow$ \texttt{Detail}; e.g. W =
+768 px
+ \item Obtain the height of the figure in $3:2$, i.e., without the
+black bands; H can be obtained from the formula:
+
+ $\frac{3}{2} = \frac{W}{H}$ \quad from which $H = \frac{768 \times
+2}{3}$ \qquad e.g., H = 512 px
+ \item Note that $W \times H = 768 \times 512$ is just the crop we
+are looking for to switch from $4:3$ frame to $3:2$ frame without
+letterbox.
+ \item Open \textit{Set Format} window: \texttt{Settings
+$\rightarrow$ Format}
+ \item Change $H = 512$ and set \textit{Display Aspect Ratio} to
+$3:2$; press \texttt{Apply} and \texttt{OK}. Note that we leave W
+unchanged, since the frame width does not change.
+ \item If needed, use the \textit{Camera} tool to get the
+desired viewport.
+\end{enumerate}
+
+\paragraph{Note:} in complex situations, with multiple sources of
+different sizes, it may be appropriate to perform an additional
+step first: change the size of the track on the Timeline via
+\texttt{RMB $\rightarrow$ Resize track}.
+In this way we crop the track to match it to the project format that
+we will change in the next step. Thus we avoid possible unwanted
+distortions.
+
+In the case of the pillarbox, we will leave H unchanged while
+calculating the new value of W. The formula $\frac{x}{y} =
+\frac{W}{H}$ is valid for any aspect ratio ($4:3; 16:9; 2.35:1$; etc).
+
projects / goodguy / cin-manual-latex.git / blobdiff