View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0002468KdenliveUser Interfacepublic2012-01-05 01:102012-05-15 10:58
Assigned Toj-b-m 
PriorityhighSeveritymajorReproducibilityhave not tried
PlatformIntel Core 2 DuoOSUbuntu 32bitOS Version11.10
Product VersionRecent git 
Target VersionFixed in Version0.9 
Summary0002468: Zone behaviour not right
DescriptionI am running:

kdenlive 0.8.3+git20120103.84cc45b7-0ubuntu0~sunab~oneiric1
melt 0.7.7+git20120103.7b10d647-0ubuntu0~sunab~oneiric1

I have to run the svn version because of this issue: [^]

For me the behaviour of the project zone (not clip zone) is weird/broken in 3 ways:

1. Even in a very simple project. when I first hit Ctrl-Space it plays the zone and stops. If I hit Ctrl-space repeatedly (after zone has finished playing) the zone will re-play but not stop at out point (keeps on playing).

2. After 1 has occurred, If I use Ctrl-space (or the menu entry etc) the zone will not play. Hitting "T" (switch monitor) twice will make Ctrl-Space work again.

3. In a more complex project, during render, if I choose "render zone" it will render a movie which is the length of the zone but starts at beginning of project (ie will not contain the zone if that is somewhere else).

Happy to provide more info if required.
TagsNo tags attached.
Build/Install Method3rd party package
Attached Filestxt file icon script001.txt [^] (589 bytes) 2012-01-05 23:03 [Show Content]
txt file icon test_run_direct_output.txt [^] (24,410 bytes) 2012-01-06 09:19 [Show Content]
txt file icon test_run_direct_consumer_output.txt [^] (28,619 bytes) 2012-01-06 09:20 [Show Content]

- Relationships
has duplicate 0001769assignedj-b-m Render guide zone renders _anything_ but the guide zone 

-  Notes
j-b-m (administrator)
2012-01-05 11:46


Issue 1: If I understand correctly, simply pressing Ctrl + Space repeteadly triggers the bug? I cannot reproduce...

Issue 2: just fixed it in latest git

Issue 3: With the "Render zone" option, could you please use the "Generate script" feature. It will create a file in $HOME/kdenlive/scripts/

Try to render using that script using "Script" tab from the render dialog, select it and press "Start script". Does the script rendering also render the wrong zone?

If it is the case, please attach the file here (you might need to rename it to .txt for it to be accepted) and tell me what was the real zone you wanted to render...
oschonrock (reporter)
2012-01-05 18:53
edited on: 2012-01-05 19:00


Thanks for quick response on Issue 2. Look forward to the rebuilt version to appear in ubuntu git repository (weekly or daily rebuild?)

Issue1: I retested with a VERY simple project. New project 1080p 29.97fps (proxy clips off, which were on during previous test).

Create a single countdown clip (10s). Add to time line. Resize zone for some subsection of the 10s clip.

Hit time line stops on out point..don't do anything else..hit Ctrl-space without doing anything else..hit Ctrl-Space a third plays..but does not stop at out point..plays to end of project.

If you keep's now consistently broken for me...unless..

Just a theory, I have 2 physical monitors and I have detached the kdenlive "project monitor" and moved it to the other screen from the main kdenlive window. When the zone-playing is broken..if I alt-tab across to the project monitor, so it has focus, then hit Ctrl-Space it's back to working again (ie stops at out point). If I keep the focus on the project monitor it will work a few times (2 or 3) and then stop working. once broken it will stay broken (>10 attempts). Until I alt-tab back to main window and then back to project monitor..then it works again...a few times...

Don't know if that makes any sense to you..

i'll respond to issue 3 separately.

j-b-m (administrator)
2012-01-05 19:04

Ok, I reproduced problem 1, working on it
oschonrock (reporter)
2012-01-05 23:01
edited on: 2012-01-05 23:25

ok, great..

