Kdenlive   bug tracker Home page

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0002117KdenliveRenderingpublic2011-05-07 03:572011-11-01 18:56
Reporterjimmac 
Assigned Toddennedy 
PrioritynormalSeveritycrashReproducibilityalways
StatusclosedResolutionfixed 
PlatformLinux x86_64OSFedoraOS Version15
Product VersionRecent git 
Target VersionFixed in Version0.8.2 
Summary0002117: Using the speed effect crashes render
DescriptionI used the speed effect just fine in the past but svn trunk kdenlive and git master mlt seem to always crash the render when I set speed of a clip to anything but 100%. Preview inside kdenlive itself is fine.

I am sorry I am unable to provide a backtrace as my knowledge of gdb is limited and the render job is a separate thread.
Steps To Reproducecreate new project
add a video clip
apply speed effect, set speed to 30%
render project, any format, say DV
render crashes
Additional InformationA screencast reproducing the issue http://dl.dropbox.com/u/24178/kdenlive/2011-05-07--03-31-51.mkv [^]
TagsNo tags attached.
Build/Install Method(select)
Attached Files

- Relationships

-  Notes
(0006698)
jimmac (reporter)
2011-05-08 22:13

Since nobody seems to have reported the issue, this is probably something I did. I cleaned up and went back to the working package only to find it doeing the same.

I figured out the kdenlive_render is responsible for rendering out the melt project. The melt pipeline runs fine, but kdenlive_render 'crashes'. The process itself doesn't and I'm not getting anything useful back form the pipeline, so it may be ffmpeg that's acting up...

    jimmac@kratos:~/kdenlive/scripts$ gdb kdenlive_render
    GNU gdb (GDB) Fedora (7.2.90.20110429-36.fc15)
    Copyright (C) 2011 Free Software Foundation, Inc.
    License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> [^]
    This is free software: you are free to change and redistribute it.
    There is NO WARRANTY, to the extent permitted by law. Type "show copying"
    and "show warranty" for details.
    This GDB was configured as "x86_64-redhat-linux-gnu".
    For bug reporting instructions, please see:
    <http://www.gnu.org/software/gdb/bugs/>... [^]
    Reading symbols from /usr/bin/kdenlive_render...(no debugging symbols found)...done.
    Missing separate debuginfos, use: debuginfo-install kdenlive-0.7.8-2.fc15.x86_64
    (gdb) run in=0 out=100 /usr/bin/mlt-melt hdv_1080_50i avformat - /home/jimmac/kdenlive/scripts/script002.sh.mlt /tmp/untitled.m2t f=mpegts acodec=mp2 ab=384k ar=48000 ac=2 vcodec=mpeg2video s=1440x1080 b=25000k g=12 trellis=1 profile=hdv_1080_50i
    Starting program: /usr/bin/kdenlive_render in=0 out=100 /usr/bin/mlt-melt hdv_1080_50i avformat - /home/jimmac/kdenlive/scripts/script002.sh.mlt /tmp/untitled.m2t f=mpegts acodec=mp2 ab=384k ar=48000 ac=2 vcodec=mpeg2video s=1440x1080 b=25000k g=12 trellis=1 profile=hdv_1080_50i
    [Thread debugging using libthread_db enabled]
    //STARTING RENDERING: false , false , "/usr/bin/mlt-melt" , "hdv_1080_50i" , "avformat" , "-" , "/home/jimmac/kdenlive/scripts/script002.sh.mlt" , "/tmp/untitled.m2t" , () , ("f=mpegts", "acodec=mp2", "ab=384k", "ar=48000", "ac=2", "vcodec=mpeg2video", "s=1440x1080", "b=25000k", "g=12", "trellis=1", "profile=hdv_1080_50i") , 0 , 100
    [New Thread 0x7ffff1af6700 (LWP 19026)]
    Detaching after fork from child process 19027.
    Started render process: "/usr/bin/mlt-melt" "/home/jimmac/kdenlive/scripts/script002.sh.mlt in=0 out=100 -profile hdv_1080_50i -consumer avformat:/tmp/untitled.m2t progress=1 f=mpegts acodec=mp2 ab=384k ar=48000 ac=2 vcodec=mpeg2video s=1440x1080 b=25000k g=12 trellis=1 profile=hdv_1080_50i"
    Rendering of "/tmp/untitled.m2t" aborted, resulting video will probably be corrupted.
    Detaching after fork from child process 19032.
    [Thread 0x7ffff1af6700 (LWP 19026) exited]
    [Inferior 1 (process 19023) exited normally]
    (gdb) thread apply all bt
