+Let's see in detail how to set the Batch Rendering.
+
+The first thing to do when preparing to do batch rendering is to
+create one or more \CGG{} projects to be rendered and save them as a
+normal project, such as \texttt{aaa.xml}. The batch renderer
+requires a separate project file for every batch to be rendered.
+You can use the same \CGG{} project file if you are rendering to
+different output files, as in an example where you might be creating
+the same output video in different file formats.
+
+You do not have to render an entire projects. We can limit ourselves to an \textit{active region} \index{active region} that we can set through a selection in Cut and Paste mode, with labels or In/Out Points. Or the rendering will start from the Insert Point position until the end of the project. Remember: if we want to render the entire project (and not just one active region) it is important to bring the Insertion Point to the beginning of the timeline. This is the only way we are sure to include the whole project.
+
+With all the \CGG{} xml project files prepared with active regions,
+go to \texttt{File $\rightarrow$ Batch Render}. This brings up the
+batch render dialog. The interface for batch rendering is more
+complex than for single file rendering. A list of batches must be
+defined before starting a batch rendering operation. The table of
+batches appears on the bottom of the batch render dialog and is
+called \textit{Batches to render}. Above this are the configuration
+parameters for a single batch; a batch is simply a pairing of a
+project file with a choice of output file and render settings.
+
+It may be advisable to start with a \textit{Delete} so you don't have any problems. Set the \textit{Output path}, \textit{File format}, \textit{Audio},
+\textit{Video}, and \textit{Create new file at each label}
+parameters as if you were rendering a single file. These parameters
+apply to only one batch. In addition to the standard rendering
+parameters, you must select the \textit{EDL Path} to be the project
+file (such as \texttt{aaa.xml}) that will be used in the batch
+job. In this case, \textit{EDL Path} is not related in anyway with
+the EDL files as created by \texttt{File/Export EDL}. In batch
+render mode the program will not overwrite an existing output file
+and will simply fail, so make sure that no files with the same name
+as the output files exist before starting.
+
+If the batches to render list is empty or nothing is highlighted,
+click \textit{New} to create a new batch. The new batch will contain
+all the parameters you just set. Repeatedly press the \textit{New}
+button to create more batches with the same parameters. When you
+highlight any batch, you can edit the configuration on the top of
+the batch render window. The highlighted batch is always
+synchronized to the information displayed. You can easily change
+the order in which the batch jobs are rendered, by clicking and
+dragging a batch to a different position. Hit \textit{Delete} to
+permanently remove a highlighted batch. In the list box is a column
+which enables or disables the batch with an \texttt{X} meaning the
+batch job is enabled and will be run. This way batches can be
+skipped without being deleted. Click on the \textit{Enabled} column
+in the list box to enable or disable a batch.
+
+The description of each of the columns in the batch list are as
+follows:
+
+\begin{description}
+\item[Enabled:] an X in this column means the batch job will be run.
+\item[Labeled:] an \texttt{X} in this column goes hand in hand with
+ create new file at each label.
+\item[Farmed:] to use or not the render farm.
+\item[Output:] path and filename for the generated output.
+\item[EDL:] the path and filename of the source EDL for the batch
+ job.
+\item[Elapsed:] the amount of time taken to render the batch if
+ finished. If field is empty, it did not run.
+\end{description}
+
+The \texttt{File $\rightarrow$ Batch Render} pulldown brings up the
+Batch Render window to be used for batch rendering as well as DVD/BD
+creation. There are some additional buttons that can save time and
+mistakes. These are described next.
+
+\begin{description}
+ \item[Save Jobs] when you have set up the batch jobs the way you
+ want and you think you may have to run them more than once, it is
+ beneficial to save the jobs for later use so you easily run them
+ again. It is recommended to use a filename with .rc as the extension
+ so that it is obvious that it is a list of batch jobs to be run.
+ \item[Load Jobs] reload a previous set of saved jobs. This can come
+ in handy if you did not have the time to render them when you
+ originally set them up, if you need to rerun, or if you got
+ interrupted.
+\end{description}
+
+To start rendering from the first enabled batch,
+hit \textit{Start}. Once rendering, the main window shows the
+progress of the batch. After each batch finishes, the elapsed column
+in the batch list is updated and the next batch is rendered until
+all the enabled batches are finished. The currently rendering batch
+is always highlighted red. To stop rendering before the batches are
+finished without closing the batch render dialog, hit \textit{Stop}.
+To stop rendering before the batches are finished and close the
+batch render dialog, hit \textit{Close}. Or you can exit the batch
+render dialog whether or not anything is being rendered, by hitting
+\textit{Close}.
+
+You can automate \CGG{} batch renders from other programs. In the
+batch render dialog, once you have created your list of batch render
+jobs, you can click the button \textit{Save Jobs} and choose a file
+to save your batch render list to. It is recommended that you use
+a filename with the extension of .rc in order to make it obvious that
+this is a list of batch jobs to render. Once you have created this file,
+you can start up a batch render without needing to interact with the
+\CGG{} user interface. From a shell prompt, from a script, or other
+program, execute:
+
+\begin{lstlisting}[style=sh]
+{path_to_cinelerra}/cin -r batchjob.rc
+\end{lstlisting} substituting your actual filename for
+\texttt{batchjob.rc}. \textbf{Warning} this file will be modified
+so if you use any filename that is not a legitimate list of batch jobs to
+render, that file will be overwritten and its previous contents destroyed.
+When invoked with these parameters, \CGG{} will start up and run the
+rendering jobs in the list contained in that file starting at the defined
+\textit{active region}, without creating its usual windows. If you do not
+specify a filename, the default will be \$HOME/.bcast5/batchrender.rc.
+Possible messages you might see where you started up the job are as follows.
+\begin{description}
+\item[The following files exist: - filename - Won't overwrite existing files] that batch job will not run in order to prevent writing over previous run.
+\item["filename" No such file or directory] the specified batch job file does not exist.
+\item["filename": Permission denied] the specified batch job file does not have write permission so can not be updated.
+\item[Render::run: filename] the batch job with the name of filename will be processed.
+\item[** rendered 0 frames in 0.000 secs, 0.000 fps] either you used a file that is not a list of batch jobs or the batch jobs within the file were not enabled.
+\end{description}
+
+\subsection{Advanced features}%
+\label{sub:advanced_features}
+\index{batch rendering!more options}
+
+\textbf{Warning}: \textit{Save to EDL path} overwrites the current EDL thus destroying the original contents.
+
+Although the operation of Batch Rendering in \CGG{} is similar to that of other NLEs, there is one big difference that we need to take into account. The render setup is not done on a project-by-project basis, which are then brought into the Batch window to be rendered automatically. The setup must be done in the Batch rendering window, where various projects are loaded and set up. In the case of similar projects, derived from a single EDL with some variation, this mode offers the possibility of altering the projects without having to open each individual project, make the changes, set up the rendering, save and import into the Batch window. The procedure is to select the batch we want to modify in the Batches to render window; operate on the currently open timeline (even if it does not correspond to the one we want to modify) making the desired changes and then press the \textit{Save to EDL path} button. Thus the chosen batch, while retaining its original name, will now contain the modified project. Since this possibility destroys the original EDL overwriting it with the modified one, you must be very careful. This procedure is convenient in case the batches are similar, i.e. they are variations of the same EDL, where we want to experiment with other effects, other output formats or when trying out various cuts of a DVD/BD before the final production. It might also be useful to use an \textit{active region} of the timeline, so as to speed up rendering times but still have an indicative result for comparison. Instead operating on different projects, we can do a \textit{save as...} of the project on the timeline to have a new EDL with a new name and then replace it with the batch selected in the joblist using the \textit{Use Current EDL} button. The new project (with its name) overwrites the original project.
+
+The \textit{Save to EDL Path} and \textit{Use Current EDL} buttons
+can be valuable tools for advanced usage or for developers doing
+testing. Description of how you can expect them to work will help
+to illustrate how to take advantage of their capabilities (figure~\ref{fig:batch-advanced}):
+
+\begin{figure}[htpb] \centering
+ \includegraphics[width=0.7\linewidth]{batch-advanced.png}
+ \caption{New Buttons with Unsafe GUI in batchrender}
+ \label{fig:batch-advanced}
+\end{figure}
+
+
+\begin{description}
+\item[Save to EDL Path] Warning: this function overwrites the contents of the original EDL with new data, keeping the name of the original. If we don't know exactly what we're doing we may lose the original project. If you have made a change to the EDL, use
+ this button to save the changes so that they will be used in the
+ render operation. Although you can get the same results by using
+ \texttt{File $\rightarrow$ Save\dots}, this capability was initially
+ added to assist developers in testing the batch jobs needed to
+ create dvd/bluray media as it keeps the work focused in a single
+ window and retains the original job name. An example --you have
+ everything all set up with a new job in the Batch Render window
+ using \texttt{generic.xml} for the EDL path and with a job name of
+ \texttt{original\_name.xml}. Then you realize that you forgot to
+ cut out a section in the media that is not wanted in the final
+ product. You can cut that out and then \textit{Save to EDL Path} so
+ your change will be in effect for the rendering. Without this
+ button, you would be using the EDL you started with and the cut
+ would be ignored. Alternatively, if the cut changes are saved via
+ \texttt{File $\rightarrow$ Save as}\dots with a filename of
+ \texttt{new.xml} and then you use \textit{Save to EDL Path}, the
+ current highlighted job displayed in the window as
+ \texttt{original\_name.xml} will be replaced with \texttt{new.xml}.
+ However, it is important to note that the result will be saved with
+ the name \texttt{original\_name} – that is, the new content from
+ \texttt{new.xml} but with the old name of
+ \texttt{original\_name.xml}. To have this functionality we have to enable the checkbox in \texttt{Settings $\rightarrow$ Preferences $\rightarrow$ Appearance} tab; section \textit{Dangerous:} and unchecked (default) \textit{Unsafe GUI in batchrender}.
+\item[Use Current EDL] Warning: this function overwrites the contents of the original EDL with new project. If we don't know exactly what we're doing we may lose the original project. if you are working on media and still testing
+ out the results, you can take advantage of this click-box to quickly
+ get results. Basically, you change the media, save that change with
+ another name (in order to preserve the original name in case you
+ don't like the changes), and press \textit{Use Current EDL}. As an
+ example, a user creates a new job in the Batch Render window using
+ the current media, previously defined in generic.xml, with the EDL
+ path of \texttt{generic.xml}. The user then changes the media on
+ the timeline, saves the changes via \texttt{File $\rightarrow$ Save
+ as\dots} with a new name, such as \texttt{new\_name.xml}, and then
+ clicks on \textit{Use Current EDL}. In this case, the EDL path
+ listbox will be automatically updated to the \texttt{new\_name.xml}
+ and the current existing highlighted job will be replaced with the
+ \texttt{new\_name.xml} in the EDL column.
+\item[Warn if Jobs/Session mismatched] Warning: It is better to keep this function unchecked because it is only needed in case of changes on the original EDL. By default it is hidden and is shown only if we enable the checkbox in \texttt{Settings $\rightarrow$ Preferences $\rightarrow$ Appearance} tab; section \textit{Dangerous:} and checked \textit{Unsafe GUI in batchrender}. After you set up your render
+ and press Start, the program checks to see if the current EDL
+ session matches your Batch Render job. If the EDL has been changed
+ since the batch job was created, it warns you so that you have the
+ opportunity to \textit{Save to EDL} path to record those changes.
+ Otherwise, you can dismiss that warning box, disable the warning
+ message by unchecking the box and use the original values. If you
+ never want to be warned about the mismatches, leave the box
+ unchecked (figure~\ref{fig:batch02}). It is advisable to keep it unchecked because it can cause problems.
+\end{description}
+
+\begin{figure}[htpb] \centering
+ \includegraphics[width=0.9\linewidth]{batch02.png}
+ \caption{Batch render with the 4 ghosted buttons on the right side
+ + the Warning message below}
+ \label{fig:batch02}
+\end{figure}
+
+A very clear tutorial on these features can be found \href{https://linuxvideoediting.blogspot.com/2021/01/save-edl-path-use-current-edl-in-cinelerra-gg.html}{here}\protect\footnote{credit Igor Vladimirsky}; in Russian but easily translatable with DeepL or similar.
+
+\subsection{Command Line Rendering}%
+\label{sub:command_line_rendering}
+\index{rendering!command line}
+
+The command line rendering method consists of a way to load the
+current set of batch rendering jobs and process them without a
+GUI\@. This is useful if you want to do rendering on the other side
+of a low bandwidth network and you have access to a high powered
+computer located elsewhere. Setting up all the parameters for this
+operation is somewhat difficult. That is why the command line aborts
+if any output files already exist.
+
+To perform rendering from the command line, first run \CGG{} in
+graphical mode. Go to \texttt{File $\rightarrow$ Batch Render}.
+Create the batches you intend to render in the batch window and
+close the window. This automatically saves the batches in a file
+with the name of \$HOME/.bcast5/batchrender.rc. Set up the
+desired render farm attributes in \texttt{Settings $\rightarrow$
+ Preferences} and quit out of \CGG{} if you want to use the Render
+Farm capability. These settings are used the next time command line
+rendering is used to process the current set of batch jobs without a
+GUI\@. It is important to remember that the rendering will begin at
+the defined \textit{active region} saved when the project was saved.
+
+On the command line run:
+
+\begin{lstlisting}[style=sh]
+cin -r
+\end{lstlisting}
+
+\section{Background Rendering}%
+\label{sec:background_rendering}
+\index{background rendering}
+
+Background rendering causes temporary output to be rendered
+constantly while the timeline is being modified. The temporary
+output is displayed during playback whenever possible. This is
+useful for transitions and previewing effects that are too slow to
+display in real time. If a Render Farm \index{render farm} is enabled, the render farm
+is used for background rendering. This gives you the potential for
+real-time effects if enough network bandwidth and CPU nodes exist.
+
+Background rendering is enabled in the \texttt{Performance} tab of
+the \texttt{Preferences} window. It has one interactive function
+\texttt{Settings $\rightarrow$ Toggle background rendering} \index{background rendering!toggle}. This
+sets the point where background rendering starts up to the position
+of the insertion point. If any video exists, a red bar appears in
+the time ruler showing what has been background rendered
+(figure~\ref{fig:back-ren02}).
+
+\begin{figure}[htpb] \centering
+ \includegraphics[width=1.0\linewidth]{back-ren02.png}
+ \caption{Settings Background Rendering}
+ \label{fig:back-ren02}
+\end{figure}
+
+It is often useful to insert an effect or a transition and then
+select \texttt{Settings $\rightarrow$ Toggle background rendering}
+right before the effect to preview it in real time and full frame
+rates (figure~\ref{fig:back-ren}).
+
+\begin{figure}[htpb] \centering
+ \includegraphics[width=1.0\linewidth]{back-ren.png}
+ \caption{Timeline with the top red bar}
+ \label{fig:back-ren}
+\end{figure}
+
+\begin{description}
+\item[Frames per background rendering job] This only works if a
+ Render Farm is being used; otherwise, background rendering creates a
+ single job for the entire timeline. The number of frames specified
+ here is scaled to the relative CPU speed of rendering nodes and used
+ in a single render farm job. The optimum number is 10 - 30 since
+ network bandwidth is used to initialize each job.
+\item[Frames to preroll background] This is the number of frames to
+ render ahead of each background rendering job. Background rendering
+ is degraded when preroll is used since the jobs are small. When
+ using background rendering, this number is ideally 0. Some effects
+ may require 3 frames of preroll.
+\item[Output for background rendering] Background rendering
+ generates a sequence of image files in a certain directory. This
+ parameter determines the filename prefix of the image files. It
+ should be accessible to every node in the render farm by the same
+ path. Since hundreds of thousands of image files are usually
+ created, ls commands will not work in the background rendering
+ directory. The browse button for this option normally will not work
+ either, but the configuration button for this option works. The
+ default value will be /tmp/brender .
+\item[File format] The file format for background rendering has to
+ be a sequence of images. The format of the image sequences
+ determines the quality and speed of playback. JPEG generally works
+ well and is the default.
+\end{description}
+Tip: If you have rendered your whole project with \textit{File format}
+set to JPEG and there are no missing numbers in the sequence, you can
+create a video from that sequence outside of \CGG{}.
+For example, if using the default output so that your files are named
+/tmp/brender000000, /tmp/brender000001, ... in a window, you would type:
+
+\begin{lstlisting}[style=sh]
+ffmpeg -f image2 -i /tmp/brender0%5d -c:v copy brender.mov
+\end{lstlisting}
+which would create the video file brender.mov - be sure to delete
+existing brender files before creating a new sequence to ensure there
+are no missing numerical values in the sequence.
+
+\section{Render Farm Usage}%
+\label{sec:render_farm_usage}
+\index{render farm}
+
+Render Farm uses background rendering, a feature of \CGG{} where the
+video is rendered in the background, to speed up rendering
+significantly. Because rendering is memory and cpu intensive, using
+multiple computers on a network via a render farm is a significant
+gain. With \CGG{} installed on all nodes, the master node and the clients communicate via a network port that you specify.
+The Master node is the one of the instance of \CGG{} that we normally start with its gui; the other nodes are the instances of \CGG{} that we decide to start in parallel from the terminal to create the Render farm (clients).
+\CGG{} can distribute the rendering tasks over the network to the
+other computers of the Render Farm; or among all threads of a multicore CPU. The render farm software tries
+to process all of the rendering in parallel so that several
+computers can be used to render the results. The \textit{Total jobs
+to create} in the setup or labels on the timeline are used to divide
+a render job into that specified number of tasks. Each background
+job is assigned a timeline segment to process and the jobs are sent
+to the various computer nodes depending upon the load balance. The
+jobs are processed by the nodes separately and written to individual
+files. You will have to put the files back together via a load with
+concatenation, or typically by using a command line tool from a
+script.
+
+\subsection{Basic Steps to Start a Render Farm}%
+\label{sub:basic_steps_start_render_farm}
+
+The following steps are just a guideline to start your render farm.
+It is assumed that you already have the master and client nodes
+communication, shared filesystem, permissions and usernames synched.
+Let's take the example of a network with 2 PCs: the master and the client. On the client we set 5 tasks; on the master we set 2 tasks.
+
+\begin{enumerate}
+\item On the master computer, use \texttt{Settings} $\rightarrow$
+ \texttt{Preferences} $\rightarrow$ \texttt{Performance} \texttt{tab}
+ to set up a Render Farm:
+ \begin{itemize}
+ \item check the \textit{Use render farm} box;
+ \item in the \textit{Hostname} box, keyin your hostname or ip
+ address such as 192.168.1.12 or \textit{localhost};
+ \item enter in a port number such as 401--405 (only a root user
+ can use privileged ports) or $10650...$ for non-root and click on \textit{Add Nodes}. To find a range of free ports to use you can look at the file \texttt{/etc/services};
+ \item you will see something like the following in the Nodes
+ listbox to the right:\newline
+ \begin{tabular}{lllc} On & Hostname & Port & Framerate
+ \\\midrule
+ X & 192.168.1.12 & 10650 & 0.0 \\
+ X & 192.168.1.12 & 10651 & 0.0 \\
+ X & 192.168.1.12 & 10652 & 0.0 \\
+ X & 192.168.1.12 & 10653 & 0.0 \\
+ X & 192.168.1.12 & 10654 & 0.0 \\
+ X & localhost & 10655 & 0.0 \\
+ X & localhost & 10656 & 0.0 \\
+ \end{tabular}
+ \item set the Total number of jobs to create. This number only pertains to client nodes, so we do not need to consider the master node;
+ \item click OK on the bottom of the Preferences window.
+ \end{itemize}
+\item For external network nodes, now we must join the nodes created to instances of \CGG{}. On the client computers ($192.168.1.12$), on the terminal, start 5 background \CGG{} tasks via:
+\begin{lstlisting}[style=sh]
+cd {path_to_cinelerra}
+cin -d 10650 cin -d 10651
+...
+cin -d 10654
+\end{lstlisting}
+In practice, at each instance that we start, the cursor will be positioned in a new line ready to enter the next command, without exiting the task. If we have several PCs on the network, repeat these steps for each new client (with its own ip address).
+\item Similarly, on the terminal, we must join the local nodes (internal to the Master node) created to instances of \CGG{}. On the Master node (localhost), start the 2 background \CGG{} tasks via:
+\begin{lstlisting}[style=sh]
+cd {path_to_cinelerra}
+cin -d 10655
+cin -d 10656
+\end{lstlisting}
+Similar to the previous point, the cursor positions itself in a new line ready to enter the next command, without exiting the task.
+\item When your video is ready, setup a render job via \texttt{File
+ $\rightarrow$ Render} or \texttt{File $\rightarrow$ Batch Render}
+ and check OK.
+\item The results will be in the shared file \texttt{path/filename}
+ that you selected in the render menu with the additional numbered
+ job section on the end as $001, 002, 003, \dots 099$ (example,
+ \texttt{video.webm001}).
+\item When finished, load your new files on new tracks via
+ \texttt{File $\rightarrow$ Load} \textit{concatenate to existing
+ tracks} or if you used ffmpeg, run \textit{RenderMux} from the Shell
+ Scripts icon.
+\item If you plan on doing more rendering, you can just leave the
+ master/client jobs running to use again and avoid having to restart
+ them. You can also close the terminal, but the jobs will remain active until you turn off the PC. Or you can kill them when you no longer are using them.
+\end{enumerate}
+
+\subsection{Render Farm Menu and Parameter Description}%
+\label{sub:render_farm_parameter_description}
+\index{render farm!parameters}
+
+Below we describe the Performance tab for configuring a render farm
+(figure~\ref{fig:farm}).
+
+\begin{figure}[htpb] \centering
+ \includegraphics[width=1.0\linewidth]{farm.png}
+ \caption{Settings: Preferences: Performance tab, menu
+ to set up your Render Farm}
+ \label{fig:farm}
+\end{figure}
+
+\begin{description}
+\item[Project SMP cpus] although this field is not Render Farm
+ specific, it is useful for \CGG{} to have the CPU count and for
+ using multiple threads.
+\item[Use render farm] check this to turn on the render farm option.
+ Once checked ALL rendering will be done via the farm including the
+ usual Render (\texttt{Shift-R}). You may want to turn if off for
+ small jobs.
+\item[Nodes listbox] displays all the nodes on the render farm and
+ shows which ones are currently enabled. The Nodes listbox has 4
+ columns -- On, Hostname, Port, Framerate -- which show the current
+ values. An \textit{X} in the \textit{On} designates that that host
+ is currently enabled; \textit{Hostname} shows the name of the host;
+ \textit{Port} shows the port number that host uses; and
+ \textit{Framerate} will either be zero initially or the current
+ framerate value.
+\item[Hostname] this field is used to edit the hostname of an
+ existing node or enter a new node.
+\item[Port] keyin the port number of an existing or new node here.
+ You can also type in a range of port numbers using a hyphen, for
+ example $10650-10799$ when you need to add many.
+\item[Apply Changes] this will allow you to edit an existing node
+ and to then commit the changes to hostname and port. The changes
+ will not be committed if you do not click the OK button.
+\item[Add Nodes] Create a new node with the hostname and port
+ settings.
+\item[Sort nodes] sorts the nodes list based on the hostname.
+\item[Delete Nodes] deletes whatever node is highlighted in the
+ nodes list. You can highlight several at once to have them all
+ deleted.
+\item[Client Watchdog Timeout] a default value of $15$ seconds is
+ used here and the tumbler increments by $15$ seconds. A value of
+ $0$ (zero) disables the watchdog so that if you have a slow client,
+ it will not kill the render job while waiting for that client to
+ respond.
+\item[Total jobs to create] determines the number of jobs to
+ dispatch to the render farm. Total jobs is used to divide a render
+ job into that specified number of tasks. Each background job is
+ assigned a timeline segment to process. The render farm software
+ tries to process all of the rendering in parallel so that several
+ computers can be used to render the results.