Issue 3: More tricky, because I cannot reproduce this in a simple project. But I have a project which does it repeatably.

So I did the Ctrl-Space thing until it doesn't work at all (ie doesn't even start playing zone (Issue2)..i somehow smell they are related)

Then render zone to mp4..renders from start of project for the length of the zone eventhough the zone is right at the end.

So I rendered to script as you suggested (will attach) the script says:
PARAMETERS="-pid:6655 in=7806 out=8330

if I check the zone with Shift-Home and Shift-End then those frame counts are correct.

If I use the scripts tab to render the project I get the same result as when rendering directly from the "Render Project" tab (using render zone option).

HOWEVER..I noticed that both renders (via script and directly) produced an MP4 which has frame 7806 as the first frame (ie correct), but then jumps back to beginning of project and renders the rest of zone length from there...

feels to me like mlt is confused about where the clips line up on timeline..

Just FYI I had the project in openshot earlier and it drove me mad, because none of clips and transitions would line up I spent 3 days investigating with ffmpeg and melt and found, after having corrected my school boy error of selecting the wrong frame rate for the project, that ffmpeg and mlt thought some of the clips were different lengths (by a few frames), even with correct frame rate. This made the project unusable in openshot and I gave up and migrated it to kdenlive. It has been a blessing, because proxy clips and many other features are far superior anyway, so well done. However, it just could be that this symptom is cropping up in kdenlive for the same root mlt goes mad because the in/out timings of the clips are beyond the bounds (or at least different) to the clip lengths according to ffmpeg...The openshot bug is here: [^] and my comments start at number 72

I will try reproduce in some of my other kdenlive projects (which are now accumulating fast!!)


oschonrock (reporter)
2012-01-05 23:22
edited on: 2012-01-05 23:39

have now tested Issue 3 with a second project (also non trivial)...exactly same result

rendering zone towards end of project via script or directly gives 1st frame of zone and rest of zone length starting with first frame of project.

I have second script if you want it...

j-b-m (administrator)
2012-01-05 23:48

Ok, then the problem may come from a bug in MLT or from a corruption inside the project file...

Can you try the following things:

1) in a terminal, type:

melt yourproject.kdenlive in=7806 out=8330

2) Same thing, but type:

melt yourproject.kdenlive in=7806 out=8330 -consumer avformat:test.mpg

Of course, replace yourproject.kdenlive with the path to one of your problematic project file, and in / out with the wanted zone.

What is the result? Is the bug here in both cases?
oschonrock (reporter)
2012-01-06 09:18

Before I respond with test results...I also tested this with Guides and render guide zone..and the same broken behaviour exists there this is not to do with zones at all..but probably something deeper (as you are speculating as well)...

so tests:
melt yourproject.kdenlive in=7806 out=8330
melt yourproject.kdenlive in=7806 out=8330 -consumer avformat:test.mpg

both produce video (on screen and in mpg file) which show "first frame of zone and rest of frames from start of project".

I have captured the stdout and stderr of those 2 commands and attached them to this bug. (test_run_direct_output.txt, test_run_direct_consumer_output.text)

The things that look suspicious to me are:

[flac @ 0x86090a0] Invalid size in frame , skipping the rest of tag.
[mpeg2video @ 0xa05afa0] warning: first frame is no keyframe

identical in both commands
j-b-m (administrator)
2012-01-06 09:56

As I cannot reproduce, it's difficult to find the real problem. It seems like it is either:

1) As said earlier, some corruption in the .kdenlive project.

2) FFmpeg is having problems seeking in some of your video files.

So now the best would be if you can take one of those projects, and try removing clips one by one to see if at some point the zone works correctly.

If the bug is still reproducible with a few clips, maybe you can create a .tar.gz file from your project (Kdenlive allows it in Project > Archive project) and put it somewhere so that I can download it for further analysis... If it's ok for you, you can mail me privately: jb at kdenlive org
oschonrock (reporter)
2012-01-06 11:32
edited on: 2012-01-06 11:41

