0001553: Project monitor hangs at video-track transition point

View Issue Details [ Jump to Notes ]

[ Issue History ] [ Print ]

Project

Category

View Status

Date Submitted

Last Update

0001553

Kdenlive

MLT

public

2010-04-15 01:44

2010-09-14 23:00

Reporter

smani

Assigned To

ddennedy

Priority

normal

Severity

crash

Reproducibility

always

Status

closed

Resolution

fixed

Platform

Linux

Fedora Linux

OS Version

Product Version

0.7.7.1

Target Version

Fixed in Version

0.7.8

Summary

0001553: Project monitor hangs at video-track transition point

Description

Kdenlive will always hang as soon as I play the preview in the project monitor of a project where video tracks overlap.

Steps To Reproduce

Create a project with any number of clips. Arrange the video tracks as
Track 1|[ Clip 1 ]
Track 2| [ Clip 2 ]
^
(Clip 1 and Clip 2 can also be the same).
Start playing from the beginning (or just before the transition (^) ) in the preview monitor. as soon as the preview reaches the transition point ^, the player will hang and never come back alive.

Additional Information

When the project monitor hangs, the interface is responsive initially. If you click to clip monitor, then the interface hangs.
If you try to render the project (even without ever playing the preview), the rendering process will hang at a percentage that is suspiciously close to the transition point.

Doing a backtrace after project monitor hung + click on clip monitor, one obtains (this specific one is obtained from the Fedora 12 configuration - see below - but they all look the same)
#0 0x000000377ec07bfd in pthread_join (threadid=140737073723152,
    thread_return=0x0) at pthread_join.c:89
        __ignore = -512
        _tid = 5884
        _buffer = {__routine = 0x377ec07ad0 <cleanup>, __arg = 0x7fffe7493d38,
          __canceltype = 513, __prev = 0x0}
        oldtype = 0
        pd = 0x7fffe7493710
        self = 0x7ffff7fb2840
        result = 0
#1 0x00007fffeb187555 in consumer_stop (parent=<value optimized out>)
    at consumer_sdl_preview.c:245
        properties = <value optimized out>
        app_locked = 16837664
        lock = 0
        unlock = <value optimized out>
        this = 0x100ea50
0000002 0x0000003f912158a2 in mlt_consumer_stop (this=0x100ea50)
    at mlt_consumer.c:945
        properties = 0x100ea50
0000003 0x0000000000487fd8 in Render::stop (this=0x100e120)
    at /usr/src/debug/kdenlive-0.7.7.1/src/renderer.cpp:1229
        __PRETTY_FUNCTION__ = "void Render::stop()"
---Type <return> to continue, or q <return> to quit---
0000004 0x00000000004cca6b in MonitorManager::slotSwitchMonitors (this=0xde9560,
    activateClip=<value optimized out>)
    at /usr/src/debug/kdenlive-0.7.7.1/src/monitormanager.cpp:74
No locals.
0000005 0x000000000047f56b in Monitor::activateMonitor (this=0xfcfed0)
    at /usr/src/debug/kdenlive-0.7.7.1/src/monitor.cpp:512
No locals.
0000006 0x000000000047fb45 in Monitor::refreshMonitor (this=0xfcfed0,
    visible=<value optimized out>)
    at /usr/src/debug/kdenlive-0.7.7.1/src/monitor.cpp:693
No locals.
0000007 0x00000000004829f5 in Monitor::qt_metacall (this=0xfcfed0, _c=
    InvokeMetaMethod, _id=<value optimized out>, _a=0x7fffffffc330)
    at /usr/src/debug/kdenlive-0.7.7.1/src/cmake_bindir/monitor.moc:279
No locals.
0000008 0x000000378456a2af in QMetaObject::activate (sender=0xfce530,
    m=<value optimized out>, local_signal_index=<value optimized out>, argv=
    0x7fffffffc330) at kernel/qobject.cpp:3293
        receiver = 0xfcfed0
        method = <value optimized out>
        currentSender = {sender = 0xfce530, signal = 30, ref = 1}
        previousSender = <value optimized out>
        c = 0x1148f00

If I close the window after the hang (with the application not responding -> force quit dialog), a kdenlive process remains in memory, which will only die with the KILL signal.

It does not matter what type of video file I choose, whether the clip has audio or not, or whatever. Switching audio output to alsa, killing pulseaudio, muting the audio channel in the video tracks, all makes no difference.

If the video tracks are placed sequentially, i.e. with some pause before the upper and the lower track, then playback in the monitor works.

Tested on:
- Fedora 12 x86_64 Gnome, v.0.7.7.1 rpmfusion package
- Debian sid x86_64 Gnome, v0.7.7.1
- Ubuntu 10.04 x86_64 Gnome, sunab2 as well as custom built from svn

All test cases suffer the same issue.

Attaching a sample video, though as pointed above I have the issue with any file, from any source.

Tags

No tags attached.

Build/Install Method

Distribution package

