\label{fig:settings}
\end{figure}
+\section{.bcast5}%
+\label{sec:bcast5}
+\index{bcast5}
+
The user's default settings, preferences, and other helpful files are retained across sessions in a hidden file, called \texttt{.bcast5}, in the user’s \texttt{\$HOME} directory. Initially when \CGG{} is launched there is an empty project and there are program default settings, and from then on the \texttt{.bcast5} directory will contain the settings that were set when quitting. If you need to revert to the default settings, delete the \texttt{.bcast5} directory contents and restart \CGG{}. Or you may want to rename it temporarily if you think you might want it back later.
Although the location defaults to \texttt{\$HOME/.bcast5}, you can use the \texttt{CIN\_CONFIG} variable to override this location. For example: \texttt{export CIN\_CONFIG=/tmp/.bcast5} will use a temporary setup for testing purposes. It is also useful for multiple users sharing the same home directory who would like to have different configuration/preferences settings data. And if you are experiencing inexplicable errors or crashes in \CGG{}, they may be due to a problem with \texttt{.bcast5} in which case taking it out of the picture can at least eliminate this as the cause. Another use case is if we want multiple installations of \CGG{}, for example one stable and one experimental, we can create the \texttt{.bcastX} folder externally and then set it as default with the option \textit{Index files go here} in \nameref{sub:index_file_section}.
-Several ways exist to change \CGG{}’s operational characteristics. A lot of variations can be made to settings and preferences by using the \textit{Settings} pulldown from the main window and choosing \textit{Preferences}.
+Several ways exist to change \CGG{}’s operational characteristics. A lot of variations can be made to settings and preferences by using the \textit{Settings} pulldown from the main window and choosing \textit{Preferences}.
+
+In addition, there are currently 2 settings that can only be manually changed in your \$Home/.bcast5/Cinelerra\_rc file and then done so by very careful editing. These include FAST\_SPEED and SLOW\_SPEED which allow you to modify the default 2X speed of \textit{Fast forwward} and the .5X speed of the \#2 keypad for \textit{Slow speed forward play}.
+For example, adding the 2 lines FAST\_SPEED 4 and SLOW\_SPEED .2 to the end of the Cinelerra\_rc wile will result in playing at 4X faster and 5X slower.
\section{Playback A / Playback B}%
\label{sec:playback_a_b}
\item[White balance CR2 images] this enables white balancing for CR2 images if interpolation is also enabled. This is because proper white balancing needs a blending of all 3 primary colors. White balance uses the camera's matrix which is contained in the CR2 file. Disabling white balancing is useful for operations involving dark frame subtraction. The dark frame and the long exposure need to have the same color matrix. If you disable Interpolate CR2 Images and use the Interpolate Pixels effect, be aware the Interpolate Pixels effect always does both interpolation and white balancing using the camera's matrix, regardless of the settings in Preferences. Dark frame subtraction needs to be performed before Interpolate Pixels.
\item[Video driver] \index{video!driver} normally video on the timeline goes to the compositor window during both continuous playback and when the insertion point is repositioned. Instead of sending video to the Compositor window, the video driver can be set to send video to another output device during continuous playback. However, this does not affect where video is routed when the insertion point is repositioned. Options are listed next.
\begin{description}
- \item[\textit{X11}] this was the first method of graphical display on Unix systems. It just writes the RGB triplet for each pixel directly to the window. It is useful when graphics hardware can not handle very large frames. And when X11 is usled with the associated checkbox enabled of \textit{use direct x11 render if possible} it can be a really good playback method to speed up playback for large frames.
+ \item[\textit{X11}] this was the first method of graphical display on Unix systems. It just writes the RGB triplet for each pixel directly to the window. It is useful when graphics hardware can not handle very large frames. And when X11 is used with the associated checkbox enabled of \textit{use direct x11 render if possible} it can be a really good playback method to speed up playback for large frames.
\item[\textit{X11-XV}] this was an enhancement to X11 in 1999. It converts YUV to RGB in hardware with scaling. In some cases it may be the preferred playback method, but it can not handle large frame sizes. Maximum video size for XV is usually $1920\times1080$.
\item[\textit{X11-OpenGL}] the most powerful video playback method is OpenGL. With this driver, most effects are done in hardware with the graphics board installed in the computer. OpenGL allows video sizes up to the maximum texture size, which is usually larger than what XV supports, depending on the graphics driver. OpenGL relies on PBuffers and shaders to do video rendering. Plugins or transitions that do not have \textit{handle OpenGL} in the code will use software instead of hardware and this will slow down playback.
OpenGL does not affect rendering. It just accelerates playback. X11-OpenGL processes everything in 8 bit color models, although the difference between YUV and RGB is retained. The scaling equation set in the preferences window is ignored by OpenGL -- it always uses linear scaling. Camera and projector operations use OpenGL, but some of the effects may not support OpenGL acceleration.
\subsection{Performance section}%
\label{sub:performance_section}
-The main focus of the performance section is rendering parameters not available in the rendering dialog with the obvious gain of perhaps better performance.
+The main focus of the performance section is rendering parameters not available in the rendering dialog with the obvious gain of perhaps better performance. For more details about using GPU hardware acceleration for both decoding and encoding see \nameref{sec:hardware_video_acceleration}.
\begin{description}
- \item[Cache size] \index{cache size} to speed up rendering, several assets are kept open simultaneously. This determines how many are kept open. A number too large may exhaust your memory rapidly. A number too small may result in slow playback as assets need to be reopened more frequently.
+ \item[Cache size] \index{cache size} to speed up rendering, several assets are kept open simultaneously. This determines how many are kept open. A number too large may exhaust your memory rapidly. A number too small may result in slow playback as assets need to be reopened more frequently.
+ \item[Cache Transition] transitions can be slow on timeline playback. With this parameter (active by default) a cache is used to smooth the transition. You might see a slight hesitation at the beginning of a transition when memory is being loaded then quite often it will play at full speed.
\item[Seconds to preroll renders] \index{pre-roll} some effects need a certain amount of time to settle in. Checking this option sets a number of seconds to render without writing to disk before the selected region is rendered. When using the render farm, you will sometimes need to preroll to get seamless transitions between the jobs. Every job in a render farm is prerolled by this value. This does not affect background rendering because background rendering uses a different preroll value.
\item[Force single processor use] \index{force single processor} \CGG{} tries to use all processors on the system by default, but sometimes you will only want to use one processor, like in a render farm client. This forces only one processor to be used. The operating system usually uses the second processor for disk access. The value of this parameter is used in render farm clients.
- \item[Project SMP cpus ] \index{entry}SMP cpus to restrict the number of processors utilized, change the count number. This number will be used for the plugin per load balance operation cpu limit, which uses smp-cpus to stripe your data. It does not affect the number of cpus used in any other \CGG{} operation besides plugins. On large cpu systems, it can come in handy to downgrade the number of cpus used for some plugins; otherwise it uses all of the processors and splits up the program into too many pieces which may add
- considerable overhead in high cpu count systems.
+ \item[Project SMP cpus] \index{SMP cpus} to restrict the number of processors utilized, change the count number. This number will be used for the plugin per load balance operation cpu limit, which uses smp-cpus to stripe your data. It does not affect the number of cpus used in any other \CGG{} operation besides plugins. On large cpu systems, it can come in handy to downgrade the number of cpus used for some plugins; otherwise it uses all of the processors and splits up the program into too many pieces which may add considerable overhead in high cpu count systems.
+ \item[Use HW Device] \index{HW Device} \CGG{} can use hardware timeline acceleration (decoding) via GPUs thanks to the \textit{OpenGL} video driver. By default the \textit{X11} video driver is used, which works only with the CPU. See \nameref{sub:video_out_section}. For h264, h265 (HEVC) and VP9 codecs you can use libraries specific to AMD, Nvidia and Intel graphics cards. For AMD and Intel set \textbf{vaapi}; for Nvidia set \textbf{vdpau} (also works with AMD thanks to a wrapper). \textbf{Cuda} does not accelerate decoding with Nvidia, but it does allow some plugins to run that are not available otherwise. \textbf{None} (default) uses the video driver set in the \texttt{Playback A/B} tab.
\end{description}
\subsection{Background Rendering section}%
\end{figure}
\begin{description}
- \item[Index files go here] \index{index file!path} index files exist in order to speed up drawing the audio/video tracks. This option determines where index files are placed on the disk.
+ \item[Index files go here] \index{index file!path} index files exist in order to speed up drawing the audio/video tracks. This option determines where index files are placed on the disk
\item[Size of index file] \index{index file!size} determines the size of an index file. Larger index sizes allow smaller files to be drawn faster, while slowing down the drawing of large files. Smaller index sizes allow large files to be drawn faster, while slowing down small files. The default is currently 4kB for average size files.
\item[Number of index files to keep] \index{index file!number} to keep the index directory from becoming very large, old index files are deleted. This determines the maximum number of index files to keep in the directory.
\item[build ffmpeg marker indexes] \index{ffmpeg!build index} improves ffmpeg seeks in certain cases although not clear which ones.
\begin{description}
\item[Unsafe GUI in batchrender] It serves to hide the button \textit{Save to EDL Path} present in the Batch Render window. In fact if used accidentally, it could lead to the loss of the original EDL content, which is overwritten without changing the project name. See Batch Rendering, section \nameref{sub:advanced_features}.
- \item[Autosave continuous backups] For each editing action \CGG{} creates an automatic backup. To avoid excessive creation, this option limits their number to 50.
+ \item[Autosave continuous backups] For each editing action \CGG{} creates an automatic backup. To avoid excessive creation, this option limits their number to 50 when quitting out of the program.
\end{description}
\subsection{Flags section}%
projects / goodguy / cin-manual-latex.git / blobdiff