Anyone trying Kdenlive5 on TW with Plasma5? Seems to install fine (from Wolfie323:Frameworks:TW) and the libmlt and LADSPA pkgs installed fine as well. I get segfault QObject failure from konsole.
It doesn’t start here as well (on 13.2) and always did. When I first added it to my repo, it showed a dialog to select the mlt profiles folder at least, but crashed afterwards, now it crashes immediately.
Just be patient, the KF5 port doesn’t work yet…
Forget my previous comment.
kdenlive5 starts fine and seems to work, I haven’t really tested it yet though.
The crash is caused by libmlt’s qt module, which uses Qt4 and makes kdenlive load both Qt5 and Qt4 causing the crash.
Remove /usr/lib64/mlt-6/libmltqt.so as a workaround (or move it out of the directory, just renaming it won’t help).
Still segfaulting with:
(unknown:0) - QObject::connect: No such slot Bin::showClipMenu(QString)
Segmentation fault
Not in a rush, so I can wait. Any indication if the port will come with the first KDE Applications drop? Seems like minimal info over on the KDE forums…
Are you sure you removed /usr/lib64/mlt-6/libmltqt.so?
That’s exactly the output I get when it is there.
If yes, try to run it in gdb and type “bt” to get a backtrace. If libmltqt.so is present it will crash inside libQtCore.so.4 (i.e. libqt4)… 
Without libmltqt.so, it runs fine here on 13.2. I have yet to try on Tumbleweed.
Not in a rush, so I can wait. Any indication if the port will come with the first KDE Applications drop? Seems like minimal info over on the KDE forums…
kdenlive is not and never was part of the KDE releases. They have their independent release cycle.
I have no idea when they will release the first KF5 based version though.
But apparently there are intentions to make it part of the KDE Applications 15.04 release (scheduled for April):
http://mail.kde.org/pipermail/kdenlive/2015-January/008393.html
Okay, verified removed the libmltqt.so (to my home folder and renamed it), here she goes gdb run:
Program received signal SIGSEGV, Segmentation fault.
0x00007fffd0540f1c in ?? () from /usr/lib64/libQtTest.so.4
…and the bt
(gdb) bt
#0 0x00007fffd0540f1c in () at /usr/lib64/libQtTest.so.4
#1 0x00007ffff7deaaaa in call_init.part () at /lib64/ld-linux-x86-64.so.2
#2 0x00007ffff7deab93 in _dl_init_internal () at /lib64/ld-linux-x86-64.so.2
#3 0x00007ffff7deed58 in dl_open_worker () at /lib64/ld-linux-x86-64.so.2
#4 0x00007ffff7dea964 in _dl_catch_error () at /lib64/ld-linux-x86-64.so.2
#5 0x00007ffff7dee54b in _dl_open () at /lib64/ld-linux-x86-64.so.2
#6 0x00007fffebd5502b in dlopen_doit () at /lib64/libdl.so.2
#7 0x00007ffff7dea964 in _dl_catch_error () at /lib64/ld-linux-x86-64.so.2
#8 0x00007fffebd555dd in _dlerror_run () at /lib64/libdl.so.2
#9 0x00007fffebd550c1 in dlopen@@GLIBC_2.2.5 () at /lib64/libdl.so.2
#10 0x00007fffd3799ae1 in mlt_register () at /usr/lib64/mlt-6/libmltfrei0r.so
#11 0x00007ffff4ee9ccd in mlt_repository_init () at /usr/lib64/libmlt.so.6
#12 0x00007ffff4ee94c0 in mlt_factory_init () at /usr/lib64/libmlt.so.6
#13 0x00007ffff4cb7d9b in Mlt::Factory::init(char const*) () at /usr/lib64/libmlt++.so.3
#14 0x0000000000912fcd in ()
#15 0x00007fffffffc510 in ()
#16 0x0000000000fd6130 in ()
#17 0x0000000000000028 in ()
#18 0x00007ffff102385d in operator new(unsigned long) () at /usr/lib64/libstdc++.so.6
#19 0x000000000098ca2d in ()
#20 0x0000000000dad980 in ()
#21 0x0000000000de96e0 in ()
#22 0x00007ffff15fc7e0 in QArrayData::shared_null () at /usr/lib64/libQt5Core.so.5
#23 0x00007ffff102385d in operator new(unsigned long) () at /usr/lib64/libstdc++.so.6
#24 0x000000000098c983 in ()
#25 0x0000000000de96a0 in ()
#26 0x0000000000dad980 in ()
#27 0x0000000000dad980 in ()
#28 0x00000000005746c0 in ()
#29 0x00007fffffffd200 in ()
#30 0x00000000009329da in ()
#31 0x00007ffff12d7e48 in () at /usr/lib64/libQt5Core.so.5
#32 0x0000000000000000 in ()
(gdb)
Looks like it’s trying to also load
libQtTest.so.4??
Yes.
But in your case it seems to be loaded by libmltfrei0r.so or (more likely) a frei0r plugin maybe.
Indeed, I can reproduce your crash (with exactly the same backtrace) by installing frei0r-plugins here.
So either uninstall frei0r-plugins, or remove /usr/lib64/mlt-6/libmltfrei0r.so as well.
According to ldd the affected plugins are facebl0r.s and facedetect, so you might try to remove those instead too. (they are in /usr/lib64/frei0r-1/)
Yup, thx, just figured it out… runs now on TW/Plasma5…at least enough to play with.
Sorry for the delay, but I finally fixed these issues yesterday.
The latest libmlt version (0.9.6) can be built against Qt5, so I added it to my repo (built with full ffmpeg and vidstab suppport ).
I changed the soversion number to 60 instead of 6 (so the packages as called libmlt60, melt60, and so on) to make it co-installable with the Qt4-based package.
I also added a conflict to frei0r-plugins to libmlt60-modules (the standard package actually recommends it), to prevent the crash caused by those. Maybe I can still find a better solution for that though, like building frei0r-plugins against Qt5 too…
So it should work now without removing files. You might have to set the mlt profiles path correctly (to /usr/share/mlt-60/profiles/) in kdenlive5’s settings though, or just remove the config (~/.config/kdenliverc) to reset it to the default.
Got it. Very nice, thx. The basics seem to be okay so far, though I have some source videos that are failing to import (worked fine before), so I’ll try to track that down and report it if needed. I see it’s become a full-on KDE app now, just excellent news all the way around for KDEnlive users.
Check that you have ffmpeg from Packman installed, i.e. the libav* packages, libavcodec56 in particular.
I only have a crippled ffmpeg in my repo. It isn’t published for Tumbleweed, but IIRC it was at the beginning for a short time.
A zypper dup should install the one from Packman though, as I did remove the published packages (for Tumbleweed/Factory, I do keep them for 13.1/13.2 so that even people not using Packman can install my packages, with restricted codecs support).
I see it’s become a full-on KDE app now, just excellent news all the way around for KDEnlive users.
Right, even though not too long ago everybody seemed to think kdenlive is dead…
And I do have the stable 15.04 version now in my repo, as you probably noticed, and will follow the stable releases.
Yeah, I run my own ffmpeg (10bit) and I just noticed that all of my sources are failing to import, so it must be the codec setup…This might require a little finesse.
Yes, I did, very nice, indeed.
Which version is that?
I build against the latest (in Packman and Tumbleweed/Factory) 2.6.1.
So my libmlt loads libavcodec.so.56, libavutil.so.54, and so on.
Source and binaries from here.
I need 10bit. Actually, now that I think about it, perhaps we should request packman to build a 10bit version too?
That’s a statically linked ffmpeg executable.
But mlt/kdenlive does not run ffmpeg, it uses ffmpeg’s libraries (e.g. libavcodec) to import/export files.
If you don’t have them from Packman, you probably use the crippled ones included in Tumbleweed now.
There’s no way to make mlt or kdenlive to use that static ffmpeg executable, for the clip import to kdenlive at least.
I need 10bit. Actually, now that I think about it, perhaps we should request packman to build a 10bit version too?
Would probably be the best idea.
Would that be incompatible or cause problems with the current version? I have no idea what that 10bit implies…
Or build ffmpeg (dynamically linked) yourself. You can use the openSUSE (it is included in the distribution since recently, crippled of course, but you only need to set a flag to build the full version) or Packman src.rpm and modify the build options accordingly.
Yes, I should’ve explained further…I’m using the Packman FFmpeg for import (I hope) and that static linked ver for render (you can set that in settings/config/options/ffmpeg in the MLT section).
10bit refers to the encoder output (vs. 8bit which has been standard for years).
Yes, that would be a good “starter” to learn to use OBS…
Well, I have never tried that, but at least the import should work then if your input files are supported by the system’s ffmpeg libs.
I haven’t encountered any problems importing any video files I tried (even real video) here on 13.2 yet, with Packman’s ffmpeg packages.
So again, check that all libav* packages come from Packman, maybe run a “zypper dup --from Packman”.
10bit refers to the encoder output (vs. 8bit which has been standard for years).
Ah, ok. So it refers to the color depth, ten “bit per color” (red, green, and blue).
Still, the question is, is that a configurable run-time option, or does ffmpeg then use 10bits unconditionally?
In the latter case it’s probably no option to offer it on Packman…
And is the output compatible to a non-10bit ffmpeg, i.e. can a “normal” ffmpeg read those files? I suppose yes, it sounds like you had that working before (with kdenlive/KDE4 I suppose), correct?
Yes, that would be a good “starter” to learn to use OBS…
Well, the problem is just that a fully blown ffmpeg is not allowed on OBS.
You could build one in your home repo, but it might happen that you’re asked to remove it again.
Other than that, it shouldn’t be too difficult. Just branch the one from multimedia:libs, openSUSE:Factory, or my repo, and add the corresponding switches to configure (I guess). What exact parameters you need for adding 10bit support I don’t know though, and I don’t find any that sound like that. Or is this added by a patch?
In this particular case you’d also have to enable the build of the restricted codecs, by defining the macro BUILD_ORIG. You can either do that in the project config (ask for details if you need help), or by adding a “%define BUILD_ORIG 1” at the top of the spec file.
PS: judging from the readme file of the tarball you linked to earlier, this 10-bit support seems to be specific to the AVC/H.264 encoder:
Notes: ffmpeg-10bit is built with 10-bit AVC/H.264 encoding support.
I remember that Packman enabled 10bit support for x264 some time ago, but there were problems so it got disabled again.
I have to look that up…
I just noticed that my libmlt actually failed to build for Factory/Tumbleweed. So the package in my repo actually has no support for ffmpeg at all, which of course explains why your import is not working…
Sorry! :shame:
I will fix it shortly…
Btw, I had a look at frei0r-plugins, and Qt actually only gets pulled in via opencv. Building against my Qt5-based opencv should fix that too. I already created a patch for installing the actual plugins to a different directory…
libmlt in my repo is now built with ffmpeg support for Factory/Tumbleweed too.
So update your system and try again, it should work now for you.
The problem was that OBS couldn’t decide between libav and ffmpeg (both are part of the distribution now), so I had to explicitely tell which one I want.
frei0r-plugins will still take a while, unfortunately my patch to install the plugins to a different directory is apparently not working. I have to investigate a bit more…
So for now, my libmlt still conflicts with frei0r-plugins.
My libmlt now only uses my new package frei0r-plugins-qt5 (built against Qt5) and ignores frei0r-plugins.
So kdenlive5 does not crash when the latter is installed, and you can still use the frei0r-plugins.
The problem was that I misunderstood how frei0r-plugins works. There is no library, the application (libmlt in this case) that wants to use the plugins loads them directly. So I had to patch libmlt to use the new plugin path (/usr/lib(64)/frei0r-plugins-qt5-1). (Actually I noticed now that patching it would not really have been necessary, you can specify the default path via an environment variable when building it. I probably will change that, but that has no effect on the resulting package anyway…)
Btw, I changed all locations of the default path, so if you happened to have a custom plugin in e.g. $HOME/.frei0r-1/lib it will not be found any more (you have to move/copy it to $HOME/.frei0r-qt5-1/lib)