It was just the DISPLAY business that had to be fixed.I've seen mention of 'FFmpeg', but this seems like it would only be able to accomplish basic tasks such as converting a series of images into a video (am I wrong?).įFmpeg (the ffmpeg command-line tool or usage of its libav* libraries) can do a lot of what the example videos show, but some effects would be difficult if you have no experience using FFmpeg. In fact, I don't seem to need this ffmpeg option to get a screen grab. Note also KDE documentation talks about a need to obtain an ffmpeg binary compiled with -enable-x11grab (or more properly, -enable-libxcb) in order for kdenlive screen grab to work. The 21.12.3 version I was using didn't show me the error output from the ffmpeg command, and it was only by chance I tried the 22.04 version this evening (which was scheduled for release tomorrow but I guess it went out early) and it did now show that error output. Note that kdenlive screen grab has some wonky behaviour, which made it harder for me to understand this problem. However, for some reason I got a Qt error doing that, and so I couldn't tell if that was a useful workaround or not. In the user's gdm3 session that is on :1 by default, I also tried to set DISPLAY :0 in an xterm and start kdenlive from the command line in that xterm. I also tried to understand if it is possible to have gdm3 put the user on DISPLAY :0 as a default at boot time through some custom configuration, but couldn't figure it out. So if you don't mind switching window manager, that could be a way to do it.

When I tried the lightdm manager, I found that it still has the older convention of putting the user on the :0 DISPLAY, which is compatible with kdenlive screen grab. From what I can see, kdenlive is hard-coded to use DISPLAY :0, while ubuntu and gnome/gdm have switched (around ubuntu 18?) to put the user on DISPLAY :1.

Kdenlive custom ffmpeg options