View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0002286KdenliveMLTpublic2011-08-18 11:282011-11-01 18:56
ReporterOlivier Berten 
Assigned Toj-b-m 
Platform32 bit intel and alikeOSUbuntuOS Version11.04
Product VersionRecent git 
Target VersionFixed in Version0.8.2 
Summary0002286: crash when attempting to render 10 simultaneous tracks
DescriptionI'm using Kdenlive for basic audio mixing. On one project, I have to deal with 11 audio tracks and as soon as it hits the 10th simultaneous clip, it crashes. When trying to render, only the rendering process crashes. When trying to play, the whole program crashes.

Additional InformationHere is the backtrace. I first tried to render then play. The last 2 lines are the playing part.

project monitor connected
clip monitor connected
QWidget::insertAction: Attempt to insert null action
QWidget::insertAction: Attempt to insert null action
//STARTING RENDERING: true , false , "/usr/bin/melt" , "atsc_720p_60" , "avformat" , "-" , "/tmp/kde-oli/kdenliveuX5481.mlt" , "/home/oli/kdenlive/Nous venons d'orient.wav" , () , ("f=wav", "ar=44100", "video_off=1", "threads=1", "real_time=-1") , -1 , -1
Started render process: "/usr/bin/melt" "/tmp/kde-oli/kdenliveuX5481.mlt -profile atsc_720p_60 -consumer avformat:/home/oli/kdenlive/Nous venons d'orient.wav progress=1 f=wav ar=44100 video_off=1 threads=1 real_time=-1"
"Rendering of /home/oli/kdenlive/Nous venons d'orient.wav aborted, resulting video will probably be corrupted."
<unknown>: Fatal IO error 9 (Mauvais descripteur de fichier) on X server :0.
Unable to start Dr. Konqi
TagsNo tags attached.
Build/Install MethodDistribution package
Attached Files? file icon Nous venons d'orient.kdenlive [^] (21,683 bytes) 2011-08-18 11:28

- Relationships

-  Notes
Olivier Berten (reporter)
2011-08-18 11:30

Oops, wrong category... please change to Render
j-b-m (administrator)
2011-08-29 11:35

I confirm that the crash is reproducible, the problem is in MLT or FFmpeg.
Crash happens when using more than 10 tracks using avformat producers in MLT.

To reproduce:

melt 1.wav -track 1.wav -track 1.wav -track 1.wav -track 1.wav -track 1.wav -track 1.wav -track 1.wav -track 1.wav -track 1.wav -track 1.wav

Note that with 10 tracks it works ok, but 11 crashes.

Using the same file for all tracks or a different file for each track doesn't make a difference. Both commands crash.


ALSA lib pcm.c:7316:(snd_pcm_recover) underrun occurred
[New Thread 0xaf3feb70 (LWP 11894)]
Current Position: 0
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xaf3feb70 (LWP 11894)]
mlt_deque_pop_back (self=0x0) at mlt_deque.c:130
130 return self->count > 0 ? self->list[ -- self->count ].addr : NULL;
(gdb) thread apply all bt

Thread 7 (Thread 0xaf3feb70 (LWP 11894)):
#0 mlt_deque_pop_back (self=0x0) at mlt_deque.c:130
#1 0xb3c1c636 in producer_avformat_close (self=0xaf5b5928) at producer_avformat.c:2582
0000002 0xb7fb29b0 in cache_object_close (object=0x83c2520, data=0xaf5b5928, cache=<optimized out>)
    at mlt_cache.c:131
0000003 0xb7fb2a45 in mlt_cache_item_close (item=0x81491b0) at mlt_cache.c:174
0000004 0xb7f9e7bb in mlt_property_clear (self=0x81d2cf0) at mlt_property.c:117
0000005 mlt_property_close (self=0x81d2cf0) at mlt_property.c:590
0000006 0xb7f9eedc in mlt_properties_close (self=0x8989f50) at mlt_properties.c:1317
0000007 0xb7f9a4c7 in mlt_frame_close (self=0x8989f50) at mlt_frame.c:875
0000008 mlt_frame_close (self=0x8989f50) at mlt_frame.c:866
0000009 0xb7f9e7bb in mlt_property_clear (self=0x8995138) at mlt_property.c:117
0000010 mlt_property_close (self=0x8995138) at mlt_property.c:590
0000011 0xb7f9eedc in mlt_properties_close (self=0x8185f30) at mlt_properties.c:1317
0000012 0xb7f9a4c7 in mlt_frame_close (self=0x8185f30) at mlt_frame.c:875
0000013 mlt_frame_close (self=0x8185f30) at mlt_frame.c:866
0000014 0xb7f9e7bb in mlt_property_clear (self=0x8783e58) at mlt_property.c:117
0000015 mlt_property_close (self=0x8783e58) at mlt_property.c:590
0000016 0xb7f9eedc in mlt_properties_close (self=0x81d24d8) at mlt_properties.c:1317
0000017 0xb7f9a4c7 in mlt_frame_close (self=0x81d24d8) at mlt_frame.c:875
0000018 mlt_frame_close (self=0x81d24d8) at mlt_frame.c:866
0000019 0xb3c0715f in video_thread (arg=0x81b5090) at consumer_sdl.c:760
0000020 0xb7f7ed31 in start_thread (arg=0xaf3feb70) at pthread_create.c:304
0000021 0xb7ecd0ce in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130
Backtrace stopped: Not enough registers or memory available to unwind further