OK, hopefully now we can get somewhere with Issue 3. I managed to reduce the project to just 1 raw clip off the camera (used twice on timeline with a dissolve transition) and 1 Image, and I still see the problem.

I archived this as .tar.gz. I did notice that when I re-opened the reduced project Kdenlive complained about overlapping transitions and removed them. A "new" transition then also appeared. I removed that. This would point to project file corruption? However even after kdenlive "tidied up" the phantom transitions, the now even simpler project still exhibits the zone render problem.

I have uploaded them both to a server I control and have emailed you the http urls for both projects (Debug1 is before phantom transition tidy up and Debug2 is afterwards).

I hope this helps.

Hopefully you can reproduce. If I remove any of the remaining timeline elements the problem goes away.

oschonrock (reporter)
2012-01-06 11:59

ok, sorry, I made a mistake the *Debug2.tar.gz version is corrupt, it is a partial archive (that is why it was so much smaller). I forgot that I abandoned the transfer to the public server..oops

But good news..I managed to reduce the project even just 1 raw clip (same one), no transitions or anything else. I am uploading a new .tar.gz and will email you the url in a minute.

The broken zone behaviour is not quite so visually obvious now because it is the same clip, but it is there. The first frame of the rendered zone is frame 67 and the second frame of the rendered mp4 is frame 0 of the project. If you rendering this does not produce the same result then I am happy to upload the mp4.

Looks like you theory of "FFmpeg is having problems seeking in some of your video files.", might be good one.

I am not sure if kdenlive/melt uses the system's ffmpeg or if you compile in your own statically bound ffmpeg lib. On my system I am running the latest svn ffmpeg as described here: [^]

oschonrock (reporter)
2012-01-06 12:35

investigating the theory of ffmpeg not being able to seek in the raw clip I calculated the in/out points based on the project timeline and zone position and came up with this:

ffmpeg -ss 2.836169 -t 1.534868202 -i IMGA0005.MP4 clip5.mp4

it seems to seek to start of the zone position ok and then render frames from there. None of media players can seek to the end of the resulting clip5.mp4 (usual GOP problem?) but they play the first 75% of the clip just fine..I have checked the start frame and the following few frames in clip5.mp4 against what kdenlive displays when scrubbing the timeline..they seem ok (maybe out by 1 or 2 frames).
j-b-m (administrator)
2012-01-06 12:42

Thanks a lot for the project file. I can reproduce the issue and it seems related to the track effects.

You have a "volume" effect applied to tracks 2 and 3. Disabling these track effects solves the zone problem for me. Can you confirm?

I think it is a bug in MLT related to track effects. Waiting for your confirmation before doing more investigations
oschonrock (reporter)
2012-01-06 13:20

yup, that's it. removing the volume track effects from tracks 2 & 3 solves the issue..well done.

I didn't notice those when reducing the project.
oschonrock (reporter)
2012-01-06 14:07

just upgraded to 0.8.3+git20120105.9dea7a4b-0ubuntu0~sunab~oneiric1

should that include your fix to Issue2?
j-b-m (administrator)
2012-01-06 14:11

No, the fix for the first 2 problems is just 2 commits after that revision... will be in the next update I guess.
I reported the MLT problem on MLT's mailing list, Dan will probably have a look at it when he finds time.
oschonrock (reporter)
2012-01-06 14:32

ok..great look forward to that. have subscribed to mlt-dev list and will read digests.

In your description of the mlt bug on the list you refer to "filters". Is the only place these are used in kdenlive in "track effects"? If so I can just remove those when I want to render a zone as a quick work around, they are quick to re-add..

Thanks for your help.
j-b-m (administrator)
2012-01-06 14:49

Filters are in fact names "effects" in Kdenlive. But the zone bug seems to be only triggered when effects are attached to tracks, not to clips. So yes, as a workaround you can disable the track effects (no need to delete them, simply uncheck them in effect stack) to render a zone.
Sunboy (reporter)
2012-02-06 23:21

