View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000180KdenliveMLTpublic2008-10-04 19:462008-11-12 23:00
Assigned To 
PlatformOSOS Version
Product VersionRecent git 
Target Version0.7.0Fixed in Version0.7.0 beta 
Summary0000180: linux freezes totally when trying to render a project
Descriptionbuilt kdenlive using the kdenlive builder wizard 0.5 .
Working in kdenlive works great.
When trying to render a project my linux freezes completly (only powering off my box gets me out of this situation - which means reboot)

I run ubuntu studio with kde 4.1
Linux woplin 2.6.24-19-rt #1 SMP PREEMPT RT Sat Jul 12 02:53:01 UTC 2008 i686 GNU/Linux
cat /etc/*elease

I tried to start in debugging mode, but i do not know where the debugging file is written.
Additional Informationffmpeg: rev. 15553
mlt/mlt++: rev. 1183
kdenlive: rev. 2430
TagsNo tags attached.
Build/Install Method
Attached Filesgz file icon debugging_output.tar.gz [^] (9,383 bytes) 2008-10-08 08:54

- Relationships

-  Notes
administrator (administrator)
2008-10-05 01:18

Could you please try to run MLT's command line player to see if it also freezes your system (sorry about that...) ?

From a terminal, type:

inigo myvideo.mpg -consumer avformat:test.mpg

inigo should be installed in the same place as kdenlive, give one of your video file as input (myvideo.mpg), and it will create a copy of it named test.mpg

If it takes all resources, please try this:

inigo myvideo.mpg -consumer avformat:test.mpg real_time=0

Let me know the result
madsdyd (administrator)
2008-10-06 22:03

If you use the kdenlive_start script created by the wizard, it will most likely write its log output to /tmp/kbw.gdb.output.XXXXXXXX, where XXXXXXX varies. This is only in debug mode.

Do a ls -ltr /tmp/kbw* to see the files that the wizard builds.

The kdenlive_start script will only show the log, if it detects a crash, not a hang. If your computer really hangs, there is actually no way to restore the log file, because your /tmp directory will (most likely) by wiped clean during boot... :-(

I will think about improving the startup script, but it is kind of a hard nut. Are you sure it is not only your X session that hangs? What does ctrl+alt+backspace do?
wopeer (reporter)
2008-10-08 08:22

Thanks for the quick response:
this is the output of
wolfgang@woplin:~/video$ inigo untitled.mpeg -consumer avformat:test.mpg
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+
|1=-10| |2= -5| |3= -2| |4= -1| |5= 0| |6= 1| |7= 2| |8= 5| |9= 10|
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+
| H = back 1 minute, L = forward 1 minute |
| h = previous frame, l = next frame |
| g = start of clip, j = next clip, k = previous clip |
| 0 = restart, q = quit, space = play |
Floating point exception

This is what mplayer tells about this video file 'untitled.mpeg'
Playing untitled.mpeg.
MPEG-PS file format detected.
VIDEO: MPEG1 720x576 (aspect 8) 25.000 fps 0.0 kbps ( 0.0 kbyte/s)

(should be PAL-DVD created with kdenlive svn-0.6)

Sadly , its not only the X-session which hangs. I tried switching to a different terminal but even the keyboard gives no more response.

Hope this helps a little.
wopeer (reporter)
2008-10-08 08:53

I managed to write the debugging output into a different directory.
(just added -p <mydirectory> to mktemp command in startscript)
I upload this output to this record. I added also the file mplayerout.txt which contains some video info about the clips i am using (this should be mpeg4 files from my tiny video camera with extension ASF - ffmpeg and even mplayer have no problems with this files , and also kdenlive works with this files on the timeline without problems)
I also tried to convert this files to .dv format - but in that case i cannot playback them in kdenlive -> this means just the 1 frame is displayed but i can hear the audio of the clip.
i used mencoder to convert to dv format:
mencoder -oac pcm -ovc libdv -o $i.dv $i

Pls. let me know if the ASF-format might be the problem, then i will try to convert my clips to different format.
Thank you!
administrator (administrator)
2008-10-08 10:12
edited on: 2008-10-08 12:06

From the output of inigo, it looks like you are having the same issue as described in bug 183.

Could you try to revert your FFmpeg svn to revision 15261 and see if it fixes the problem ? I think you can select a revision in the builder wizard, otherwise do the following commanf in the ffmpeg directory:

make clean; svn up -r 15261;make install

After that, the inigo command from my previous command should work, it will then be interesting to see if the freeze is still here.

EDIT: I just fixed the rendering crash in MLT, so all you need to do is run the builder wizard to update to the last revision and recompile to see if freeze is still here. thanks

wopeer (reporter)
2008-10-08 21:06
edited on: 2008-10-09 08:26

thanks for the feedback.
i rebuilt ffmpeg with svn rev. 15261 .
Now the inigo command worked , but during the run of inigo the system load went to 100% so,that nothing else could be done, as long as inigo finished.
i also tried with option real_time=0 but with, lets say, no difference.
the i tried "inigo --help" which again froze my linux , so i had to reboot again (which means power off the box).
I have the feeling , that the main problem is that inigo takes all system resources during rendering. Since the rendering process may take some while nothing can be done during that time .
I can imagine that this wont be such a problem on a dual core , but on a single core , as mine, this stops me from doing anything during rendering :-S

Could it be possible that my 'RealTime Kernel' might cause this problem? Since i am also sometimes using JACK i installed 'ubuntu studio' which comes with a realtime - kernel.

administrator (administrator)
2008-10-10 13:05

I am posting your infos on the mlt-devel mailing list. Dan Dennedy who is MLT's maintainer has probably a better understanding of this problem...

gsking1 (reporter)
2008-10-11 04:50

I was having this problem last month and resolved it. It may be due to either the ubuntustudio realtime kernel or other priority settings below. First I changed back to the generic kernel in ubuntu and checked some of the custom settings I had made in /etc/security/limits.conf
I commented out the following lines which I've used for audio programs in the past. They were causing crashes because inigo would completely use all processor and then X and other things would lock up.
#@audio - rtprio 99
#@audio - nice -19
Hope this helps.
It's running nicely now.
nadavkav (reporter)
2008-10-12 21:35

i use debian sid (as root) and i experience the same issues

i used to have kdenlive 0.5 from debian's official unstable repositories
and now i have 0.7beta1 from svn (compiled it myself) and i am
experiencing the same issue with the system that is almost hanged.
the mouse barely moves until the render process is gone, it takes
the entire cpu resources.

kernel 2.6.26-1-amd64
mlt 0.3
ffmpeg -version
FFmpeg version SVN-r13582, Copyright (c) 2000-2008 Fabrice Bellard, et al.
  configuration: --prefix=/usr --libdir=${prefix}/lib --shlibdir=${prefix}/lib --bindir=${prefix}/bin --incdir=${prefix}/include/ffmpeg --enable-shared --enable-libmp3lame --enable-gpl --enable-libfaad --mandir=${prefix}/share/man --enable-libvorbis --enable-pthreads --enable-libfaac --enable-libxvid --enable-postproc --enable-libamr-nb --enable-libamr-wb --enable-x11grab --enable-libgsm --enable-libx264 --enable-liba52 --enable-libtheora --extra-cflags=-Wall -g -fPIC -DPIC --cc=ccache cc --enable-swscale --enable-libdc1394 --enable-nonfree --disable-mmx --disable-altivec --disable-stripping --enable-avfilter --enable-libdirac --disable-decoder=libdirac --enable-libschroedinger --disable-encoder=libschroedinger
  libavutil version: 49.7.0
  libavcodec version: 51.58.0
  libavformat version: 52.16.0
  libavdevice version: 52.0.0
  libavfilter version: 0.0.0
  built on Jul 7 2008 23:19:26, gcc: 4.3.1
FFmpeg SVN-r13582
libavutil 3213056
libavcodec 3357184
libavformat 3411968
libavdevice 3407872
ddennedy (developer)
2008-10-13 18:53

I can not comment at this time on the side effects when using the ubuntustudio realtime kernel. If the situation gets dire or this is resolved to just being an issue with that sort of kernel config, then I will take a look at it. Also, I will fix inigo so it will show usage info with -h or --help. Now, onto the real issue "inigo takes all system resources during rendering..."

First off, one must qualify "resources." That could mean CPU, memory, file handles, processes (threads). I have seen systems become very unresponsive when all memory is consumed due to the system paging - what I call the "death spiral." :-) More often than not, if that is the problem, then there is a bug or design flaw. Let's rule that out - let me know if that is the problem rather than CPU; it should be very obvious. If the file handle or process count is exceeded, then it would just segfault - I doubt that is it. All hints here suggest CPU consumption. Well, that is by design. Any well written program that is not bound by I/O (including user interface events) will utilize the CPU as much as possible. Of course, it is more noticeable with a long running process like video rendering. It is not the role of inigo to intentionally slow itself down with sleep calls. In short, you should be calling inigo or kdenlive_renderer with "nice."
wopeer (reporter)
2008-10-14 02:09

I just did some additional testing. I installed the ubuntu 'generic' kernel image version "2.6.24-19-generic ".
after that i commented out the line
"@audio - rtprio 99 "
in my /etc/security/limits.conf as suggested by 'gsking1' .
With this changes inigo works fine from commandline and from kdenlive rendering - it still takes 95% CPU but i can still work during the rendering :-)

What i did not try was , how this limits-changing affects the realtime kernel (maybe it works now with that image too).

Thank you for your help!
nadavkav (reporter)
2008-10-17 13:10

i tried to pass inigo the real_time=0 param but with no help.
when i run inigo from the cli it works fine... not hugging the system.
(it seem to take 80% cpu, rendering the video and displaying it)
i use a regular / generic debian sid kernel not a realtime kernel
and i did not change the /etc/security/limits.conf file.
tried to nice the inigo process, but no good :-(

the entire system is not responsive, until the rendering process is finished
aspiers (reporter)
2008-10-20 13:31

I also see this on Fedora 9 (with some 10/rawhide) and latest kdenlive, mlt etc. from svn. System almost completely freezes until the rendering is finished.
aspiers (reporter)
2008-10-20 14:45

I had a closer look and it's happening because inigo (the renderer) sets itself to SCHED_FIFO priority -99, so the scheduler gives it precedence over pretty much everything on the system. I have no idea why the author made it do this - it seems crazy to me. Fortunately it's easily fixed with the following patch:

Index: src/inigo/inigo.c
--- src/inigo/inigo.c (revision 1184)
+++ src/inigo/inigo.c (working copy)
@@ -324,14 +324,14 @@
        char *name = NULL;
        struct sched_param scp;
        mlt_profile profile = NULL;
+ /*
        // Use realtime scheduling if possible
        memset( &scp, '\0', sizeof( scp ) );
        scp.sched_priority = sched_get_priority_max( SCHED_FIFO ) - 1;
 #ifndef __DARWIN__
        sched_setscheduler( 0, SCHED_FIFO, &scp );
+ */
        // Construct the factory
        mlt_repository repo = mlt_factory_init( NULL );

