Hi together,

I was away for over a half year from video editing. Wow, there are a lot of new features in Kdenlive & MLT!
Respect!

I've trouble with old project files e.g. from Kdenlive 0.7.8 in Kdenlive 0.8!
Some transitions won't be rendered correctly. There is a little gap or they are on a wrong position.
I'm using the release versions (Kdenlive 0.8 & MLT 0.7.2, all build from source) with DNxHD .mov manual proxy clips. In Kdenlive's Project-Monitor all is ok.

In the Bugtracker and Changelog's I noticed, that there are different regarding bug's fixed since the last major release. So I tried to build Kdenlive & MLT from svn/git (4th July 2011). With this builds, a wizard has corrected some clip lengths and I was able to move all clips and transitions to its correct position again. There is also a new project file version level. The problem is, that rendering (melt) is permanently failing with a segmentation fault.

Can anybody tell me, which version I should use a) to fix old projects and b) to start new projects and to be sure that such problems won't come up in the future? Last MLT major and Kdenlive from svn? In future I'll use the new internal proxy file feature for new projects.

Thanks
Christian

Is it the case that one whole track has been moved by one or two frames? If yes, the best way to fix this is to edit the .kdenlive file (make a backup before) and insert or remove the frames there. The other way to fix this is to move everything by hand, or actually, with the current version you can also just lock the correct tracks and move the clips on the bad track with the spacer tool. This would be much easier.

I assume I have trouble with clip length too, because the gap size I've to correct increases when I work from the beginning till the end.
To correct this, I've to spend time for it. It's annoying but it's ok.

The Problem is, that Kdenlive&MLT last release version is showing all correct in the timeline and when I play the project in Kdenlive there is also all ok. But the rendered output isn't ok.

With Kdenlive & MLT newest SVN/GIT version I can see the mistakes also in the timeline and I can fix all. But this release is quite unstable because segmentation faults appears (rendering) and some transitions disappears in the rendered output.

At the moment I'm unsure if there is all ok with Kdenlive & MLT?

Next is to test with a new generated project... but is the last major release bug-free enough? What happens, when the next versions are released? Are there with 0.8 generated project's also corrupt? It seems to be so, when I take a look to current SVN/GIT release.

Check whether your SVN is actually using MLT from the previously-installed version due to KDE defaults. Look at bug 2190:
http://www.kdenlive.org/mantis/view.php?id=2190

Ok, thanks for this information. I'm not so deep experienced with Linux, but I understand your reported bug. Actually I use x264, ffmpeg, mlt and kdenlive from ~/opt (all compiled from source). I use openSuse 11.4 x64 with packman repo and only the binaries from x264 and ffmpeg are also present. Every time I deal with different versions I'm building all in this explicit order: x264, ffmpeg, mlt, kdenlive.
I don't use the buildscript.

In my .profile there are these environment settings:
I use --prefix=$HOME/opt when configuring the packages.
#Mods for Kdenlive with mlt lib64
export PKG_CONFIG_PATH="$HOME/opt/lib64/pkgconfig:$HOME/opt/lib/pkgconfig:$PKG_CONFIG_PATH"
export LD_LIBRARY_PATH="$HOME/opt/lib64:$HOME/opt/lib:$LD_LIBRARY_PATH"
export PATH="$HOME/opt/bin:$PATH"
#This is for ffmpeg to find x264 because ffmpeg isn't using pkg config.
export CFLAGS="-I$HOME/opt/include $CFLAGS"
export LDFLAGS="-L$HOME/opt/lib64 -L$HOME/opt/lib $LDFLAGS"
#export MLT_FREI0R_PLUGIN_PATH=$HOME/opt/lib/frei0r-1

Is my system also affected from your reported bug, when I change permanently between different versions compiled myself?

With current SVN/GIT versions, rendering crashes at the end of each pass but I can play the file.

Btw. I render kdenlive projects direct with melt using verbose settings to have all informations.
(A half year ago I've found a bug in libavcodec)

I assume you are rendering to H.264 since you mentioned x264 as part of your build setup?
On July 4, in MLT, I was testing and debugging issues with the latest release versions from libav.org and ffmpeg.org. I made some changes that day, and you might have caught it at a bad time:


commit 90c1e74e21d563e0c8ba4a92bb0a31a3b264edd1
Author: Dan Dennedy
Date: Mon Jul 4 20:57:58 2011 -0700

Fix crash in consumer on FFmpeg v0.8 and later.

commit 39376e84868c2ca62daacce5a9c78399745cbbb8
Author: Dan Dennedy
Date: Mon Jul 4 19:40:15 2011 -0700

Revert "Temporary fix for new crash when closing codec."

This reverts commit d04be23b0519f80fe2002dbef5239ca326fd2a1d.

Yes, I render to x264.

Yesterday I did a test with a new small project in new and clean environment.
With kdenlive & mlt from svn/git of 10th July I get only an segfault at end of each pass and also when I start melt from shell without any parameters. I assume this is the open qt bug?

Dan, please could you provide me a new command line example(mlt 0.7.3), how to render a kdenlive project direct with melt from the shell?
(With verbose, input is the kdenlive project, with atsc 1080i 50 profile, output to a file. Don't waste time with detailed avformat/codec options)

My old script isn't working proper anymore. Yesterday I tried myself to find out the correct syntax, but with no success.
I get error messages like "can't open atsc_1080i_50" or I get the output direct on my screen...

Btw. first step is to generate the render script and mlt file with kdenlive render gui to have the original input files instead of the new proxies.
Or is it possible to provide kdenlive renderer a verbose parameter?

I will watch the x264 codec messages.

I got it. Kdenlive renderer shows in the console window a complete working set of melt options between the 2nd "" while rendering. With this, I can do it all on command line. After the first segfault at pass 1 I can go ahead with pass 2.

Does anyone know, when this segfault (I assume this is the Qt bug, which is described on bugtracker) has been solved? I use openSuse 11.4 x64.