Kdenlive   bug tracker Home page

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0001030KdenliveRenderingpublic2009-07-09 23:442010-02-02 10:38
Reportermcfrisk 
Assigned Toj-b-m 
PrioritynormalSeveritymajorReproducibilitysometimes
StatusclosedResolutionfixed 
PlatformOSOS Version
Product VersionRecent git 
Target VersionFixed in Version0.7.6 
Summary0001030: time line corruption
DescriptionKdenlive svn3726, mlt commit bc30828d88ec690e4781704a58e2922f3d9df03b, ffmpeg commit d314d12ff724fd678e8e99f5b5359e39695ace7b on Debian unstable.

Kdenlive project set to 720p30, lots of images and videos on a 30 minute timeline.

Corruptions start at some point with one frame long deviations, one track is one frame off the others. Then they may gradually grow to be 5-10 frames long deviations on various tracks in the end.

Maybe related, ffmpeg created deinterlaced streams (Stream #0.0(eng): Video: mpeg4, yuv420p, 1280x720 [PAR 1:1 DAR 16:9], 50 tbr, 50 tbn, 50 tbc) seem to play maybe 30% faster than they are in real life (though I don't mind it atm).

Some of the corruption seems to be only on the UI. In addition, kdenlive only allows to fix the corruption for a certain amount of clips. After I've fixed 10-20 of them, I start to get moving, deleting etc. errors. Restarting kdenlive helps in this case.

Don't know how to debug these any better, I guess screen shots and even rendered output as such are useless.
TagsNo tags attached.
Build/Install MethodManual build from SVN
Attached Files

- Relationships
related to 0001065closedj-b-m Cannot move clip anymore until restart 

-  Notes
(0003655)
mcfrisk (reporter)
2009-07-09 23:55

Workaround for me is to go through the whole timeline so many times that all corrupted parts are fixed and no new ones introduced, and restart kdenlive everytime a moving, resizing etc. error comes about.
(0003656)
madkins (reporter)
2009-07-10 06:46

I'm experiencing the exact same issue. My project is about an hour long.

My profile is HD 1080p 23.98 Hz. My source video is ffmpeg created 1080p 24000/1001 fps huffyuv which otherwise seems fine.

Not only are the video clips moving around, but so are the transitions.

I had many editing sessions on this project with no problems until the corruption suddenly appeared. (Or maybe I finally noticed it?) I actually first noticed the problem in the rendered output the first time I rendered the whole thing. (A black frame between clips, etc.) After going back into kdenlive to investigate, I saw the corruption. I don't suppose the act of rendering could have affected the timeline? I've also been recompiling the latest from SVN a lot lately. Perhaps that had something to do with it? It's hard to say.
(0003657)
madkins (reporter)
2009-07-11 06:04

Okay. I think I have a snapshot of this happening. I can't speak for what mcfrisk is seeing, but is sure seems similar.

The file http://www.mikeadkins.net/kdenlive/A.kdenlive [^] is a snapshot of a project that I've been working on. Look at rows 4074 and 4075 in this file. Those correspond to a clip on the timeline and a blank entry following it. The outpoint of the clip is 342 and the length of the blank is 427.

I loaded this into kdenlive and moved the outpoint of that clip to the right by one frame. Everything appeared normal on the timeline. I saved the changed project and that file is here: http://www.mikeadkins.net/kdenlive/B.kdenlive [^]

I exited kdenlive and reopened the project. Something appeared obviously wrong at this point. All of the clips following the clip whose output I tweaked, and that were on the same track as that clip, shifted in time to the right. This corruption could only been seen after exiting and reloading.

Now compare A.kdenlive and B.kdenlive. On lines 4074 the outpoint of the clip changes from 342 to 343 as expected. But, lines 4075 show no change to the length of the blank. I think it should have decreased from 427 to 426 to compensate for the longer preceding clip. Since the blank didn't decrease in length everything after it on that track got pushed.

Making lots of tweaks to this project caused corruption that I couldn't see until reloading. Then, when I started fixing this corruption it just started causing more problems further down. It snowballs.

I tried to recreate this with a smaller project (just two clips with a gap in between) but couldn't. Somehow my project is triggering this bug but some others don't.

I'm running SVN 3728.
(0003660)
Granjow (developer)
2009-07-11 19:31

Sounds like being related to 0000924
(0003719)
madkins (reporter)
2009-07-25 05:20

Okay. The timeline corruption that I'm seeing is more repeatable that I thought. Try this:

(1) Put a new clip on the timeline. We'll call this clip A.
(2) Put a second clip (clip B) on the timeline, on the same track as clip A but starting several frames after A ends. (Leave a gap.) Note the exact frame where clip B starts.
(3) Save the project file. Copy it to another location for safe keeping because we're about to corrupt it.
(4) Move the end of clip A to the right by exactly one frame.
(5) Save this version of the project file, exit and reload it.

Note that clip B has moved to the right by one frame. I think that everything following A on that track of the timeline would have moved causing apparent timeline corruption.

If I instead move the end of A to the right by two or more frames, there is no corruption. Similarly, if I move the end of A to the left by any amount it seems to work as well.

I did some digging through the code and have some observations. This resize operation ends up calling function mlt_playlist_remove_region in file mlt_playlist.c in MLT. When we extend clip A this function is called to remove frames from the blank space following it. This function has a "length" parameter where you're supposed to specify "the duration of time to remove" in frames. But, the way this function and mlt_playlist_split (which it calls) are written, it looks like you really have to specify one fewer frames to remove than you actually want. For example, if you want to remove 10 frames, the length parameter must be 9.

Whoever wrote function Render::mltResizeClipEnd in kdenlive file renderer.cpp must have realized this because a "minus one" is performed in the line...

trackPlaylist.remove_region(blankStart, diff - 1);

The problem is that if you are trying to remove exactly one frame like in my example, the length parameter to mlt_playlist_remove_region is zero. That function includes the line...

while( length > 0 )

...which means that nothing happens if length is zero. In fact, I don't see any way to remove a one frame region using this function as it's written. So, perhaps this is really an MLT bug?

I'm a complete newbie to the kdenlive and MLT code so I don't feel comfortable proposing a fix to this. But, maybe this will help a real developer get on the right path.

I did all of this using kdenlive rev 3754 out of SVN and MLT out of git around the same time.
(0003720)
j-b-m (administrator)
2009-07-25 09:10
edited on: 2009-07-25 09:10

Madkins, thanks a lot for your investigation. Looks like you identified a bug that I have been looking for a long time. I will check if I can find a workaround for that behaviour in Kdenlive.

(0003721)
j-b-m (administrator)
2009-07-25 09:37

Ok, patch send to mlt's mailing list, should be fixed soon.
(0003724)
madkins (reporter)
2009-07-25 14:33

I'm glad that I could help. That's the beauty of open source.

Thanks to YOU and the other kdenlive and MLT developers for putting together such a great product. I've really enjoyed using it!

- Issue History
Date Modified Username Field Change
2009-07-09 23:44 mcfrisk New Issue
2009-07-09 23:44 mcfrisk Build/Install Method => Manual build from SVN
2009-07-09 23:55 mcfrisk Note Added: 0003655
2009-07-10 06:46 madkins Note Added: 0003656
2009-07-11 06:04 madkins Note Added: 0003657
2009-07-11 19:31 Granjow Note Added: 0003660
2009-07-25 05:20 madkins Note Added: 0003719
2009-07-25 09:10 j-b-m Note Added: 0003720
2009-07-25 09:10 j-b-m Status new => acknowledged
2009-07-25 09:10 j-b-m Note Edited: 0003720 View Revisions
2009-07-25 09:37 j-b-m Note Added: 0003721
2009-07-25 14:33 madkins Note Added: 0003724
2009-07-26 15:28 j-b-m Relationship added related to 0001065
2010-01-19 11:41 j-b-m Status acknowledged => resolved
2010-01-19 11:41 j-b-m Resolution open => fixed
2010-01-19 11:41 j-b-m Assigned To => j-b-m
2010-02-02 10:34 j-b-m Fixed in Version => 0.7.7
2010-02-02 10:37 j-b-m Fixed in Version 0.7.7 => 0.7.6
2010-02-02 10:38 j-b-m Status resolved => closed


Copyright © 2000 - 2014 MantisBT Team
Powered by Mantis Bugtracker