maybe this helps trying to render to png:

(gdb) backtrace
#0 0x00007fffd7d2f850 in ?? ()
#1 0x00007fffd6f2e54e in av_lockmgr_register () from /usr/lib/libavcodec.so.54
#2 0x00007ffff2895e51 in __run_exit_handlers () from /usr/lib/libc.so.6
#3 0x00007ffff2895ed5 in exit () from /usr/lib/libc.so.6
#4 0x00007ffff287fa1c in __libc_start_main () from /usr/lib/libc.so.6
#5 0x0000000000455ef1 in _start ()

I have a larger project in the pipe and I cannot render it due to this bug.

The bug - as described by the previous posters can be confirmed rendering ANYTHING using kdenlive or mlt directly. I can also confirm it on two machines - both running x86_64. I have checked pacman.log and I can confirm rendering was still working until March 2nd (was th elast time I rendered). After that it stopped. I downgraded mlt and ffmpeg (kdenlive was not updated after this date) but that did not help. The problem persists.
So it has to be connected with something else that has been upgraded at this point. But I can't put my finger on it.

Pleas elet me know if there is something I can do, can test or something. Otherwise I have to *ugh* change the distribution to finish my projects.

kdenlive crashes for me during shutdown. haven't used it much, so can't say if it would crash during use, too. (well, it usually does, sooner or later, doesn't it?)


rendering some random, short video shows an error, but the video seems to be ok:

"Rendering of /home/phani/kdenlive/untitled.avi aborted, resulting video will probably be corrupted."


KDE crash handler gives me the follwoing output after it crashes during shutdown:

Application: Kdenlive (kdenlive), signal: Segmentation fault
Using host libthread_db library "/usr/lib/libthread_db.so.1".
[Current thread is 1 (Thread 0x7f3b0685f780 (LWP 4713))]

Thread 3 (Thread 0x7f3acb22d700 (LWP 4721)):
#0 0x00007f3b012cdfad in poll () from /usr/lib/libc.so.6
#1 0x00007f3afe6deb14 in ?? () from /usr/lib/libglib-2.0.so.0
#2 0x00007f3afe6dec34 in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0
#3 0x00007f3b03588b86 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4
#4 0x00007f3b035593ff in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4
#5 0x00007f3b03559688 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4
#6 0x00007f3b0345a8a0 in QThread::exec() () from /usr/lib/libQtCore.so.4
#7 0x00007f3b03539bbf in ?? () from /usr/lib/libQtCore.so.4
#8 0x00007f3b0345d87c in ?? () from /usr/lib/libQtCore.so.4
#9 0x00007f3b031cde0f in start_thread () from /usr/lib/libpthread.so.0
#10 0x00007f3b012d6efd in clone () from /usr/lib/libc.so.6

Thread 2 (Thread 0x7f3ada10e700 (LWP 4790)):
#0 0x00007f3b031d1954 in pthread_cond_wait@@GLIBC_2.3.2 () from /usr/lib/libpthread.so.0
#1 0x00007f3b04df57a7 in ?? () from /usr/lib/libQtScript.so.4
#2 0x00007f3b04df57d9 in ?? () from /usr/lib/libQtScript.so.4
#3 0x00007f3b031cde0f in start_thread () from /usr/lib/libpthread.so.0
#4 0x00007f3b012d6efd in clone () from /usr/lib/libc.so.6

Thread 1 (Thread 0x7f3b0685f780 (LWP 4713)):
[KCrash Handler]
#5 0x00007f3af12f9850 in ?? ()
#6 0x00007f3af053a69e in av_lockmgr_register () from /usr/lib/libavcodec.so.54
#7 0x00007f3b01225e51 in __run_exit_handlers () from /usr/lib/libc.so.6
#8 0x00007f3b01225ed5 in exit () from /usr/lib/libc.so.6
#9 0x00007f3b0120fa1c in __libc_start_main () from /usr/lib/libc.so.6
#10 0x0000000000455ef1 in _start ()

The rendering crash error is also the same as this one:

#5 0x00007f3af12f9850 in ?? ()
#6 0x00007f3af053a69e in av_lockmgr_register () from /usr/lib/libavcodec.so.54
#7 0x00007f3b01225e51 in __run_exit_handlers () from /usr/lib/libc.so.6
#8 0x00007f3b01225ed5 in exit () from /usr/lib/libc.so.6
#9 0x00007f3b0120fa1c in __libc_start_main () from /usr/lib/libc.so.6
#10 0x0000000000455ef1 in _start ()

which I could confirm by running melt with gdb.

Oh yes I forgot: you CAN do a simple render: 1-pass. Melt will still crash after being done but the video MIGHT be okay. However every time two render instances are required, the video will be corrupt.

Seems like this bug is actually related to the mlt package. A user on the mlt bugtracker traced it down and hacked together a quick fix:
http://sourceforge.net/p/mlt/bugs/192/

I just tested that after rebuilding mlt with the patch. With a 5-second video rendered in one pass, two pass, via kdenlive directly and via mlt script (generated within kdenlive). And the crashes are gone for me now. May I suggest adding this into a mlt 0.8.8-4 release until the bug is fixed upstream? Because as it is right now mlt is useless when used in multipass rendering.

I just posted a more elaborate explanation of the problem on http://sourceforge.net/p/mlt/bugs/192/. Basically both OpenCV 2.4.4 and mlt call av_lockmgr_register.

The patch I wrote fixes the problem, but a better solution might be required at some point.

pleas try mlt-0.8.8-4