|Anonymous | Login | Signup for a new account||2014-08-28 03:51 CEST|
|My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000689||Kdenlive||Rendering||public||2009-02-23 16:57||2011-04-27 23:59|
|Status||closed||Resolution||unable to reproduce|
|Platform||AMD64 (but running a 686 kernel)||OS||Debian||OS Version||unstable|
|Target Version||Fixed in Version|
|Summary||0000689: Incorrect rendering of segments with altered clip speed|
|Description||When incorporating segments with altered (in my case: increased) clip speed, those segments look fine when viewed in the project monitor, but exhibit various oddities when rendered (tried AVI DV and MPEG2). In particular, when executing the "Steps To Reproduce", the following can be observed with regard to the accelerated "red2blue" clip:|
- Mismatch between project and displayed timecode, e.g.
timecode 00:00:01:12 displayed for frame 00:00:01:00
- Time code display frequently missing
- red -> blue transition should start at about 00:00:01:16,
but starts at 00:00:01:07
- Frame 00:00:01:19 is vertically split into areas of
- Frames 00:00:01:20 and 00:00:01:21 have the same color
- So do 00:00:01:22 and 00:00:01:22
- red -> blue transition should end at about 00:00:02:08,
but ends at 00:00:02:00 already
|Steps To Reproduce||1a) Load attached project file "red2blue.kdenlive|
00:00:00:00 - 00:00:00:24 Red (#FF0000)
00:00:01:00 - 00:00:01:24 Luma transition red -> blue
00:00:02:00 - 00:00:02:24 Blue (#0000FF)
1b) Render as AVI DV/DV PAL 16:9, filename "red2blue.avi"
2a) Load attached project file "clip-speed-test.kdenlive"
00:00:00:00 - 00:00:00:24 Orange (#FF8000)
00:00:01:00 - 00:00:02:23 Previously generated clip "red2blue.avi",
clip speed set to 150%
00:00:02:24 - 00:00:03:23 Green (#0000FF)
2b) Render as AVI DV/DV PAL 16:9, filename e.g. "clip-speed-test.avi",
with timecode overlay
|Build/Install Method||Distribution package|
|Attached Files|| clip-speed-test.tar.gz [^] (1,407 bytes) 2009-02-23 16:57|
clip-speed-test.flv [^] (339,570 bytes) 2009-03-05 16:42
clip-speed-test-real-footage.flv [^] (1,021,123 bytes) 2009-03-19 12:00
clip-speed-test-full.zip [^] (2,649 bytes) 2009-08-16 20:12
I cannot reproduce the issue. I followed your instructions but it works fine here. Maybe the issue is related to your version of FFmpeg, which may have issues when seeking in dv files?
What FFmpeg version do you have?
ffmpeg says it is version SVN-r17516, built on Feb, 22nd at 09:28:29 with gcc 4.3.3. This is, I suppose, not the official Debian built, but from debian-multimedia.org.
|So... which ffmpeg version do those people use who cannot reproduce this issue?|
Ok, I made another test with current FFmpeg svn:
FFmpeg version SVN-r17751
I see no error in the rendered file, no split frames and transitions start and end correctly. However, the timecode overlay is sometimes wrong, with an offset of 1-2 frames. That might be related to the seeking offset reported by Ivan Schreter on MLT's mailing list which will probably get fixed soon, so I wait for this before taking any action.
Also, please make sure you don't have several versions of MLT libraries installed on your system, that might cause that kind of corruption...
I don't think I have multiple versions of libmlt installed. Anyway, I just uploaded a flash export of the video demonstrating the incorrect timing of the accellerated transition segment as observed on my system. (The split frame, however, seems to magically have vanished during the last system upgrade...)
Well, we'll see what happens after a new ffmpeg update will be available from the multimedia repository.
ffmpeg has been update to version SVN-r18029 from Mar 18 2009 11:23:45. The rendering problem seems to have disappeared when creating an AVI DV. However, when choosing Flash as output format, the problem remains that the last frame of the speed-increased segment is reached too early and then hangs around for a while. For an example, see the uploaded file 'clip-speed-test-real-footage.flv' and check displayed timecode 00:01:32:13.
With http://www.kdenlive.org/mantis/view.php?id=719 [^] apparently being fixed, I gave mpeg2 another go -- still same funny behaviour as with flv. (DV AVI still ok).
ffmpeg is version SVN-r18508 from Apr 14 2009 18:53:03, gcc: 4.3.3.
|So... with kdenlive 7.5 and FFmpeg version SVN-r19468, DV AVI rendering looks funny again. Check out the attached projects (same procedure as before, i.e. render "red2blue-full.kdenlive" as "red2blue-full.avi", then open and render "clip-speed-test-full.kdenlive"). The result has little to do with the intended output. For instance, at 00:00:01:00 the red2blue transition starts with a deep purple hue (instead of red) and proceeds in three intermediary steps (each 1 to 6 frames in length), reaching the final pure blue color at 00:00:01:16 already (instead of 00:00:02:22).|
|How about current svn?|
|2009-02-23 16:57||tcrass||New Issue|
|2009-02-23 16:57||tcrass||File Added: clip-speed-test.tar.gz|
|2009-02-23 16:57||tcrass||Build/Install Method||=> Distribution package|
|2009-02-24 09:09||administrator||Note Added: 0002460|
|2009-02-24 09:09||administrator||Status||new => feedback|
|2009-02-24 12:10||tcrass||Note Added: 0002462|
|2009-02-28 20:58||tcrass||Note Added: 0002480|
|2009-03-03 15:25||administrator||Note Added: 0002491|
|2009-03-05 16:42||tcrass||File Added: clip-speed-test.flv|
|2009-03-05 16:56||tcrass||Note Added: 0002502|
|2009-03-19 11:58||tcrass||Note Added: 0002562|
|2009-03-19 12:00||tcrass||File Added: clip-speed-test-real-footage.flv|
|2009-04-27 17:53||tcrass||Note Added: 0002768|
|2009-08-16 20:10||tcrass||Note Added: 0003802|
|2009-08-16 20:12||tcrass||File Added: clip-speed-test-full.zip|
|2010-12-26 10:36||Granjow||Tag Attached: old|
|2010-12-26 10:37||Granjow||Note Added: 0006226|
|2011-04-27 23:59||ttill||Status||feedback => resolved|
|2011-04-27 23:59||ttill||Resolution||open => unable to reproduce|
|2011-04-27 23:59||ttill||Status||resolved => closed|
|Copyright © 2000 - 2014 MantisBT Team|