Attached Files

00029.MTS [^] (4,521,984 bytes) 2010-04-15 01:44

Relationships

Notes
(0005033) smani (reporter) 2010-04-15 01:55	Spaces got stripped in the Steps to reproduce, should be as in http://www.kdenlive.org/forum/project-monitor-hangs-overlapping-video-tracks#comment-8584 [^]

(0005036) Chamo (reporter) 2010-04-15 16:58	Hi, just wanted to tell you I have the same issue here on a Gentoo system, 64 bit AMD architecture. My Gentoo system is up to date, Kdenlive is 0.7.7.1 on KDE 4.3.5, everything compiled by the "emerge" command. Chamo

(0005037) ttill (developer) 2010-04-15 17:21	I can also reproduce. System: up-to-date Archlinux; kdenlive, mlt, ffmpeg from svn/git. However I did not get stuck if I cropped the end of the first clip for at least 3 frames. I use PAL. Color clips work without problems.

(0005047) ddennedy (developer) 2010-04-19 02:15	Unable to reproduce. Someone might need a better description or screencast.

(0005048) smani (reporter) 2010-04-19 10:27	Example screencast at http://n.ethz.ch/~smani/download/out.ogv [^]

(0005049) ddennedy (developer) 2010-04-19 16:55	You are using AVCHD, which is known to have very, very poor seeking performance. So, this is not unexpected. When switching clips during playback, it must seek into the second clip. Depending on factors, this can take _several_ (5-10) seconds. You were simply impatient and clicking around not waiting.

(0005050) ttill (developer) 2010-04-19 16:58	For me this also happens using DNxHD, which is normally quite fast. I also waited longer, but the monitor won't respond.

(0005051) smani (reporter) 2010-04-19 17:51	In the screencast I was a little to hasty to avoid having a 100mb video to upload, but it actually makes no difference how long I wait: I've waited up to 5-10 minutes at least on other occasions. As I write I am also trying with a quicktime mov of 30secs (1440x1080 H.264 / AVC 30fps), and it's stuck too. Nevertheless I was incorrect stating that the issue affects all formats, but I from what I've seen all *264 codecs are affected. As a side node, I tested with openshot, which also uses MLT, and there it works fine - hence the MLT category above is probably wrong.

(0005052) ddennedy (developer) 2010-04-19 18:04	This might be regression due to a fix to try to play all frames at the end of the _project_. I believe there was a change in Kdenlive as well as MLT to address this, but I only did the MLT change. Hmm. This concerns me quite a bit, and I wish I can reproduce it. I will keep trying with different systems and formats.

(0005053) smani (reporter) 2010-04-19 18:56	Additionally to the file attached in this bugreport, you might want to try http://n.ethz.ch/~smani/download/IMAG0069.MOV [^] , which is another h264 movie. I am able to reproduce the issue with both files on any system configuration as listed in my original description. Hope this helps.

(0005054) ddennedy (developer) 2010-04-20 05:41	I believe I have reproduced and fixed this in MLT git commit 1519edd. This was due to some insufficient error handling on failure to decode video. Perhaps this bug was aggravated by various changes over the past half year. In any case, it is not uncommon that FFmpeg can not decode some frames at the end of AVCHD. Maybe that is because it has some forward references that do not exist. However, you need to be able to reliably get in that area of the timeline to trim them out!

(0005055) ddennedy (developer) 2010-04-20 05:43	Oh, and I plan to release MLT 0.5.4 tonight; OpenShot has requested it to try to get a fix into Debian/Ubuntu ASAP. So, I really hope it fixed it for you too.

Issue History
Date Modified	Username	Field	Change
2010-04-15 01:44	smani	New Issue
2010-04-15 01:44	smani	File Added: 00029.MTS
2010-04-15 01:55	smani	Note Added: 0005033
2010-04-15 16:58	Chamo	Note Added: 0005036
2010-04-15 17:21	ttill	Note Added: 0005037
2010-04-19 02:15	ddennedy	Note Added: 0005047
2010-04-19 10:27	smani	Note Added: 0005048
2010-04-19 16:55	ddennedy	Note Added: 0005049
2010-04-19 16:58	ttill	Note Added: 0005050
2010-04-19 17:51	smani	Note Added: 0005051
2010-04-19 18:04	ddennedy	Note Added: 0005052
2010-04-19 18:56	smani	Note Added: 0005053
2010-04-20 05:41	ddennedy	Note Added: 0005054
2010-04-20 05:41	ddennedy	Status	new => resolved
2010-04-20 05:41	ddennedy	Fixed in Version	=> Recent git
2010-04-20 05:41	ddennedy	Resolution	open => fixed
2010-04-20 05:41	ddennedy	Assigned To	=> ddennedy
2010-04-20 05:43	ddennedy	Note Added: 0005055
2010-09-14 11:01	j-b-m	Fixed in Version	Recent git => 0.7.8
2010-09-14 23:00	j-b-m	Status	resolved => closed