In other words, just comment or remove those lines of code. Then recompile and reinstall the inigo binary wherever you previously had it, and it works fine. *sigh*
aspiers (reporter)
2008-10-20 14:46

Note that this is also being discussed here: [^]
aspiers (reporter)
2008-10-21 10:56

MLT/Miracle README says:

        MLT is a LGPL multimedia framework designed for television broadcasting,
        and Miracle is a GPL multi-unit video playout server with realtime

so maybe this is why they made it run with real-time priority. But kdenlive does not need real-time rendering, right?
nadavkav (reporter)
2008-10-21 11:08

that patch worked for me :-)
the system is responsive again.
with some hiccups ;-)
but what can i do, it's rendering...

i also started kuiserver before starting kdenlive
and the job is shown on it,
but without progress indication. (only Cancel button)

madsdyd (administrator)
2008-10-21 11:15

I am changing this to acknowledged, and an MLT problem, because I understand from aspiers, that the situation is that inigo overrides the scheduling policy, even when one does a "nice" on it. So, there should be a way to tell inigo not to change its scheduling properties.

Of course, this understanding may be wrong, but since I do not experience the problem on my system, I rely on this from aspiers:

[10:51] <madsdyd> Personally, I think ddennedy is right: one should nice the renderer
[10:52] <aspiers> madsdyd: that already happens but the code overrides it with nice -99 SCHED_FIFO
[10:52] <aspiers> madsdyd: if you apply the patch, it goes to nice 5