I´ve got the 3rd issue in a bigger project too, but unfortunately it seems not to be reproductible by simply adding a track effect to a simple project.
j-b-m (administrator)
2012-02-06 23:43


The 3rd issue should have been fixed in MLT on the 21st of january 2012. Which MLT version are you running?
Sunboy (reporter)
2012-02-07 00:14

As far as I know the build script should compile the latest git. But I have tested this with a project that was migrated from an 8.2.1 Kdenlive install which was installed on the same system as the recent GIT build. Maybe I got some settings wrong so the recent build used the older, on the system installed MLT. Now I have tried a Buildscript build on a fresh Kubuntu install and the issue is gone. Thanks ;)

- Issue History
Date Modified Username Field Change
2012-01-05 01:10 oschonrock New Issue
2012-01-05 11:46 j-b-m Note Added: 0007707
2012-01-05 11:46 j-b-m Assigned To => j-b-m
2012-01-05 11:46 j-b-m Status new => feedback
2012-01-05 18:53 oschonrock Note Added: 0007710
2012-01-05 18:53 oschonrock Status feedback => assigned
2012-01-05 19:00 oschonrock Note Edited: 0007710 View Revisions
2012-01-05 19:04 j-b-m Note Added: 0007711
2012-01-05 23:01 oschonrock Note Added: 0007713
2012-01-05 23:03 oschonrock File Added: script001.txt
2012-01-05 23:03 oschonrock Note Edited: 0007713 View Revisions
2012-01-05 23:18 oschonrock Note Edited: 0007713 View Revisions
2012-01-05 23:22 oschonrock Note Added: 0007714
2012-01-05 23:24 oschonrock Note Edited: 0007713 View Revisions
2012-01-05 23:25 oschonrock Note Edited: 0007713 View Revisions
2012-01-05 23:25 oschonrock Note Edited: 0007713 View Revisions
2012-01-05 23:39 oschonrock Note Edited: 0007714 View Revisions
2012-01-05 23:48 j-b-m Note Added: 0007715
2012-01-06 09:18 oschonrock Note Added: 0007716
2012-01-06 09:19 oschonrock File Added: test_run_direct_output.txt
2012-01-06 09:20 oschonrock File Added: test_run_direct_consumer_output.txt
2012-01-06 09:56 j-b-m Note Added: 0007717
2012-01-06 11:32 oschonrock Note Added: 0007719
2012-01-06 11:39 oschonrock Note Edited: 0007719 View Revisions
2012-01-06 11:41 oschonrock Note Edited: 0007719 View Revisions
2012-01-06 11:59 oschonrock Note Added: 0007720
2012-01-06 12:35 oschonrock Note Added: 0007721
2012-01-06 12:42 j-b-m Note Added: 0007722
2012-01-06 13:20 oschonrock Note Added: 0007723
2012-01-06 14:07 oschonrock Note Added: 0007725
2012-01-06 14:11 j-b-m Note Added: 0007726
2012-01-06 14:24 j-b-m Relationship added has duplicate 0001769
2012-01-06 14:32 oschonrock Note Added: 0007729
2012-01-06 14:49 j-b-m Note Added: 0007730
2012-02-06 23:21 Sunboy Note Added: 0007865
2012-02-06 23:43 j-b-m Note Added: 0007866
2012-02-07 00:14 Sunboy Note Added: 0007869
2012-02-07 13:37 j-b-m Status assigned => resolved
2012-02-07 13:37 j-b-m Fixed in Version => Recent git
2012-02-07 13:37 j-b-m Resolution open => fixed
2012-05-15 10:57 j-b-m Fixed in Version Recent git => 0.9
2012-05-15 10:58 j-b-m Status resolved => closed

Copyright © 2000 - 2016 MantisBT Team
Powered by Mantis Bugtracker