Re: [Cin] Seconds to preroll render
Unfortunately, my old computer's performance doesn't improve by changing Preroll values. (OS-UbuntuStudio16.04_64bit) Andrea wrote: but why doesn't the whole world speak Italian? "Why are you speaking in English?" (Sheldon Cooper) My suggestion would be to speak in Klingon or UbbiDubbi! Take a look at https://www.youtube.com/watch?v=ETFmY93JnoU -- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
Re: [Cin] Seconds to preroll render
Thank you. With a few minor mods, checked into GIT. We should all just be speaking one language called "Earth" so that we can talk to the aliens more easily -- you know they are out there right?! On Thu, May 5, 2022 at 1:06 PM Andrea paz wrote: > Here are the variations to the manual on caching and preroll. Please, > the usual check on the language! (but why doesn't the whole world > speak Italian?). > -- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
Re: [Cin] Seconds to preroll render
On Thursday, May 5, 2022, Andrea paz via Cin wrote: > Here are the variations to the manual on caching and preroll. Please, > the usual check on the language! (but why doesn't the whole world > speak Italian?). > because interesting Italians speak english already?) spatial audio/VR http://pcfarina.eng.unipr.it/Ambix_3rd_order.htm (found by chance while searching for 'matrixing' operation apparently required for TrueHD 5.1/7.1 encoder..) -- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
Re: [Cin] Seconds to preroll render
Here are the variations to the manual on caching and preroll. Please,
the usual check on the language! (but why doesn't the whole world
speak Italian?).
\chapter{Performance and other Tips}%
\label{cha:performance_tips}
Performance of \CGG{} is related to the software and video format being used in conjunction with your computer system hardware -- the number of CPUs and its speed, I/O bus speed, graphics card, and amount of available memory. A basic, less powerful system will be sufficient for users working with audio only or lower resolution video formats. Higher end computers will be needed when playing and working with higher resolution formats, like 1080p or 4k. Adding effects and multiple tracks will require more cpu, memory, and various other resources to
perform at an acceptable level.
Perhaps the easiest method for determining if your performance could be improved is to look at the numerical value displayed as \textit{Framerate achieved}. Good performance means that when \textit{Play every frame} is set
in \texttt{Settings $\rightarrow$ Preferences, Playback A} tab, the frames/second (frames per second or fps) in playback might be almost always at the maximum rate of your project setting and/or video frame rate. You can check this in \texttt{Settings $\rightarrow$ Preferences, Playback A}, by watching \textit{Framerate achieved} while playing forward. A higher number is better, up to the format frame rate of the video.
Some computer hardware factors to consider for better performance are listed here:
\begin{itemize}
\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 that we will 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. \CGG{}'s not as expensive as other NLEs, however we can optimize RAM utilization with \textit{Cache size} and \textit{Seconds to preroll render} parameters. Se section \ref{sec:cache_and_preroll}. If we have limited RAM we 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 CINELERRA-GG 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. The higher the transfer rate, the less slowdowns and problems we will have. 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.
\end{itemize}
Besides the above hardware recommendations, this section covers tips for performance improvements and tips on how to perform some specific tasks, often for older media.
\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
under \hyperref[sub:gpu_hardware_encoding]{GPU hardware encoding}.
VDPAU, Video Decode and Presentation API for Unix, is an open source library to offload portions of the video decoding process and video post-processing to the GPU of graphics boards, such as Nvidia. It may also apply to Nouveau and Amdgpu boards (by wrapper), but that has not been verified.
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
Re: [Cin] Seconds to preroll render
Yes, it is helpful to put some more details in the manual. I'll look into it, but let me run a few more tests so I have a clearer idea. -- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
Re: [Cin] Seconds to preroll render
Andrea, still it would be useful to make a note in the Manual so I will do that unless you would rather do that yourself? It seems to run in reverse more consistently for me and not as jerky - although my test only had 1 video effect added. I have to scale back my enthusiasm. With Further Testing I don't get > much of a boost, especially if there are effects and transitions. > -- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
Re: [Cin] Seconds to preroll render
Thanks. I have to scale back my enthusiasm. With Further Testing I don't get much of a boost, especially if there are effects and transitions. -- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
Re: [Cin] Seconds to preroll render
For me it also makes a difference and it should be put into the manual for sure as a possibility on some computers. I assume it is based on the speed to get to the disks?? And there is probably a "sweet spot" for anyone's specific system. Here are my observations but not totally scientific based on 64-bit Fedora 31/32. Input File: Big Buck Bunny with Video Effect brightness/contrast applied; Play every frame enabled (I got different results when not Play every frame). *HP slow laptop* Forward Framerate Achieved = 32 for .5, 1.0, and 2.0 seconds. *0.5 *seconds Reverse Framerate Achieved average = *15* and varied from a low of 9 to a high of 18 *1.0* seconds Reverse Framerate Achieved average = *18 *and varied from a low of 15 to a high of 23 -- playing seemed moe consistent 2.0 seconds Reverse Framerate Achieved average = 17 and varied from a low of 13 to a high of 23 *AMD gaming laptop* Forward Framerate Achieved = 60 for .5, 1.0 and 2.0 seconds. * 0.5 *seconds Reverse Framerate Achieved average = *32* and varied from a low of 19 to a high of 40 *1.0* seconds Reverse Framerate Achieved average = *36 *and varied from a low of 28 to a high of 42 -- playing seemed moe consistent 2.0 seconds Reverse Framerate Achieved average = 35 and varied from a low of 30 to a high of 43 On Tue, May 3, 2022 at 2:18 AM Andrea paz via Cin < cin@lists.cinelerra-gg.org> wrote: > One thing that has always bothered me is that in the transition from > an 11 year old notebook to a mid-to-high level PC, playback and > especially reverse playback always suffered from the same lags and > framerate drops. There wasn't the improvement I expected. In the > Preferences > Performance tab, I tried increasing the "Cache size" > from 256MB (default) to 4096MB without noticing any change (I have > 32GB of RAM). I never touched the "Seconds to preroll renders" option, > which by default is 0.5 seconds. Now I've tried to set it to 1.0s and > the improvement in playback and reverse playback is EVIDENT! > If anyone feels like trying to take a problematic project in timeline > and increase the preroll time and then report the results, it would be > a favor to me. If the improvement is also confirmed by others I will > immediately put the tip in the manual, because it seems very important > to me. > -- > Cin mailing list > Cin@lists.cinelerra-gg.org > https://lists.cinelerra-gg.org/mailman/listinfo/cin > -- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
Re: [Cin] Seconds to preroll render
for me only obvious positive difference comes from increasing cache from 256 mb to 2048 mvb but I am on 32-bit cin + 64 bit Linux kernel (5.1.12) I tried with single 1080p 24 fps vp9 video as downloaded from youtube. With default 256 mb cache reverse playback stutters a lot. With 512 it stutters less. With 2048 mb it stutters only ocassionally. Changing preroll renders from 0 to 100.0 does not change things for me. On Tuesday, May 3, 2022, Phyllis Smith via Cin wrote: > That is quite a discovery. Hopefully, I can find time today to test that > as I have a really slow laptop and a decent faster laptop. > Maybe that is what makes the difference. OR it could just be 0.5 seconds > is leftover from the really old days. > > On Tue, May 3, 2022 at 2:18 AM Andrea paz via Cin < > cin@lists.cinelerra-gg.org> wrote: > >> One thing that has always bothered me is that in the transition from >> an 11 year old notebook to a mid-to-high level PC, playback and >> especially reverse playback always suffered from the same lags and >> framerate drops. There wasn't the improvement I expected. In the >> Preferences > Performance tab, I tried increasing the "Cache size" >> from 256MB (default) to 4096MB without noticing any change (I have >> 32GB of RAM). I never touched the "Seconds to preroll renders" option, >> which by default is 0.5 seconds. Now I've tried to set it to 1.0s and >> the improvement in playback and reverse playback is EVIDENT! >> If anyone feels like trying to take a problematic project in timeline >> and increase the preroll time and then report the results, it would be >> a favor to me. If the improvement is also confirmed by others I will >> immediately put the tip in the manual, because it seems very important >> to me. >> -- >> Cin mailing list >> Cin@lists.cinelerra-gg.org >> https://lists.cinelerra-gg.org/mailman/listinfo/cin >> > -- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
Re: [Cin] Seconds to preroll render
That is quite a discovery. Hopefully, I can find time today to test that as I have a really slow laptop and a decent faster laptop. Maybe that is what makes the difference. OR it could just be 0.5 seconds is leftover from the really old days. On Tue, May 3, 2022 at 2:18 AM Andrea paz via Cin < cin@lists.cinelerra-gg.org> wrote: > One thing that has always bothered me is that in the transition from > an 11 year old notebook to a mid-to-high level PC, playback and > especially reverse playback always suffered from the same lags and > framerate drops. There wasn't the improvement I expected. In the > Preferences > Performance tab, I tried increasing the "Cache size" > from 256MB (default) to 4096MB without noticing any change (I have > 32GB of RAM). I never touched the "Seconds to preroll renders" option, > which by default is 0.5 seconds. Now I've tried to set it to 1.0s and > the improvement in playback and reverse playback is EVIDENT! > If anyone feels like trying to take a problematic project in timeline > and increase the preroll time and then report the results, it would be > a favor to me. If the improvement is also confirmed by others I will > immediately put the tip in the manual, because it seems very important > to me. > -- > Cin mailing list > Cin@lists.cinelerra-gg.org > https://lists.cinelerra-gg.org/mailman/listinfo/cin > -- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
[Cin] Seconds to preroll render
One thing that has always bothered me is that in the transition from an 11 year old notebook to a mid-to-high level PC, playback and especially reverse playback always suffered from the same lags and framerate drops. There wasn't the improvement I expected. In the Preferences > Performance tab, I tried increasing the "Cache size" from 256MB (default) to 4096MB without noticing any change (I have 32GB of RAM). I never touched the "Seconds to preroll renders" option, which by default is 0.5 seconds. Now I've tried to set it to 1.0s and the improvement in playback and reverse playback is EVIDENT! If anyone feels like trying to take a problematic project in timeline and increase the preroll time and then report the results, it would be a favor to me. If the improvement is also confirmed by others I will immediately put the tip in the manual, because it seems very important to me. -- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