wopeer (reporter)
2008-10-28 08:03
edited on: 2008-10-28 08:04

In the meanwhile i patched my linux to ubuntu 8.10 and rebuilt kdenlive using kdenlivebuilder-script to the latest svn versions.
This version seems to work pretty well (many thanks to the authors!!)
currently i am using
ffmpeg rev 15708
mlt rev 1202
mlt++ rev 1202
kdenlive rev 2562

=> these components seems to work well together. even no freeezing when starting the rendering process. The only thing i am missing is a progress-bar during rendering , but maybe this is since kdenlive is still beta.
Thank you all.
from my point of view this issue may be closed.

madsdyd (administrator)
2008-10-28 09:20

I am not sure we should close this issue, because others appear to still experience it?

Regarding the feedback, please check these issues: [^]
and [^]
ddennedy (developer)
2008-10-30 00:40

Sorry, guys, I forgot that inigo requested to change its scheduling priority. It does not belong there. The reason for which it was added was already addressed elsewhere. I just committed the change to MLT to remove these lines from inigo.
ddennedy (developer)
2008-10-30 00:49

I want to clarify the usage of the "real_time" property. It does not affect the kernel process scheduling. When the value is 1, MLT drops frames or governs speed to maintain playback timing. A value of 0 means go as fast as possible with a single thread. A value of -1 means go as as possible using 2 threads.
madsdyd (administrator)
2008-10-30 09:12