(0006701)
jimmac (reporter)
2011-05-08 23:29

With some help of afriend I was able to provide a backtrace of the render fork:

Thread 5 (Thread 0x7fffeeacc700 (LWP 7423)):
#0 0x00007ffff0ede42c in filter_line_sse2 (mode=0, dst=0x7fffe0f95920 "",
prev=
0x7fffe0b958c0 "{{|}~\177\202\204\213\215\215\213\210\206\205\204effffeefffffffikywgaknnlhe]ZC@@@JJOQ0Hw\217\205\203{urqrtx{}|{zyyyyyyyxxwDCDB@>>?,--,----...///./LMKKKLLLep\205\217\177\177\177\177ju\212\224\177\177\177\200hhaXCA><:899SU[\\klmoonnnnnoppqppoort\216\220\217\215srmkhfdd~\210\235\250\233\227\217\214\212\213\214\214\230\230\230\231\231\231\231\231\260\244\213~"..., cur=
0x7fffe0995890 "{{|}~\177\202\204\213\215\215\213\210\206\205\204effffeefffffffikywgaknnlhe]ZC@@@JJOQ0Hw\217\205\203{urqrtx{}|{zyyyyyyyxxwDCDB@>>?,--,----...///./LMKKKLLLep\205\217\177\177\177\177ju\212\224\177\177\177\200hhaXCA><:899SU[\\klmoonnnnnoppqppoort\216\220\217\215srmkhfdd~\210\235\250\233\227\217\214\212\213\214\214\230\230\230\231\231\231\231\231\260\244\213~"..., next=
0x7fffe0d958f0 "{{|}~\177\202\204\213\215\215\213\210\206\205\204effffeefffffffikywgaknnlhe]ZC@@@JJOQ0Hw\217\205\203{urqrtx{}|{zyyyyyyyxxwDCDB@>>?,--,----...///./LMKKKLLLep\205\217\177\177\177\177ju\212\224\177\177\177\200hhaXCA><:899SU[\\klmoonnnnnoppqppoort\216\220\217\215srmkhfdd~\210\235\250\233\227\217\214\212\213\214\214\230\230\230\231\231\231\231\231\260\244\213~"...,
w=<optimized out>, refs=1280, parity=0) at vf_yadif_template.h:234
#1 0x00007ffff0edf27b in filter_plane (mode=0, dst=
0x7fffe0f94a20 "\r\r\016\017\020\021\020\020\017\016\016\016\016\016", '\017' <repeats 15 times>, "\020\023\024\027\027\023\017\f\v\f\f\016\016\020\021\022\---Type <return> to continue, or q <return> to quit---
022\021\021\020\020\r\v\b\t\022\025\026\030\036\034\026\023\023\022\023\023\023\023\022\021\020\020\020\020\020\020\020\017\017\016\r\f\f\f\v\v\f\017\017\020\017\017\016\r\r\r\016\016\016\017\017\017\016\016\r\r\f\f\f\v\v\v\r\016\021\024\025\024\022\021\020\021\024\025\023\022\020\017\r\r\022\025\025\024\023\022\021\021\021\021\020\020\017\016\r\r\r\r\r\r\016\016\016\016\017\020\021\022\022\021\020\017\020\021\023\024\023\023\021\020\016\017\017\017\020\020\021\022\023\026\017\020\030\031\017\016\r\f\v\v\v\v\v\v\f\r\016\016\020\021"..., dst_stride=
1280, prev0=<optimized out>, cur0=
0x7fffe0994990 "\r\r\016\017\020\021\020\020\017\016\016\016\016\016", '\017' <repeats 15 times>, "\020\023\024\027\027\023\017\f\v\f\f\016\016\020\021\022\022\021\021\020\020\r\v\b\t\022\025\026\030\036\034\026\023\023\022\023\023\023\023\022\021\020\020\020\020\020\020\020\017\017\016\r\f\f\f\v\v\f\017\017\020\017\017\016\r\r\r\016\016\016\017\017\017\016\016\r\r\f\f\f\v\v\v\r\016\021\024\025\024\022\021\020\021\024\025\023\022\020\017\r\r\022\025\025\024\023\022\021\021\021\021\020\020\017\016\r\r\r\r\r\r\016\016\016\016\017\020\021\022\022\021\020\017\020\021\023\024\023\023\021\020\016\017\017\017\020\020\021\022\023\026\017\020\030\031\017\016\r\f\v\v\v\v\v\v\f\r\016\016\020\021"...,
next0=<optimized out>, refs=1280, w=1280, h=720, parity=0, tff=0, cpu=3)
at yadif.c:397
0000002 0x00007ffff0edfa8e in deinterlace_yadif (frame=<optimized out>,
filter=<optimized out>, image=0x7fffeeacbe70, format=0x6158f0, width=
0x7fffeeacbab4, height=0x7fffeeacbab8, mode=0) at filter_deinterlace.c:152
0000003 0x00007ffff0edfdd5 in filter_get_image (this=0x7fffe0005ea0, image=
---Type <return> to continue, or q <return> to quit---
0x7fffeeacbe70, format=0x6158f0, width=0x7fffeeacbab4, height=
0x7fffeeacbab8, writable=0) at filter_deinterlace.c:220
0000004 0x00007ffff7bc073a in mlt_frame_get_image (self=0x7fffe0005ea0, buffer=
0x7fffeeacbe70, format=0x6158f0, width=0x7fffeeacbab4, height=
0x7fffeeacbab8, writable=0) at mlt_frame.c:453
0000005 0x00007ffff16f9495 in filter_get_image (this=0x7fffe0005ea0, image=
0x7fffeeacbe70, format=0x6158f0, width=0x7fffeeacbbe0, height=
0x7fffeeacbbe4, writable=0) at filter_rescale.c:215
0000006 0x00007ffff7bc073a in mlt_frame_get_image (self=0x7fffe0005ea0, buffer=
0x7fffeeacbe70, format=0x6158f0, width=0x7fffeeacbbe0, height=
0x7fffeeacbbe4, writable=0) at mlt_frame.c:453
0000007 0x00007ffff16f999e in filter_get_image (this=0x7fffe0005ea0, image=
0x7fffeeacbe70, format=0x6158f0, width=0x7fffeeacbe78, height=
0x7fffeeacbe7c, writable=0) at filter_resize.c:265
0000008 0x00007ffff7bc073a in mlt_frame_get_image (self=0x7fffe0005ea0, buffer=
0x7fffeeacbe70, format=0x6158f0, width=0x7fffeeacbe78, height=
0x7fffeeacbe7c, writable=0) at mlt_frame.c:453
0000009 0x00007ffff7bd186b in producer_get_image (self=<optimized out>, buffer=
0x7fffeeacbe70, format=0x6158f0, width=0x7fffeeacbe78, height=
0x7fffeeacbe7c, writable=<optimized out>) at mlt_tractor.c:275
0000010 0x00007ffff7bc073a in mlt_frame_get_image (self=0x7fffe0001540, buffer=
0x7fffeeacbe70, format=0x6158f0, width=0x7fffeeacbe78, height=
0x7fffeeacbe7c, writable=0) at mlt_frame.c:453
---Type <return> to continue, or q <return> to quit---
0000011 0x00007ffff7bd186b in producer_get_image (self=<optimized out>, buffer=
0x7fffeeacbe70, format=0x6158f0, width=0x7fffeeacbe78, height=
0x7fffeeacbe7c, writable=<optimized out>) at mlt_tractor.c:275
0000012 0x00007ffff7bc073a in mlt_frame_get_image (self=0x7fffe0000910, buffer=
0x7fffeeacbe70, format=0x6158f0, width=0x7fffeeacbe78, height=
0x7fffeeacbe7c, writable=0) at mlt_frame.c:453
0000013 0x00007ffff7bcf093 in consumer_read_ahead_thread (arg=0x615870)
at mlt_consumer.c:655
0000014 0x00007ffff79a2cd1 in start_thread () from /lib64/libpthread.so.0
0000015 0x00007ffff76dcdfd in clone () from /lib64/libc.so.6
 
