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.
\section{Hardware video acceleration}%
\label{sec:hardware_video_acceleration}
+\index{hardware!acceleration}
With certain newer, more powerful graphics boards and newer device drivers, there is the potential for enhanced \textit{decode} and \textit{encode} performance. Decode refers to loading and playing video in \CGG{}. The GPU, Graphics Processing Unit, on the graphics board is accessed via one of the following libraries: vdpau or vaapi. The hardware acceleration done by the graphics card increases performance by activating certain functions in connection with a few of the FFmpeg decoders. This use makes it possible for the graphics card to decode video, thus offloading the CPU. Decode operations are described here next.
Encode refers to rendering video and is described at the end of this section
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.
-Currently only the most common codecs, such as MPEG-1, MPEG-2, MPEG-4, and H.264 /MPEG-4, 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.
+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.
\subsection{GPU hardware decoding}%
\label{sub:gpu_hardware_decoding}
+\index{hardware!decoding}
\begin{enumerate}
\item Verify that you have installed \textit{libva-dev} or \textit{libva} on your operating system.
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}
-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}%
\subsubsection*{Special .opts file}%
\label{ssub:special_opts_file}
+\index{hardware!special opts files}
The situation may arise where you have enabled hardware acceleration and after loading several files for a project, you find that a file had some kind of error resulting in a black video instead of an image or you see an error message pop up which states something like \textit{Error retrieving data from GPU to CPU} or \textit{err: Unknown error occurred}. Because the \texttt{CIN\_HW\_DEV} environment variable is either all or none, ordinarily in order to correct the non-working video you would have to turn off hardware acceleration for the entire project/session. However, there is a way to continue working on your project without having to reload all of your files. You still use the environment variable and it will be effective for all of the formats it is able to handle, but you make an exception for any of the files that erred out. To do this you simply create a file in the same directory with the same name as the erring file with the different extension of .opts. The contents of this .opts file would just be the one line of:
HEVC with NVIDIA, VDPAU driver is buggy, skipping
\end{lstlisting}
-If you would like to see more information on what is occurring, you can 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{}. Then you will see messages in the startup window like:
+AppImage does not provide this capability. If you would like to see more information on what is occurring, you can 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{}. Then you will see messages in the startup window like:
\begin{lstlisting}[numbers=none]
[AVHWDeviceContext @ 0x7fc9540be940] Successfully created a VDPAU device
\subsection{GPU hardware encoding}%
\label{sub:gpu_hardware_encoding}
+\index{hardware!encoding}
Encoding using hardware acceleration of your graphics board GPU is
included in \CGG{} but it is of limited availability and works only
\subsubsection*{Broadcom, Intel HD, AMD}%
\label{ssub:broadcom_intel_amd}
+\index{hardware!vaapi}
To use hardware acceleration for rendering (that is, encoding) you do not have to set a preference or an environment variable, as was required for decoding. To use this feature you use an ffmpeg render options file which specifies a vaapi codec, such as h264\_vaapi. You must include this line in that options file to trigger the hardware probe: \qquad \texttt{CIN\_HW\_DEV=vaapi}
\end{description}
Other option files can be added as needed for your specific hardware if it is known to work for you, such as VP8 and VP9. An example of the included \CGG{}’s \texttt{ffmpeg/video/h264\_vaapi.mp4} file (figure~\ref{fig:render-vaapi}):
+\begin{figure}[htpb]
+ \centering
+ \includegraphics[width=1.0\linewidth]{render-vaapi.png}
+ \caption{Render menu setup to encode using GPU with vaapi}
+ \label{fig:render-vaapi}
+\end{figure}
\begin{lstlisting}[numbers=none]
mp4 h264_vaapi
profile=high
\end{lstlisting}
-\begin{figure}[htpb]
- \centering
- \includegraphics[width=0.7\linewidth]{render-vaapi.png}
- \caption{Render menu setup to encode using GPU with vaapi}
- \label{fig:render-vaapi}
-\end{figure}
-
According to an online wiki, hardware encoders usually create output of lower quality than some software encoders like x264, but are much faster and use less CPU. Keep this in mind as you might want to set a higher bitrate to get output of similar visual quality.
Results of a particular test case performed on a Intel, 4-core computer, with Broadwell Graphics using an mp4 input video/audio file with dimensions of
\subsubsection*{Nvidia graphics boards}%
\label{ssub:nvidia_graphics_card}
+\index{hardware!nvenc}
To use hardware acceleration for rendering (that is, encoding) you do not have to set a preference or an environment variable, as was required for decoding. To use this feature you use an ffmpeg render options file which specifies the nvenc codec, either \texttt{h264\_nvenc.mp4} or \texttt{nvenc.mp4}. There are several requirements in order for this to work on your computer as listed here:
\subsection{Effects (OpenCL, Cuda)}%
\label{sub:effects_opencl_cuda}
+\index{openCL}
+\index{CUDA}
CUDA® is a parallel computing platform / programming model developed by Nvidia that provides big increases in computing performance through use of the GPU. It was first introduced in about 2006 for applications in computationally intense fields such as astronomy, biology, chemistry, and physics.
\begin{lstlisting}[numbers=none]
env CUDA_PATH=/opt/cuda
-#OR if using the bash shell:
+OR if using the bash shell:
export CUDA_PATH=/opt/cuda
\end{lstlisting}
For all distros you will need to add to the ./configure line in your build script, the following:
\begin{lstlisting}[numbers=none]
--with-cuda
-#so your configure line will look something like this:
+so your configure line will look something like this:
./configure --with-single-user --with-booby --with-cuda
\end{lstlisting}
\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{Optimized Playback -- X11 Direct}%
\label{sec:optimized_playback}
+\index{playback -X11 direct}
Normally, when \CGG{} reads a video frame, it is copied into a \textit{Vframe}. This frame may also need other actions performed on it, such as a color model change. In addition, ffmpeg and libzmpeg \textit{can\_scale\_input}. So the read can be color transformed and scaled just by asking the library to do that. This means that if the compositor is in a \textit{good} state with no zoom, the VFrame read can be done in the fastest render color model, and already scaled to the correct size for the compositor. In reality, this is not what you need for editing, but quite often the \textit{virtualconsole} is not used because the render is media only -- that is \textit{just data}. If no data transforms are needed and the input scaling can be done, the vrender program detects this, and tells the codec to transmit the data in a compatible way to the compositor canvas. This is the \textit{X11 direct} data path.
\section{Proxy Settings and Transcode}%
\label{sec:proxy_settings}
-Working with videos that have large image geometry can greatly impede editing. Instead you can substitute \textit{proxies} which will create smaller video image files from the original file that can then be edited more quickly. When you are done working on this smaller scale, you will need to bring up the Proxy settings menu again, and change the Scale factor back to the Original size so that all of your edits/work take affect on that original higher quality video on the timeline.
-
-To use this feature, select \texttt{Settings $\rightarrow$ Proxy settings} and change the Scale factor from Original size to your downsized choice. You can choose ffmpeg as the File Format and a choice of various codecs associated with that. A good choice is the default of mpeg which can usually be quite fast. In addition, to modify values for that codec, click on the wrench icon. When you have completed your choices, just click OK, and then the video tracks will be rendered. This may take some time, but previous proxy renders will be reused.
-The proxy videos will be added to your assets in a separate Proxy folder, and the video track edits will use the proxies.
-The assets in both the Media folder and Proxy folder will look proxied when dragged to the Viewer although the scale may be different.
-Proxy downsizing renders all loaded tracks, but only work on the $1^{st}$ video layer of any multi-layer media. Rendered proxy media is saved in the same directory as the original media.
-However, if you proxy your session, the clips do not get proxied to the Proxy folder, but if you Drag and Drop the clip from the Clip folder to the Viewer or the Timeline, you will see that it too is proxied.
-As usual, you can delete proxy files from the project or disk in the Resources window if you no longer want to retain them.
-And you can save your project either as proxied or not.
-
-You can also nest clips while in a proxied state, but you can not drag the proxied nested clips
-to the viewer or the timeline.
-If you create proxies for Nested clips they will be saved in \texttt{\$HOME/Videos} unless you modify that in
-\texttt{Settings $\rightarrow$ Preferences, Interface} tab, \textit{Nested Proxy Path}.
-
-There are two ways that the proxy files can be used, with or without input scaling. When the proxy is done without rescaling, the Mask, Camera and Projector automations are re-scaled accordingly. In this situation, the entire project will be re-sized so that the session is in the resized geometry. Not all plugins are useful when the project is rescaled, because the keyframe data must be in the original geometry. In this case, you can use the rescaler, by enabling \textit{Use scaler (FFMPEG only)}. This has the added advantage that the project size does not change and the proxy media is down-scaled as usual and up-scaled on read-in, which means the project editing is done in full scale. Since decoding is done on smaller video, there is a time savings, but all rendering is done full scale. The main reason for using \textit{scaler} is that it does not change the image coordinate data, so that automation and plugin parameters will be in the original project geometry. This is not as fast as the first option, but is a performance gain, and may be needed if you are using plugins that need coordinate data such as the Title plugin. As noted, the scaler only works on ffmpeg video formats.
-
-In the upper right hand corner of the main window, there is a toggle button to easily switch back and forth when you have a proxied file on the timeline. The icon is to the left of the FF icon. It will have the letter “P” as the icon for Proxy or if \textit{Using Scaler}, the letter “S”. \quad \includegraphics[height=\baselineskip]{proxy-01.png} \quad This quick switch is especially useful when editing and you need to see a better image temporarily.
-
-Screencast in figure~\ref{fig:proxy-02} shows the Use scaler checked so you can still use plugins and the original project size is kept. The Scale factor pull-down gives you available size options. Note the new media dimensions shown (partially covered). If the size is an odd number, 1 is added to make the dimensions both even numbers.
-
-In the case of the scaler checkbox, it will retain that setting for ease of use.
-
-\begin{figure}[htpb]
- \centering
- \includegraphics[width=0.6\linewidth]{proxy-02.png}
- \caption{Proxy settings dialog}
- \label{fig:proxy-02}
-\end{figure}
-
-There is also a convenient \textit{Beep on done volume} dial included so that you can work on other tasks until there is an audible notify of completion. The default volume is set to 0 for no audible notify.
-
-A good choice for proxy settings with 1080p source video is:
+Information on proxies to reduce required CPU for less powerful computers is in the section \nameref{sec:proxy}.
-\begin{lstlisting}[numbers=none]
-Scale Factor: 1/4
-Use Scaler: unchecked
-File Format: FFMPEG - mpeg
-Video Preset:
-Compression: mpeg.mpeg
-Bitrate: 1800000
-Quality: -1
-Pixels: yuv420p
-\end{lstlisting}
-
-If you get errors for some videos, such as those with strange variable bit rate or some types of files made on a smartphone, a usually reliable alternative is to change the following parameters:
-
-\begin{lstlisting}[numbers=none]
-File Format: FFMPEG - mov
-Video Preset:
-Compression: mov.mov
-\end{lstlisting}
-
-Or if you want small files with high image quality, a File Format of m2ts is optimal. For example a 1 GB file can be reduced to 50 MB with scale $\frac{1}{2}$.
-
-Checking the \textit{Auto proxy/scale media loads} results in any additional media loads to be automatically proxy scaled. However, single frame media such as PNG or JPEG \textit{stills}, can not be scaled to \textit{stream} media. If this type of media exists, you should \textit{use scaler}.
-
-If you get error messages when creating proxies, check the Video wrench settings. These usually default to values that are expected to work correctly for the \textit{File Format} and codec you selected but they can be changed and may result in errors. If you get an error message of \textit{check\_frame\_rate failed} followed by \textit{Error making proxy} in the popup Errors window, do just that and check the Frame rate value by going to the Resources window, Media folder, and use the right mouse button for the Info option for that specific media in question. You can change the frame rate in this window to a more codec acceptable value. Different codecs may have different legal values.
+Information on transcode which is used to provide keyframes to make the video seekable is in the section \nameref{sec:transcode}.
-More specific information on which plugins need to use scaler is provided here next. If the keyframe data uses coordinate data that is absolute, then the scaler should be used. If the data is normalized (like always $0-100\%$) then the proxy can be done without the scaler. The session geometry format, shown in \texttt{Settings $\rightarrow$ Format} as $width \times height$, is changed if the scaler is not used to cause all of the data to be in the reduced format. If this affects the plugin operation, then scaler should be used. Examples of plugins that need the scaler are: Title, AutoScale, Scale, ScaleRatio, and Translate. Most others are safe to use without scaling.
- This makes its so that you can save your project
-either as proxied or not.
-\textbf{Transcode}, an option under the Settings pulldown right next to the Proxy settings option, is a type of full resolution \textbf{1:1 Proxy}.
-The process of transcoding works directly from the resource; it is independent of the timeline.
-All of the loaded asset media will be converted, that is, rendered in the selected format and loaded onto the timeline.
-Menu choices besides the usual File Format and File Type include: \textit{Tag suffix} (to add to media filename), \textit{Remove originals from project}, \textit{Into Nested Proxy directory} (an option to have the file saved here instead of the location of the original media), and \textit{Beep on done} volume.
+\section{Cache size and Seconds to preroll render}%
+\label{sec:cache_and_preroll}
+\index{cache}
-The settings of the project have an effect, for example the dimensions are taken into account. The resulting files are also larger than if they were created directly with ffmpeg.
-Transcode works for videos with or without audio and even single frame files, like png's.
-If you have a video file that also contains audio, and you convert only the video, the original audio will stay on the timeline if do not check \textit{Remove originals from project}. Or vice versa if audio converted and not video.
-Multiple stream media will only transcode the first stream (this would be like the TV channel recordings in the United States).
-You will get an error message if you already have a transcoded file in the selected format with the same suffix name and try to transcode it again with a different selection made -- you will have to delete that file first. An example would be
-an already converted file that has both video and audio and now you request video only.
+\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.
-The BIGGEST gain from using this is if you have media that is not \textit{seekable}, that is, you can play it from the beginning but can not move to another spot and have the audio or video play correctly. A video file with no keyframes makes seeking next to impossible, but then a Transcode generally adds these keyframes.
-
-\section{Some Settings Parameter Values}%
-\label{sec:settings_parameter_values}
-
-\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.
-
-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.
\section{General Crash Handling Tips}%
\label{sec:general_crash_tips}
+\index{crash handling tips}
This section is a handy guide for describing various kinds of software computer system failures. Only some of these various lockups or crashes can be dealt with. Hopefully, it will help to have some hints to know what kind of failure it is, or to save your work or to avoid future problems. For most of this, your user name must be root, although you can certainly try to see if it works for you when not root.
To create a specific 440 Hz tone, follow these steps. You can vary the length, use more channels, or change the frequency to a different desired value (figure~\ref{fig:aeval}).
+\begin{figure}[htpb]
+ \centering
+ \includegraphics[width=1.0\linewidth]{aeval.png}
+ \caption{Use Audio$\rightarrow$Render effect to set render parameter values and then that effect can be varied.}
+ \label{fig:aeval}
+\end{figure}
+
\begin{enumerate}
\item Make sure there is an armed audio track on the timeline, get into Cut and Paste mode, and highlight
a selection or define In/Out points where you want to insert the audio tone.
that to 1C|2C instead of the usual default of 1C.
\end{enumerate}
-\begin{figure}[htpb]
- \centering
- \includegraphics[width=1.0\linewidth]{aeval.png}
- \caption{Use Audio$\rightarrow$Render effect to set render parameter values and then that effect can be varied.}
- \label{fig:aeval}
-\end{figure}
-
\subsection{Camera supplied LUTs}%
\label{sub:camera_supplied_luts}
+\index{LUT}
A LUT, acronym for Look-Up Table, is a mathematically precise way of taking specific RGB image values from a source image and modifying them to new RGB values by changing the hue, saturation and brightness values of that source image. In other words, LUTs are used to map one color space to another. Some high-end cameras supply a .cube file to use as input. There are several different ffmpeg plugins included with CinGG for using Lut's. These are:
\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}
+\index{dolby pro logic}
Dolby pro logic is an easy way to output 6 channel audio from a 2-channel soundcard with degraded but useful results. Rudimentary Dolby pro logic encoding can be achieved with usage of some effects.
\subsection{Remove Interlacing}%
\label{sub:remove_interlacing}
+\index{interlacing}
Interlacing often exists on older video sources, such as camcorders, and was previously used in broadcast television. Playing this video results in jagged images on a computer monitor, but with \CGG{} you can use deinterlacing effects to solve this. After some experimentation, it has been determined that the FFmpeg \textit{F\_kerndeint} plugin seems to produce the best results with the least amount of fiddling. But some of the parameters described next are pertinent to other potential plugin usage.
\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}
\subsection{Time stretching audio}%
\label{sub:time_stretching_audio}
+\index{audio!time stretching}
It may appear that time stretching audio is a matter of selecting a region of the audio tracks, enabling recording for the desired tracks, going to\texttt{ Audio $\rightarrow$ Render Effect}, and applying \textit{TimeStretch}. In actuality there are 3 audio effects for time stretching: Time Stretch, Resample, and Asset info dialog.
You can see that the camera smoothly flows from keyframe point to next keyframe point, as \CGG{} automatically adjusts the camera movement in straight lines from point to point.
+\subsection{Video lagging behind Audio}%
+\label{sub:video_lagging}
+
+When there is a lag between the Audio and the Video, it can be because there are a lot of video frames
+and the computer can not display them as fast as the Audio can play the samples. However, this does
+not affect the rendered media in that the Audio and Video will be correctly synchronized. When playing
+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