I was inaccurate, I'm 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 it's 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.
I'm not sure if the way to put a filter in a region of the track works for you or not. It's 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:
https://wiki.archlinux.org/index.php/Hardware_video_acceleration
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: gg's 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 isn't a workaround, but it seems weird for anyone used to drag&drop. I understood what you meant nonetheless.
Regarding JPG/PNG: it does't 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 it's 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?
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.
1) dynamic ram for local program operation.
2) dynamic ram for shared items.
3) 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 doesn't 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.
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 didn't work, CinGG complained about a missing libjbig.so.0 that I could not find in Arch repos (there is one named jbigkit but it didn't work either).
BTW, I got a 404 error when I try to read the Arch requirements in the page:
https://www.cinelerra-gg.org/arch-cinelerra-installation-instructions/
I think the correct URL is: https://www.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 png's 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 png's 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 didn't 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 don't 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
GG has made an improvement based on slowness he was able to see on an quite old desktop computer running Mint 19.3. This mod really helped to "draw lines". He then created a static tar ubuntu 19.10 for you to test. Please let us know if this solves the problem.
https://cinelerra-gg.org/download/testing/cinelerra-5.1-ub19-x86_64-static.txz
@phyllissmith Well, I guess I bit my tongue: it worked flawlessly under Manjaro (Gnome 3.36), even with assets and all auto keyframes enabled under XOrg (even tho it used a lot of CPU when scrolling the timeline it didn't freeze the user input), but it was slow again when I used Wayland (CinGG runs under Xwayland as I said). Not as slow, but still much slower than under XOrg. I carefully checked all the settings, to make sure it was using the same configuration as Pop!_OS, but nothing I changed caused slowness under XOrg on Manjaro. Only vaapi didn't work, probably due to missing libs since this test installation was created with Architect to be streamlined.
PS: Initially the Arch static build didn't run due to a missing "libnuma", but it was fixed installing "numactl" which provides the missing library.
I tried it again on Pop!_OS with XOrg instead of Wayland, and it was still slow, so I guess my main problem is related to Wayland and/or something related to the XOrg on Ubuntu 19.10. Too bad there is no workaround for me as I will be stuck to this system for a while. But I am happy that it's not an issue with CinGG infinity itself!
Thanks again for all the replies. Hopefully more people will start to use Cinelerra GG Infinity, and more people will help with its development as well.
Regards
Just an idea: your video ram is part of the system ram. Is there maybe a bios option that limits the amount of video ram that can be used? If so, have you tried different values?
I installed Pop!_OS in a Vbox VM, 2 CPUs, 4G ram, 16M video ram. After updates, installed the 2020-03 single user tar for Ubuntu 19. It started fine, I left everything at default. In a VboxVM, hardware video acceleration is not available. When I loaded a 1080p50 mp4 video, and added 5 extra audio tracks to the 2 from the video, I noticed after some time that CPU utilisation was well over 100% (100% being 1 CPU equivalent full out). It only went down when I cycled in the resource window the icons to show only text. Is this also the case with you?
On subsequent starts from Cin-GG and loading the same video, it quieted down after some time, and "top" showed low utilisation.
Second, how do you switch between Wayland and X11? I did not see an obvious setting for that.
Regards