Thread 4 (Thread 0x7fffefa00700 (LWP 7422)):
#0 0x00007ffff79a6a05 in pthread_cond_wait@@GLIBC_2.3.2 ()
from /lib64/libpthread.so.0
#1 0x00007ffff7bcf1f3 in mlt_consumer_rt_frame (self=0x615870)
at mlt_consumer.c:1252
0000002 0x00007ffff5395a5a in consumer_thread (arg=0x615870)
at consumer_avformat.c:1209
0000003 0x00007ffff79a2cd1 in start_thread () from /lib64/libpthread.so.0
0000004 0x00007ffff76dcdfd in clone () from /lib64/libc.so.6
 
Thread 3 (Thread 0x7ffff7fcb740 (LWP 7419)):
#0 0x00007ffff79a4d0f in pthread_mutex_lock () from /lib64/libpthread.so.0
---Type <return> to continue, or q <return> to quit---
#1 0x00007ffff7bc458b in mlt_properties_find (name=
0x7ffff7bd4a70 "_position", self=0x6da890) at mlt_properties.c:352
0000002 mlt_properties_get_position (self=0x6da890, name=
0x7ffff7bd4a70 "_position") at mlt_properties.c:856
0000003 0x0000000000402a8a in transport (consumer=0x615870, producer=0x6da890)
at melt.c:274
0000004 main (argc=<optimized out>, argv=<optimized out>) at melt.c:655
 
