OK, gg and I took an initial look at your video but will have to check it much more closely. BTW - I really like the green circle that shows when you click - I need one of those! More later.
@phyllismith The name of the screen recorder I used is Vokoscreen. It was discontinued (maybe its package is still available in your distro tho) but there is a new version called Vokoscreen-NG that seems even better.
Here is the video showing the usage of keyframes, with a quick example of how it could be better using a separate window for keyframe timelines (if the sluggishness cannot be fixed):
Besides the bug regarding the Show titles I mentioned in my previous message, Cinelerra GG Infinity cannot handle PNG or JPG when vappi is enabled for HW acceleration, I get some errors in the terminal when running the app manually. It doesnt seem to be related to the system installed ffmpeg version. Should I open a bug tracker item for these two?
Another request suggestion is related to Titles: when adding them to an empty track they fill the whole track, is there a way to set a limit like 3s or 5s? Or maybe add a solid color generator for clips so we can add blank ones with a chosen duration to the timeline and them apply Title? I remember I was able to add a solid color filter, but as it is displayed as a filter and not a clip, probably adding one to an empty track will fill the whole duration as well (same as Title).
Regards
Hi,
Ive seen you dont use Autos (manual 7.1 and 7.2: Automation Keyframes, Autos). They are comfortable and speed up the work.
I think the main problem for new users is the habit of using keyframes as done in practically all other programs. CinGG is very different in the way of working, but I, by now, find much faster, more comfortable and precise the CinGG method (all available at the same time in the timeline) because it is more intuitive and immediate, without opening new windows, curve editors and small timelines for each effect. I have to say that the precision in working I have obtained only since I use a big monitor; before, with the laptop, I often didnt center the keyframe with precision and so I created another one I didnt want, etc..
A convenience is to right-click on the keyframe and choose the item that opens the adjustment slider (Fade in the case of the fade curve). This way you can make very precise adjustments and also enter the numerical value directly.
Im not sure I understand the problem with the Title plugin: when we have to apply an effect to only one edit or to only one part of the track (even empty), we have to use cut and past editing to select the desired region; or use the In/Out Points (manual 5.5.4: Selections Methods). You can then apply the effect only to the chosen region.
@andreapaz: because it is more intuitive and immediate
On the contrary, as it is, its the biggest shit. Not without reason, the Alpha version of Olive has more users than Cinelerra after twenty years. Just my opinion.
The problem of Cinelerra has indeed been the slow development time and also the unwillingness of the previous developers to respond quickly to user requests. This has partly changed due to the new developers, unfortunately their capacities are still not sufficient to address the most urgent problems. The user interface is still one of the biggest problems. Many users prefer a single window program. Also the arrangement of the buttons and the general design is very old-fashioned.
I agree with Olaf that Olive Editor does many things right and with the next version it will probably become the standard among open-source NLEs. The biggest advantage is that it has learned from the mistakes of other NLEs and will use this experience in a completely new development. The advantages are obvious, it can be used on almost all operating systems from Windows, Linux and Mac. This is also the main reason for the fast distribution, Windows users are a dime a dozen. The single-window operation and the handling reminds very much of professional NLEs like Premiere. The next killer feature in the upcoming version will be the node-based effects. It is a mixture of Premiere and Resolve.
Nevertheless I like Cinelerra-GG, it is very solid and the development is progressing. It will probably continue to be a niche application in the future, as it has been in the past. Due to the bad reputation from the past, it is unfortunately difficult to find new users now, but the awareness is slowly changing to the positive.
@olaf
Because people want the Premiere Pro interface and workflow. So it has already happened with Photoshop, which has destroyed every possible competitor. Now its happening with Premiere Pro.
@andreapaz I will take a look at Autos, thanks for the heads up! Other editors also have keyframes in the timeline too, OpenShot does this for Fade as well, IIRIC. The interface per si isnt the problem IMO, but how slow it gets making the feature unusable (regarding keyframes at least).
I think I tried to use copy&paste for the Title, but it didnt work, at least not when using a track just for titles. I had to insert a short clip from the Viewer, then add the filter. Thats why I am suggesting the feature of creating clips with solid colors, they can be useful for many other things as well.
Regards
@sam Cinelerra GG is so much porwerful than any other open source NLE right now, there is no comparison. No other can do speed ramps or object tracking AFAIK, the only other program that comes close is DaVinci Resolve, that is hard to install on Linux and requires a beefed up hardware.
With so many videos showing how to use CGG the interface isnt a huge problem IMO. Of course, it helps new users when the UI is similar to another program. But some things need time to get used to like the keyboard shortcuts (very different from any other NLE), how some things work like the Title plugin but mostly how slow it can run sometimes. My guess is that Olive is so popular now because it runs well for basic tasks on almost any machine that can run it, and the basic tools are easy to find and use.
Regards
I agree with you that Cinelerra is powerful and currently by far the most capable open source NLE available. Ive been working with Cinelerra for quite some time and I run the website here. I have never said that Cinelerra is bad. I just wanted to say that there are people who would like to have a Premiere Pro or Resolve replacement. Like single window operation and that the thing runs on Windows for example. Thats the audience the Olive Editor serves. Cinelerra is specifically designed for Linux, because of that alone the audience range is much smaller and for that reason it is a niche product and not a mass product like Premiere or other well-known NLEs.
Nevertheless, you can look beyond the horizon and also appreciate the achievements of others, which doesnt mean that I am disparaging our own work. We are automatically compared to the others and it does not hurt to consider some desired features for the future. This also includes a critical and honest self-assessment. I appreciate our work and also the help of supporters like you and the other people here. We are making progress and I am also very grateful to our developers for the many great new improvements.
I have found out what causes the errors when using vaapi for HW acceleration: if ffmpeg_first is enabled, CinGG cannot load JPG/PNG. It works if I disable it, load the images, then enable ffmpeg first for the videos.
@andreapaz I think I was using auto keyframes in the video showing the sluggishness, wasnt I? Unfortunately, I didnt find a way that would decrease the slowness and allow me to use keyframes. Also the lack of snap when moving filters (Ttile, for example), either the whole segment or the in/out points is frustrating… If it was possible to enable snap at least to the current cursor position it would help a lot.
Regarding applying the Title for just a segment of the track, the simple workaround I found was to move to copy&paste mode temporary, select the are I want for the title, and then apply the filter.
Regards
I was inaccurate, Im sorry; I meant to activate the generate keyframe while tweeking button. This way you decide by looking at the Compositor where to put/modify a keyframe; it will appear automatically in the Timeline. This will improve accuracy and viewing comfort; but its not about your slowness issues.
Good idea for a keyframe snap. In the Mask tool there is no need to get to the point precisely, just be nearby to activate and move that point. I wonder if you can do this for keyframes as well.
Im not sure if the way to put a filter in a region of the track works for you or not. Its not a workaround, but just the right way to do it.
Vaapi does not support images and errors appear on the terminal, but everything should work normally without problems: on the Timeline them should be loaded and viewed without problems. There is a compatibility table at the link:
I finally dragged out GG and dragged out a smaller laptop and we spent several hours trying to get bad results similar to that you show in your 2 videos. We saw no slowness and he had dumb downed the Pavillion dv6 (800mhz) to 3.5GB of RAM with 512 Video RAM and 4 CPUs. He had 3 Cinelerra sessions running simultaneously, 2 Autos (keyframes) enabled (Fade and something else); each was loaded with 1920x1080 video with 6 audio tracks, a couple of View windows up, and playing in the Compositor, plus at least 3 plugins with their menus popped and they were enabled.
CONCLUSION: ggs best guess is that you are swapping and out of graphics memory.
PLEASE TEST: based on this guess, could you run top from the command line?, make sure no other large tasks are running, and then start up Cinelerra. Put the top screen where you can see it when using Cinelerra. Run the same kinds of commands that you did in demo #1 (i.e. the c29…mp4 demo) and CAREFULLY watch the top display - specifically the KiB Swap (or MiB Swap) line (it is about the 4th line from the top) and in about the 3rd field over there is the number followed by the word used. If it is non-zero, this will confirm that you are simply out of memory. In our tests, it stayed at 0.0 until we kept adding more and more menus and doing more stuff and then it would get to 84 but even then we did not see the abysmal slowness of using the View pulldown like seen in your video.
From your demos, I do not think you can work like this and you may have to find an alternative solution or a different computer.
About the issue of the fade auto (keyframe) line hard to work with it being so near the edge, there is an easy solution. On the bottom of the timeline is the zoom bar. Starting from the left side, you see a number, then the number 64, some toggles, another number 64, and then a box that probably reads Audio Fade. Use the arrow to the right of Audio Fade, and change to Video Fade and then modify the number range to the right of this box which probably reads 0.0 to 100.0 to 0.0 to 200.0 and then the Fade line will be further down in the video track so it is easy to work with. Let me know if you need a demo.
@andreapaz I got the generate keyframe while tweeking working for fade, it is nice because there is a slider for the track opacity. So it works with any other parameter regarding filters? But my main problem remains: how slow the program responds when I enable keyframes…
Yeah, I know copy&paste edit mode isnt a workaround, but it seems weird for anyone used to drag&drop. I understood what you meant nonetheless.
Regarding JPG/PNG: it doest work if I keep vaapi + ffmpeg first enabled, I have to disable ffmpeg first, import the images, then enable it again, while I keep vaapi enabled in settings, otherwise all I get are black thumbnails that slows down CinGG and it eventually crashes.
@phyllissmith Sorry to disappoint you (I am sad too!) but even with swap off I get super sluggishness, please see attached screenshot. Even if I just open CinGG without loading any media but with Fade enabled in View I get the same problem… Maybe its something related to the DE? Do you mind sharing the environment used for testing (distro, kernel, DE, screen resolution, etc)? Maybe it is a bug related to small screens like mine?
Screenshot-from-2020-04-05-23-27-26.png
There is a serious resource contention of some kind. Memory is the first and most critical demand that is needed for proper operation. There are at least 3 kinds of critical memory.
-
dynamic ram for local program operation.
-
dynamic ram for shared items.
-
graphics memory. This may be in short supply on your system.
The menu bar popup menus are constructed when the program initializes. When you activate one, all that happens is that it goes from unmapped offscreen image memory to mapped onscreen image data. On your system, just creating a keyframe seems to capsize this process. How can this happen if the image already is built? All that is supposed to happen is that the blitter (bit editor in your graphics card) is supposed to blast that image onto the main display at just the right moment. This is suddenly very slow. Why? There are several major steps to realizing the process. First, the mouse motion/button event must be received and processed on the window thread which operates the main window. Next, the rendering primitives are sent to the X server to realize the offscreen data. Then, the X server must draw the updated display, and post it to the video ram and rendering hardware.
Run top and watch the programs in execution when the problem is occuring. Is cinelerra executing at all? Is it running at cpu saturation? Are other tasks (window manager, X) using more resources than cinelerra (hogging resources)?
Just in case in was not obvious from the technical flavor of the last post, it was written by GG instead of the less than technical me.
The computer we did the tests on has the following characteristics:
HP Pavilion dv6 / 4 CPUs / 4GB RAM / 800 mhz
x86_64 / 64 bit / Little Endian
AMD A8-3500M APU with Radeon HD Graphics
DE = Gnome (I think version 3.10 according to the web)
O/S = Fedora version 20 (this laptop was not booted for at least 4 months so this is really old but we did not want to take the time to upgrade it to the latest version 31). I think the kernel version is 3.11 from what I see on the web).
Forgot to mention that we compiled CinelerraGG from scratch here and because Fedora was so old, we had to comment out some of the newer stuff, like aom, webp, dav1d, etc. that required a later version of nasm, etc.
VAAPI with png-s works to load these on a different HP/Intel laptop and you can see them instead of black blobs, BUT they default to be loaded without vaapi. I see the message in the terminal window of Decoder png does not support device type vaapi. It is supposed to fall back like this and if it does not, then perhaps you have a different error message and we would like to see that too. As you noted, if you do not use FFmpeg first, it does use vaapi which I can confirm and am somewhat surprised about.
@phyllissmith The problem is XOrg/Wayland (display server) indeed. Although it is not shown in the CPU graph that I use in the top bar, top command shows that they use 98% of the CPU when I activate Fade in View. But it is caused by some iteration between CinGG and the display server, because it only happens with Cinelerra. Both kernel and Gnome you used is pretty old, are you sure it doesnt happen with latest configurations? In the meantime, I have latest Manjaro installed in an (slow) external drive that I am using for tests, I will check if this happens with it as well. I know a few GTK apps have issues with Gnome on Ubuntu (the distro I use is based on Ubutuntu 19.10), Manjaro runs a newer kernel and Gnome tho.
** Posted by: @lfom **In the meantime, I have latest Manjaro installed in an (slow) external drive that I am using for tests, I will check if this happens with it as well.
Well, it didnt work, CinGG complained about a missing libjbig.so.0 that I could not find in Arch repos (there is one named jbigkit but it didnt work either).
BTW, I got a 404 error when I try to read the Arch requirements in the page:
I think the correct URL is: https://cinelerra-gg.org/download/README.arch
Could you use the static tar instead of the package install for Arch?
Meanwhile we have been trying to come up with what the problem is. It seems like drawing lines is where the problem occurs, i.e. audio waveforms consist of lines; keyframe autos are lines.
Our test laptop with the old gnome and old Fedora versions do not appear to be relevant as we routinely run using Fedora 29, 30, and 31 with whichever version of gnome comes with those on about 4 computers with no problems.
VAAPI only works with ffmpeg (clarification from gg for me) so that explains why no error messages when I load pngs with vaapi enabled – it is not even using it. I did a vainfo and compared it to the version you are using and you are at 1.5.0 and I am at 1.6.0 so I do not know if that is why i see the actual pngs and you just see black. Vainfo shows you hae an Intel CherryView and I have Intel Broadwell.
GG would like to see your file: /var/log/Xorg.0.log to check for errors there if you have time to send. Thanks for the notify on the Readme.arch – I can fix that.
The one thing we have not ruled out is Wayland. Although we tried this about 1 year ago, just once, we have no experience with it. Maybe when/if gg has time he can try that again to see if it could be a source of a problem.
We looked at your inxi results and your computer specs (on the net) and there did not spot anything unusual about it – it should just work with Cinelerra.
@phyllissmith By static tar you mean the single user build? I was trying to use the same single user build (latest one) I have installed and I using with Pop!_OS with Manjaro, I didnt install it from their repos.
The same problem happens with me either using Wayland (CinGG actually runs in its XOrg compatibility layer, called Xwayland) or plain Gnome on XOrg, same exact output in top using either. I dont think it is related…
As soon as I can I will share the XOrg logs while trying to use CinGG.
Thanks a lot for your feedback! Regards