ddennedy (developer)
2011-09-03 21:28

MLT defaults to only permitting 10 *active* instances of avformat at the same time. This is an arbitrary default for the mlt_cache subsystem. To resolve it, something needs to call mlt_service_cache_set_size(service, "producer_avformat", N) on *any* MLT service object. N should probably equal the total number of tracks: audio + video.
j-b-m (administrator)
2011-09-04 20:42

Ok, I made further tests which revealed several problems. First of all, the crash is effectively related to MLT's maximum cache size.

However, the method suggested by Dan does not work. Looking at mlt_service_cache_set_size, it calls:

mlt_cache_set_size( cache, size );

Looking at the code for mlt_cache_set_size, I discovered that this function can only be called to make the cache size smaller, not larger, as explained in the description for this function.

Trying to change this function to allow a cache size increase also fails, probably because some other stuff (like the "void* A" and "void* B" functions are defined using MAX_CACHE_SIZE which always has a value of 10).

Manually changing the MAX_CACHE_SIZE default value fixes the crash but MLT is not able to change that max value correctly. Dan, can you have a look at it?
ddennedy (developer)
2011-09-04 21:56

Please confirm fix in mlt git commit e22f54d. I tried to fix melt as well in that commit because come render time, it would be affected. Oh, wait, I need to fix producer_xml as well, doing that now...
ddennedy (developer)
2011-09-04 22:01

...will need to come back to the xml producer tomorrow.
j-b-m (administrator)
2011-09-04 23:00

Wouldn't it be easier to directly patch MLT in the multitrack code? With your change to mlt_cache, the following patch solves the crash for me (no need to patch melt nor xml in that case):

--- a/src/framework/mlt_multitrack.c
+++ b/src/framework/mlt_multitrack.c
@@ -211,8 +211,11 @@ int mlt_multitrack_connect( mlt_multitrack self, mlt_producer producer, int trac
                mlt_event_inc_ref( self->list[ track ]->event );
                // Increment the track count if need be
- if ( track >= self->count )
+ if ( track >= self->count ) {
                        self->count = track + 1;
+ if ( self->count > 10 )
+ mlt_service_cache_set_size( MLT_MULTITRACK_SERVICE( self ), "producer_avformat", self->count );
+ }
                // Refresh our stats
                mlt_multitrack_refresh( self );
ddennedy (developer)
2011-09-05 07:30

Yes, perhaps easier. However, generally, I do not like putting module-specific code into the framework. I try to keep the framework code as clean and simple as possible pushing more complexity into the modules.
ddennedy (developer)
2011-09-05 08:07

more changes including producer_xml pushed to mlt git.
ddennedy (developer)
2011-09-06 23:33

Fixed in mlt git commit fa7d3ce using j-b-m's suggestion.

- Issue History
Date Modified Username Field Change
2011-08-18 11:28 Olivier Berten New Issue
2011-08-18 11:28 Olivier Berten File Added: Nous venons d'orient.kdenlive
2011-08-18 11:30 Olivier Berten Note Added: 0007207
2011-08-29 11:33 j-b-m Category User Interface => MLT
2011-08-29 11:35 j-b-m Note Added: 0007237
2011-08-29 11:35 j-b-m Assigned To => j-b-m
2011-08-29 11:35 j-b-m Status new => acknowledged
2011-09-03 21:28 ddennedy Note Added: 0007265
2011-09-04 20:42 j-b-m Note Added: 0007268
2011-09-04 21:56 ddennedy Note Added: 0007271
2011-09-04 22:01 ddennedy Note Added: 0007273
2011-09-04 23:00 j-b-m Note Added: 0007277
2011-09-05 07:30 ddennedy Note Added: 0007278
2011-09-05 08:07 ddennedy Note Added: 0007279
2011-09-06 23:33 ddennedy Note Added: 0007282
2011-09-06 23:33 ddennedy Status acknowledged => resolved
2011-09-06 23:33 ddennedy Fixed in Version => Recent git
2011-09-06 23:33 ddennedy Resolution open => fixed
2011-10-31 15:23 j-b-m Fixed in Version Recent git => 0.8.2
2011-11-01 18:56 j-b-m Status resolved => closed

Copyright © 2000 - 2016 MantisBT Team
Powered by Mantis Bugtracker