Thread 2 (Thread 0x7ffff0cbb700 (LWP 7418)):
#0 0x00007ffff72362b3 in select () from /lib64/libc.so.6
#1 0x0000003b7413c1f1 in ?? () from /usr/lib64/libQtCore.so.4
0000002 0x0000003b74074125 in ?? () from /usr/lib64/libQtCore.so.4
0000003 0x00007ffff7786cd1 in start_thread () from /lib64/libpthread.so.0
0000004 0x00007ffff723cdfd in clone () from /lib64/libc.so.6
 
Thread 1 (Thread 0x7ffff7fcb740 (LWP 7415)):
#0 0x00007ffff720ae96 in fork () from /lib64/libc.so.6
#1 0x0000003b7413b2db in ?? () from /usr/lib64/libQtCore.so.4
0000002 0x0000003b740fd688 in QProcess::start(QString const&, QStringList const&, QFlags<QIODevice::OpenModeFlag>) () from /usr/lib64/libQtCore.so.4
0000003 0x0000000000408338 in RenderJob::start (this=0x61cf40)
at /usr/src/debug/kdenlive-0.7.8/renderer/renderjob.cpp:236
0000004 0x00000000004043d4 in main (argc=21, argv=<optimized out>)
---Type <return> to continue, or q <return> to quit---
at /usr/src/debug/kdenlive-0.7.8/renderer/kdenlive_render.cpp:72
(0006728)
moorsey (reporter)
2011-05-20 11:14

Did you have this problem with MTS files?

I had a similar issue, but managed to cure it by rendering my AVCHD files to MPEG4, the speed effect the rendered OK.

Sometimes I got a freeze/crash as you describe, but sometimes the file rendered but was blank with audio

See bug report here http://www.kdenlive.org/mantis/view.php?id=2101 [^]
(0006729)
jimmac (reporter)
2011-05-20 22:14

This happens for the AVCHD MTS files from my GF1 which I believe are mpeg4 transport streams, as well as regular mpeg4 program streams (also h264 video).
(0006959)
darthMax (reporter)
2011-06-26 16:47

Same problem for me. Kdenlive crashes every time I try to render a clip (unimportant of which format) the renderer crashes.

I'm running Kdenlive 0.8.0 and melt 0.7.2-1
(0006989)
Inso (reporter)
2011-06-30 12:50

Any news ? This bug is very annoying, i cant work at the moment on my project cause i need the speed effect.... :/
(0007089)
Inso (reporter)
2011-07-23 13:06

With svn, using this effect render a black video.
(0007091)
ddennedy (developer)
2011-07-24 01:13

If you are getting a crash in yadif sse2 code, then see this:
https://sourceforge.net/tracker/?func=detail&aid=3316086&group_id=96039&atid=613414 [^]
(0007093)
Inso (reporter)
2011-07-24 22:26

Disabling sse2 for mlt changes nothing.

How can i get a backtrace of the mlt crash ?
(0007238)
Inso (reporter)
2011-08-29 12:34

Ok, it seems fixed in the last versions. Can be closed.

- Issue History
Date Modified Username Field Change
2011-05-07 03:57 jimmac New Issue
2011-05-08 22:13 jimmac Note Added: 0006698
2011-05-08 23:29 jimmac Note Added: 0006701
2011-05-20 11:14 moorsey Note Added: 0006728
2011-05-20 22:14 jimmac Note Added: 0006729
2011-06-26 16:47 darthMax Note Added: 0006959
2011-06-30 12:50 Inso Note Added: 0006989
2011-07-23 13:06 Inso Note Added: 0007089
2011-07-24 01:13 ddennedy Note Added: 0007091
2011-07-24 22:26 Inso Note Added: 0007093
2011-08-29 12:34 Inso Note Added: 0007238
2011-09-18 22:02 ttill Status new => resolved
2011-09-18 22:02 ttill Fixed in Version => 0.8.2
2011-09-18 22:02 ttill Resolution open => fixed
2011-09-18 22:02 ttill Assigned To => ddennedy
2011-11-01 18:56 j-b-m Status resolved => closed


Copyright © 2000 - 2014 MantisBT Team
Powered by Mantis Bugtracker