Kdenlive and 0.7.8 simultaneously


I'm working on Kdenlive on Kubuntu 10.4 (KDE 4.4.2) [apt-get].
Can I have both versions installed?
I've seen some posts that the new version fails on Kubuntu.


Fails on what?

Kdenlive 0.7.8 is working on Lucid Lynx using every Ubuntu spin.

Using both 0.7.7 and 0.7.8 via package is technically possible but no one has packaged that, as far as I know.

Last week, I spent a couple nights with the Kdenlive Builder Wizard shell script to make it easier to use only with bash, without Kommander. I will make it available soon. With it, it is fairly easy to create multiple versions built and usable.

Here is the bash script I mentioned. Rename it to have a .sh filename extension or no extension, and make it executable:
chmod +x build-kdenlive.
You can edit the configuration variables at the top of the script to tailor it.
By default, it downloads to and builds in $HOME/kdenlive/src.
Then, it installs to a dated subdirectory in $HOME/kdenlive.
To run, execute $HOME/kdenlive/YYYYMMDD/bin/start-kdenlive.

Thanks a lot!! :)
I have this error right now:
make[1]: Leaving directory `/home/boggiano/kdenlive/src/mlt/src/melt'
In file included from producer_avformat.c:34:
/home/boggiano/kdenlive/20101002/include/libavcodec/opt.h:32:27: error: libavutil/opt.h: No such file or directory
In file included from consumer_avformat.c:42:
/home/boggiano/kdenlive/20101002/include/libavcodec/opt.h:32:27: error: libavutil/opt.h: No such file or directory
make[2]: *** [depend] Error 1
make[1]: *** [depend] Error 1
make: *** [all] Error 1
KBWERROR: Unable to build mlt
KBWTRACE: Entering feedback_result @ = FAILURE Some kind of error occured: Unable to build mlt
KBWLOG: Process has finished. Reason: FAILURE Some kind of error occured: Unable to build mlt

There is something I can do ?

This appears to be an error in ffmpeg source repo where it is failing to install libavutil/opt.h. Unfortunately, at this time, the script does not allow you go back to a usable ffmpeg revision, even using config var FFMPEG_REVISION, due to how ffmpeg subversion trunk always pulls the head of the linked libswscale repository. We either have to wait for ffmpeg fixes, or I need to modify the script to support subversion branches/tags. I will try to provide updated comment soon.

Thanks a lot!!
Not in a hurry! ;)

I filed a bug for it. I am surprised it has not been addressed. I am not sure what it means.

The issue in ffmpeg is fixed now. Please give it a shot.

Is this build-kdenlive.txt a command line replacement for the now defunct Builder Wizard or is it the same Builder Wizard run from the command line?


Hi Dan,

I ran the build-kdenlive script successfully on an Ubuntu 10.04 box (32-bit). Unfortunately when I launch the new Kdenlive I'm informed that the MLT version (0.5.5) is unsupported. Running 'ldd kdenlive' reveals that the binary correctly depends on the locally-built libmlt and libmlt++.

What am I missing ?



You must run the script bin/start_kdenlive, not bin/kdenlive.

Got it, thanks. Kdenlive starts up fine now, I'm looking forward to working with the new features.



Hi Dan,

today I tried to compile kdenlive with the shell script, but I failed because the script was not able to identify the running KDE version.
The reason was:

Running "kde4-config -v" in a regular bash gives the expected:
Qt: 4.6.3
KDE: 4.5.3 (KDE 4.5.3) "release 1"
kde4-config: 1.0

But embedded in the script "kde4-config -v" gives back:
Qt: 4.6.3
KDE Development Platform: 4.5.3 (KDE 4.5.3) "release 1"
kde4-config: 1.0

Therefore I had to change in the function "test_kde4_available" the line:
>> KDE_VER=`kde4-config -v | grep -i KDE: | awk '{print $2}'` to
>> KDE_VER=`kde4-config -v | grep -i "KDE Development Platform:" | awk '{print $4}'`

BTW: This is exactly what's coded in the wizard ( script.

CU Tom

Trying to update my version of kdenlive.
Ran the build-kdenlive script and got this error

KBWTRACE: Entering cmd @ = git --no-pager clone git://review.webmproject.org/libvpx.git
KBWLOG: About to run command: git --no-pager clone git://review.webmproject.org/libvpx.git
/usr/local/bin/build-kdenlive.sh: line 260: git: command not found
KBWERROR: Unable to git clone source for libvpx from git://review.webmproject.org/libvpx.git
KBWTRACE: Entering feedback_result @ = FAILURE Some kind of error occured: Unable to git clone source for libvpx from git://review.webmproject.org/libvpx.git
KBWLOG: Process has finished. Reason: FAILURE Some kind of error occured: Unable to git clone source for libvpx from git://review.webmproject.org/libvpx.git

Any ideas


If you can not understand "git: command not found", then this build script is not for you, and you should just use the Linux provider's binary packages.

Using the build script all seemed to be going well until I hit this problem building mlt:-


The errors all appear on what appear to be compiler conditional (#if lines) - but my programming skills are minimal!

I am building in Mandriva 2010.2 x86_64, any ideas?

OK it's fixed - I was missing libsox-devel

Since ffmpeg moved their source repository to git on 17/1/2011 the above script is broken.
I have updated it to use the correct repository and git for ffmpeg and this is now here:-


If you have an existing ffmpeg svn checkout (i.e. you have used the old script previously) you will need to delete or rename ~/kdenlive/src/ffmpeg before re-building with the new script.

I hope that saves someone some time and head scratching :-)

I have two versions installed, 078 from binary repository in /usr/... and the newest compiled from source in ~/kdenlive...

The problem is, there seems to be some interaction between the two. If I run one and then the other, I am always presented with the wizzard saying "Your Kdenlive has been updated to version...." (even if it is a downgrade)

I noticed that the compiled version in "Settigs/Configure/Environment" had everything (like melt path) still pointing to /usr/..., although the compile script generated everything in ~/kdenlive/....
I changed these things to point to the local directories, but still have this.

Also, the local version still seems to use the effect xml files in /usr/share/kde4/apps/kdenlive/effects rather than in ~/kdenlive/20110416/share/apps/kdenlive/effects, because the new effects don't show their parameters as expected. Also, the effects with changed names appear twice, like "Contrast" and "contrast0r" are both present.
Also, no on-screen controls for corners and rotoscoping (only three parameters in rotoscope effect)

Where do I tell Kdenlive where to look for these?

I looked into the start_kdenlive script, and it sets the frei0r path to both local and /usr. Removed the /usr /opt etc stuff, but no change.

The stuff in ~/.kde4/share/apps/kdenlive is probably not the problem?

How can I make each version to be completely isolated from the other?

P.S. In the mean time I compiled V 0.8 too, same problem.

OK, I think the reason that the wizzard comes up is the ~/.kde4/share/config/kdenliverc
I guess this has to be in ~/ so no way of isolating the two versions in this respect?

Also solved the doubled effects problems by renaming /usr/share/kde4/apps/kdenlive/effects to /usr/share/kde4/apps/kdenlive/OLDeffects

Now, in the compiled version the effects are listed only once, under their new names, and Corners has on-screen controls.

However, this also causes the old version (in /usr...) to loose most of the effects.

I can live with that, but still, is there a way to tell Kdenlive where to look for the effect .xml files? I did change the FREI0R_PATH in the startup script, but it did not help.

Another problem that remains is that rotoscoping still only has three parameters (Invert, Feathering and Feathering passes) and no on-screen drawing is possible.

I don't know about the issues between to installed versions.

But does a XML description of the rotoscoping effect exist?
If yes, is Kdenlive compiled against QJSON?

I think the only way to get isolation is to not have one installed in system (/usr). Beyond that, they will share a common local configuration settings, which we can not really do anything about. Unfortunately, that is storing the path to melt for rendering, and it is important to change that when switching versions.