This problem has been fixed in MLT svn rev. 1210. Thanks to all for their effort.

- Issue History
Date Modified Username Field Change
2008-10-04 19:46 wopeer New Issue
2008-10-05 01:18 administrator Note Added: 0000313
2008-10-06 22:03 madsdyd Note Added: 0000315
2008-10-06 22:03 madsdyd Status new => feedback
2008-10-08 08:22 wopeer Note Added: 0000324
2008-10-08 08:53 wopeer Note Added: 0000325
2008-10-08 08:54 wopeer File Added: debugging_output.tar.gz
2008-10-08 10:12 administrator Note Added: 0000326
2008-10-08 12:06 administrator Note Edited: 0000326
2008-10-08 21:06 wopeer Note Added: 0000344
2008-10-09 08:26 wopeer Note Edited: 0000344
2008-10-10 13:05 administrator Note Added: 0000351
2008-10-11 04:50 gsking1 Note Added: 0000353
2008-10-12 21:35 nadavkav Note Added: 0000375
2008-10-13 18:53 ddennedy Note Added: 0000386
2008-10-14 02:09 wopeer Note Added: 0000396
2008-10-17 13:10 nadavkav Note Added: 0000426
2008-10-20 13:31 aspiers Note Added: 0000477
2008-10-20 14:45 aspiers Note Added: 0000479
2008-10-20 14:46 aspiers Note Added: 0000480
2008-10-21 10:56 aspiers Note Added: 0000501
2008-10-21 11:08 nadavkav Note Added: 0000502
2008-10-21 11:15 madsdyd Note Added: 0000504
2008-10-21 11:15 madsdyd Status feedback => acknowledged
2008-10-21 11:15 madsdyd Category Rendering => MLT
2008-10-23 00:26 madsdyd Target Version => 0.7.0
2008-10-28 08:03 wopeer Note Added: 0000720
2008-10-28 08:04 wopeer Note Edited: 0000720
2008-10-28 09:20 madsdyd Note Added: 0000721
2008-10-30 00:40 ddennedy Note Added: 0000761
2008-10-30 00:49 ddennedy Note Added: 0000762
2008-10-30 09:12 madsdyd Note Added: 0000767
2008-10-30 09:12 madsdyd Status acknowledged => closed
2008-10-30 09:12 madsdyd Resolution open => fixed
2008-10-30 09:12 madsdyd Fixed in Version => Recent git
2008-11-12 23:00 madsdyd Fixed in Version Recent git => 0.7.0 beta

Copyright © 2000 - 2016 MantisBT Team
Powered by Mantis Bugtracker