Hi
The MELT (or MELT6) command, which is critical to kdenlive (video editor) segfaults immediately it is run. This happens with the versions of MELT from the Opensuse and Packman repos.
The failing module (in libmlt6-modules) is libmltfrei0r.so. If you remove this module from /usr/lib64/mlt-6 then MELT runs OK but presumably without access to any of the frei0r filters.
The upshot of this is you can edit videos but you can’t render the final result.
Curiously, on Tumbleweed, it works OK. Unfortunately, I’m running Leap 42.2.
OK. I checked an got a segfault. So I started digging.
First, make sure all your packages are from packman (go to packman repository in YAST and switch all system packages).
Second, make sure that frei0r-plugins is not installed. That is from the wrong repository and will not work with the packman builds. The melt6 package includes frei0r.
Also, install ladspa (my system was complaining that it was not installed when I tried to run melt). This may be irrelevant for you.
After that, melt tried to display video but still segfaulted. That was resolved by setting my window decorations back to breeze.
melt is no longer segfaulting on my Leap 42.2 system.
I’ve just rendered a video successfully after some weeks of not being able to. (I’ve had quite a journey around various program forums, trying to work out where the problem was.)
Glad I could help. I have a long standing battle with kdenlive. I used to build it form source because of issues with the repository packages. But that hasn’t been an issue for a while, so I was well motivated when my belief in them was challenged. As a lesson, my recommendation is always to come here first. I’ve learned most of what I know from this community.
OK. I don’t think I have a solution for you. I have never obsessed about the frei0r filters, as my kdenlive needs are not that sophisticated. I did try installing the frei0r-plugin packages from tumbleweed, as well as a number of different repos, but no joy. Your best bet is going to be to write to the mlt packman packager as see if (s)he is willing to build a frei0r-plugins package as well.
Lacking that, there are only a few other options. Since you have access to a tumbleweed installation that you say works, you might look to see where kdenlive is installed from (packman or opensuse repo). If it is working with the opensuse frei0r-plugins package, probably it is the kdenlive from the original installation (not packman). If true, you could try reverting all your packman packages back to the Main repository. That is going to be quite a few packages, including kdenelive, mlt, ffmpeg, and libav*. It is something to try.
Or you could try building everything from source and have your own complete installation that you maintain. I’ve done that in the past, but don’t really recommend it. It’s a pretty long build sequence, and it is much harder to get support when you run into trouble.
Hm, I don’t think there’s a (general) problem with the frei0r-plugins package in 42.2, and it is definitely not “incompatible” to Packman’s kdenlive and mlt packages either (which are the same versions than in the standard repo anyway).
I just tried to render some small videos with frei0r-plugins installed and had no problems here (running 42.2).
Yeah, we may have gotten sidetracked by the fact that, for us, this command
melt nameofvideo.mp4
causes a segfault if the frei0r-plugins package is installed. No segfault is observed if it is not installed. Wolfi, can you confirm that melt does not segfault on your system?
I do have an additional data point. I went ahead and built frei0r-plugins from source. melt segfaults. I then went through the process of elimination, and discovered that it is the filters that begin with “cairo” that are the source of the problem. With all others installed, melt works fine. I don’t have an explanation, just the observation to share.
I do have an additional data point. I went ahead and built frei0r-plugins from source. melt segfaults. I then went through the process of elimination, and discovered that it is the filters that begin with “cairo” that are the source of the problem. With all others installed, melt works fine. I don’t have an explanation, just the observation to share.
Seems to be related to cairo then, or an incompatibility between the installed cairo and frei0r-plugins.
What does “rpm -qi libcairo2” say?
OTOH:
Cairo is a vector graphics library with cross-device output support.
Currently supported output targets include the X Window System,
in-memory image buffers, and PostScript. Cairo is designed to produce
identical output on all output media while taking advantage of display
hardware acceleration when available.
So it may even be a graphics driver issue.
Do you get any error messages in the terminal when melt/the cairo plugins crash?
Does the backtrace have a clue maybe?
What graphics driver are you using?
One thing that has caused problems for users in the past (including me starting with 42.2) is libvdpau_va_gl1. I would suggest trying to uninstall it if it is installed.
Though I have no idea whether cairo would use VDPAU…
john@linux-5vqd:~> rpm -qi libcairo2
Name : libcairo2
Version : 1.15.2
Release : 4.2
Architecture: x86_64
Install Date: Wed 22 Feb 2017 09:17:51 PM EST
Group : System/Libraries
Size : 1665491
License : LGPL-2.1+ or MPL-1.1
Signature : RSA/SHA256, Fri 07 Oct 2016 07:14:15 PM EDT, Key ID b88b2fd43dbdc284
Source RPM : cairo-1.15.2-4.2.src.rpm
Build Date : Fri 07 Oct 2016 07:13:46 PM EDT
Build Host : lamb08
Relocations : (not relocatable)
Packager : http://bugs.opensuse.org
Vendor : openSUSE
URL : http://cairographics.org/
Summary : Vector Graphics Library with Cross-Device Output Support
Description :
Cairo is a vector graphics library with cross-device output support.
Currently supported output targets include the X Window System,
in-memory image buffers, and PostScript. Cairo is designed to produce
identical output on all output media while taking advantage of display
hardware acceleration when available.
Distribution: openSUSE Leap 42.2
Yup. Works through strace. I read the link provided, and agree that the nvidia driver seems suspect. Not quite sure what, if anything, I want to do about that. :disapointed:
OK. After about 6 hours of video driver hell (the source of another thread) I can report two things:
melt does not segfault on when running the nouveau video driver.
melt does not segfault if nvidia proprietary drivers are installed “the hard way”.
That latter statement is open for discussion, as I spent several hours last night trying to reinstall the repository drivers and failed for unknown reasons. But I can confirm that the proprietary drivers are installed and working now, and that melt does not segfault with the frei0r-plugins package installed:
I realized that my kids’ desktop is also running Leap 42.2 with nvidia. Proprietary G04 drivers installed from the repo and the whole system up to date. melt works fine with frei0r-plugins installed. I am now at a loss.
It seems that there is a problem with how the nvidia drivers interact with openGL. It is unclear whose fault it is. Does melt work with “strace” for you? If you type
lsmod | grep "nvidia"
do you get what I posted above?
My problem went away during a long struggle with the video drivers that started when I decided to try downgrading nvidia to G03, just to see if that would work. My computer did not respond well to that, which, combined with changes to opensuse since the last time I struggled with video drivers, had me scrambling to find a solution. The G04 drivers would happily install again, but no matter what I did, I would continue to boot to a black screen. I guess that the nvidia scripts included in the nvidia installation packages cleaned that up for me. So. A couple lessons:
Installing “the hard way” is not actually hard. I’ve done it a million times over the years. Used to do it to avoid nvidia upgrades that used to cause trouble. You just download the driver for your card from the nvidia site, make it executable, and run it as root from a console. The first challenge I had was getting a console, as in leap 42.2 that is accomplished by hitting <ctrl><alt>F1 from the login screen. Or black screen, if that’s what you have. Opensuse used to just dump you into a console by default if anything went wrong with the video drivers, so there was a learning curve there. You’ll need an ethernet cable and a router to plug it into, as you won’t have wireless in a console, and that makes using yast a problem. All my cables were in the attic and the kids were asleep. So that was just another thing. Also, the nouveau drivers are supposed to be “blacklisted” for nvidia to work, but that wasn’t getting done for some reason with any approach (one-click, simple driver install, or even “hard way”). No idea why not. I had to edit as root the /etc/modprobe.d/50-blacklist.conf file manually. Just need to add the line “blacklist nouveau” to the end. Then you run mkinitrd and reboot.
You don’t need to do any of that, apparently, as my kids’ computer has Leap 42.2 and nvidia drivers installed from the repos and works fine. It means that the method of installation and what else is being used is what matters, not the drivers. You might just try going into yast, reinstalling all the nvidia drivers, and rebooting. You might also try changing the openGL setting in “Configure Desktop”->“Display and Monitor”->“Compositor”. Log out and in after each change. That’s a long-shot, though. I tried that. I did not try simply turning the compositor off.
There is a quick and dirty solution, and that is to go into /usr/lib64/frei0r-1 and simply deleting the plugins (as root) that begin with “cairo” while waiting for an nvidia update. There are only 4 (of many), and honestly, I don’t think all of them are a problem. You can put them back by reinstalling the package. Messing with package-provided solutions is not recommended, and someone will no doubt complain that I suggested it. This is the solution for when you have totally given up.
As I can no longer reproduce the problem, I don’t have much more than the above to offer.
As I understand it, it is a problem with the order in which certain libraries are loaded.
nvidia replaces Mesa’s OpenGL libraries. To avoid problems with Mesa updates (which would again overwrite nvidia’s versions), the nvidia rpm packages install them to a different place and modify the linker search path to load them from there.
Apparently the latter is what causes the problem (this also explains why everything works if you install nvidia the hard way).
You may also try this and see whether it “fixes” the crash as well:
LD_LIBRARY_PATH="" melt xxx.mp4
(this would prevent melt from loading nvidia’s OpenGL libraries at all)
If that works, you might write a script that calls melt this way and configure kdenlive to run that instead. (running melt through strace is probably not a good idea as it would surely cause a performance loss).
Or just delete the offending plugins as suggested.
I don’t think there ever will be an update to frei0er-plugins in 42.2 that would reinstall them, and I somehow doubt that you would need/use those cairo plugins in the first place.
Thank you for sharing your issue and your fix lately.
I’ve faced the same (nvidia closed-source driver), and solved by removing frei0r-plugins package.
I don’t understand if by removing that package i’m loosing something important that worked in my past projects. I hope no.
Opensuse used to just dump you into a console by default if anything went wrong with the video drivers, so there was a learning curve there. You’ll need an ethernet cable and a router to plug it into, as you won’t have wireless in a console, and that makes using yast a problem. All my cables were in the attic and the kids were asleep. So that was just another thing. 
Also, the nouveau drivers are supposed to be “blacklisted” for nvidia to work, but that wasn’t getting done for some reason with any approach (one-click, simple driver install, or even “hard way”). No idea why not. I had to edit as root the /etc/modprobe.d/50-blacklist.conf file manually. Just need to add the line “blacklist nouveau” to the end. Then you run mkinitrd and reboot.