\label{sec:create_ffmpeg_options_files}
\index{ffmpeg!options files}
-AppImage does not provide this capability. This section describes how the FFmpeg options files work for decoding and encoding and goes into great detail. It will make more sense if you look at \CGG{}'s ffmpeg config directory and the \CGG{} menus at the same time.
+This section describes how the FFmpeg options files work for decoding and encoding and goes into great detail. It will make more sense if you look at \CGG{}'s ffmpeg config directory and the \CGG{} menus at the same time.
It is meant to include everything necessary for complete understanding. You will be able to personalize your own options files without knowing all of the information included below if you know the basics. The word encoding is used interchangeably with the word rendering.
The possible combinations for ffmpeg options files are literally combinatorial -- that is a lot (factorial!). The allowed media file format / codec choices are much more flexible than you might realize. When the ffmpeg design was initially added, some parameter files which describe the choices which the program uses had to be created. There are way too many to enumerate in the deliverable \CGG{} package. Some quite detailed information for how ffmpeg options work is given here and hopefully, enough basics for simple understanding. It may all seem complicated at first, but will become obvious.
+AppImage does not provide this capability unless you use the workaround as described in the Appendix \nameref{cha:faq_problems_workarounds}.
\subsection{File naming convention}%
\label{sub:file_naming_convention}
-AppImage does not provide this capability. In \CGG{}'s ffmpeg configuration directory you will see files as listed and described below. File type and extension names are the key for \CGG{}'s use of ffmpeg. Basically the \texttt{.opts} file extension represents options; \texttt{.dfl} represents defaults; and all the rest are media types. For example one media type is quicktime so that \texttt{*.qt} file names would be the \textit{quicktime} choices. In the file names below, \textit{ext} refers to a set of files with file names matching the \texttt{*.ext} file extension. And \textit{typ} refers to a type of format / codec combination used, that is, the media type.
+In \CGG{}'s ffmpeg configuration directory you will see files as listed and described below. File type and extension names are the key for \CGG{}'s use of ffmpeg. Basically the \texttt{.opts} file extension represents options; \texttt{.dfl} represents defaults; and all the rest are media types. For example one media type is quicktime so that \texttt{*.qt} file names would be the \textit{quicktime} choices. In the file names below, \textit{ext} refers to a set of files with file names matching the \texttt{*.ext} file extension. And \textit{typ} refers to a type of format / codec combination used, that is, the media type.
+AppImage does not provide this capability unless you use the workaround as described in the Appendix \nameref{cha:faq_problems_workarounds}.
In the ffmpeg configuration directory there are a series of options files used when encoding or decoding audio or video. They are read in the order from top to bottom and only the files needed for the current operation are added to the active configuration.
\label{sub:option_file_format_content}
\index{ffmpeg!option file format}
-AppImage does not provide this capability. For the option files a specific format must be followed in creating the file content.
+For the option files a specific format must be followed in creating the file content.
+AppImage does not provide this capability unless you use the workaround as described in the Appendix \nameref{cha:faq_problems_workarounds}.
In \texttt{typ.ext} encoder parameter files, the first line is defined as:
\begin{lstlisting}[style=sh]
\label{sec:ffmpeg_image2_streams}
\index{ffmpeg!image2 streams}
-AppImage does not provide this capability. Another feature gained from using ffmpeg in \CGG{} takes advantage of what is being referred to as the \textit{\%d trick}. This trick uses the ffmpeg muxer image2 and a filename template to create a series of image files of a given type. A specific example is described below.
+Another feature gained from using ffmpeg in \CGG{} takes advantage of what is being referred to as the \textit{\%d trick}. This trick uses the ffmpeg muxer image2 and a filename template to create a series of image files of a given type. A specific example is described below.
+AppImage does not provide this capability unless you use the workaround as described in the Appendix \nameref{cha:faq_problems_workarounds}.
To encode a series of $48$\,bit tiff output image files, add a file to the \CGG{} data ffmpeg/video subdirectory as in:
\subsection{Delete Plugins to save Resources Space or make them Unavailable}%
\label{sub:delete_plugin_resouces_unavaible}
-Maybe you just don't ever use certain plugins or would prefer to only find the ones that are useful to you. To save space in the Resources Window so you don't have to scroll to find the plugins you want as much, a feature to delete others is available. If you have a System install, you will have to be root for this function to be usable. The plugins will be permanently deleted, but only until you rebuild or download a new set of \CGG{} binaries. To delete a plugin, highlight the plugin you no longer want in the Resources window then press Ctrl-Shift-delete. A small window will come up allowing you to change your mind and red-X out or check-OK to remove plugin. This feature may come in handy if you have personnel working on media for you and you only want them to exercise certain functions. Or maybe you can't remember which is the good \textit{deinterlace} plugin out of the available five or so and want to delete the extras so as not to be confused. The ffmpeg, \textit{ladspa}, and \textit{lv2} plugins can not be deleted in this manner but, of course, you can always turn them off from view by clicking on \textit{Visibility} and unchecking them (figure~\ref{fig:remove-effect}).
+Maybe you just don't ever use certain plugins or would prefer to only find the ones that are useful to you. To save space in the Resources Window so you don't have to scroll to find the plugins you want as much, a feature to delete others is available. If you have a System install, you will have to be root for this function to be usable. The plugins will be permanently deleted, but only until you rebuild or download a new set of \CGG{} binaries. To delete a plugin, highlight the plugin you no longer want in the Resources window then press Ctrl-Shift-delete. A small window will come up allowing you to change your mind and red-X out or check-OK to remove plugin.
+AppImage does not provide this capability unless you use the workaround as described in the Appendix \nameref{cha:faq_problems_workarounds}.
+
+This feature may come in handy if you have personnel working on media for you and you only want them to exercise certain functions. Or maybe you can't remember which is the good \textit{deinterlace} plugin out of the available five or so and want to delete the extras so as not to be confused. The ffmpeg, \textit{ladspa}, and \textit{lv2} plugins can not be deleted in this manner but, of course, you can always turn them off from view by clicking on \textit{Visibility} and unchecking them (figure~\ref{fig:remove-effect}).
\begin{figure}[htpb]
\centering
(or cinfinity2, original or smoother -- Leap distro)
+AppImage does not provide this capability unless you use the workaround as described in the Appendix \nameref{cha:faq_problems_workarounds}.
+
\subsection{Details on where to put your own Plugin Icons}%
\label{sub:details_put_plugin_icons}
\label{sub:example_plugin_icon_testing}
For a simple test just copy an existing \texttt{<plugin\_name>.png} file into the cinfinity directory with the name \texttt{bluebanana.png} to write over the existing file. This icon will now show up in \CGG{} and still execute the Blue Banana function.
+AppImage does not provide this capability unless you use the workaround as described in the Appendix \nameref{cha:faq_problems_workarounds}.
For an ffmpeg plugin, create \texttt{ff\_loop.png} and copy it to: \\
\texttt{<cinlib\_path>/plugins/picon/original}. This icon will show up in \CGG{} if original is selected and execute the \textit{F\_loop} function.
The X Window system originally did not have a suitable font renderer for video. It also is restricted to the current bit depth. It does not have a convenient way to know which fonts work with the suitable font renderer in the desired bit depth. The easiest way we have found to support fonts in the titler is to have a directory for them at \texttt{/usr/lib/cinelerra/fonts}.
-The titler supports mainly \textit{TTF}, true type fonts. It supports others but TTF are the most reliable. To add true type fonts, copy the \texttt{.TTF} files to the fonts directory. In that directory run
+The titler supports mainly \textit{TTF}, true type fonts. It supports others but TTF are the most reliable. AppImage does not provide this capability unless you use the workaround as described in the Appendix \nameref{cha:faq_problems_workarounds}.
+
+ To add true type fonts, copy the \texttt{.TTF} files to the fonts directory. In that directory run
\vspace{1ex}
\begin{lstlisting}[style=sh]
# /usr/lib/cinelerra/fonts
\label{cha:faq_problems_workarounds}
\index{workarounds}
-There are a few known problems that have not yet been fixed for which there are some workarounds presented here.
+Some workarounds for issues and a few known problems that have not yet been fixed, are described here.
\paragraph{Workaround for the \textit{alpha channel not working as intended when using an EDL} inserted as a reference or when an EDL is nested.}
Using the Projector on the EDL within a Master Project follow these next steps.
having a separate plugin for each clip. Or another workaround is to use two tracks and have the
plugin cover the cut point and use a Fade auto instead of the Dissolve transition.
+\paragraph{Workaround for access to modifiable text files when using AppImage.} This includes
+such files as FFmpeg video or audio files, fonts that you want to add for usage in the Title
+plugin, icons that you wish to modify, and any other text file for customization.
+To get access, first extract the files from the AppImage, find the files to add, edit, or modify, and then run the extracted binary following the steps shown here.
+\begin{itemize}
+ \item /path-to-appimage/CinGG-20211231-x86\_64.AppImage --appimage-extract
+ \item edit or add the files you want to modify in the \textit{bin} subdirecctory
+ \item /path-to-appimage/squashfs-root/usr/bin/cin
+\end{itemize}
+
\paragraph{The Fade auto in certain circumstances produces an unwanted black flash.}
When you insert an effect on an empty track the fade fades as if it were on a black background;
it interprets the alpha as black where there is transparency, which is what produces the fade.
Just a side note here. Fade in/out in the Title plugin works fine if there is a clip/image above
the plugin in the same track without an alpha channel but not if there is no clip/image.
And the Transition effect works fine when there is a transition between two clips/images without
-an alpha channel.
\ No newline at end of file
+an alpha channel.
VA-API, Video Acceleration API, is an open source library which provides both hardware accelerated video encoding and decoding for use mostly with Intel (and AMD) graphics boards.
+AppImage will probably not allow for either VDPAU or VA-API hardware acceleration because the
+computer where AppImage is created will not have the same graphics card as yours.
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.
projects / goodguy / cin-manual-latex.git / commitdiff