Kdenlive   bug tracker Home page

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000796KdenliveUser Interfacepublic2009-04-28 10:032011-04-28 00:01
Reportertcrass 
Assigned To 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionunable to reproduce 
PlatformAMD64 (but running a 686 kernel)OSDebianOS Versionunstable
Product Version0.7.3 
Target VersionFixed in Version 
Summary0000796: Clip duration dialog handles clips with altered speed inconsistenty and incorrectly
DescriptionThe duration settings of clips with altered clip speed are not correctly handled. In particular, in some cases, the values for crop start and duration seem to refer to the original clip's time base, while in other cases the altered clip's time base is used. As a consequence, the values for crop start and duration keep changing when opening and confirming (OK button) the clip duration dialog multiple times.

Furthermore, the duration value displayed in the duration dialog seems to occasionally fluctuate by 1 (perhaps due to a rounding error?).

Finally, clip speed changes don't get correctly undone in at least some cases.
Steps To ReproduceCreate/Load the sample project described in bug report 0000689 (http://www.kdenlive.org/mantis/view.php?id=689 [^]). In the following description, 'clip' always refers to the central red2blue transition clip of original length 00:00:03:00, inserted into the clip-speed-test.kdenlive project.

Crop start/duration time base problem:
--------------------------------------
Clip initially: 00:00:01:00 - 00:00:01:00 - 00:00:02:00
Change speed to 140%
Re-open duration dialog
  Clip now: 00:00:01:00 - 00:00:00:18 - 00:00:02:00
    should be: 00:00:01:00 - 00:00:01:00 - 00:00:02:00 (original clip)
           or: 00:00:01:00 - 00:00:00:18 - 00:00:01:11 (speeded up)
OK & reopen: 00:00:01:00 - 00:00:00:13 - 00:00:02:00
OK & reopen: 00:00:01:00 - 00:00:00:09 - 00:00:02:07
OK & reopen: 00:00:01:00 - 00:00:00:06 - 00:00:02:12
...


Duration fluctuation problem:
-----------------------------
Clip initially: 00:00:01:00 - 00:00:00:00 - 00:00:03:00
Change speed to 140%
Re-open duration dialog
  Clip now: 00:00:01:00 - 00:00:00:00 - 00:00:02:24
    should be: 00:00:01:00 - 00:00:00:00 - 00:00:02:04
Cancel & reopen: unchanged
OK & reopen: 00:00:01:00 - 00:00:00:00 - 00:00:03:00

Undo-Problem:
Clip initially: 00:00:01:00 - 00:00:00:00 - 00:00:03:00
Change speed to 140%
Undo
Re-open duration dialog
  Clip now: 00:00:01:00 - 00:00:00:00 - 00:00:02:24
    should be: 00:00:01:00 - 00:00:00:00 - 00:00:03:00
Tagsold
Build/Install MethodDistribution package
Attached Files

- Relationships

-  Notes
(0003465)
administrator (administrator)
2009-06-25 21:43

This should be fixed now (svn rev. 3660)
(0003682)
tcrass (reporter)
2009-07-19 19:36

Hi,

sorry for not replying earlier, been on holiday...

Unfortunately, I cannot verify whether this problem has been fixed since when opening any kdenlive project containing clips with altered speed (e.g. the project described in the initial report of this bug), the application keeps telling me that some clips (namely those with altered speed) are "missing or invalid" and asks me whether to remove them from the project. When denying deletion, the clip is shown as pure black in both the clip and the project monitor; when trying to change clip speed to some different value, kdenlive crashes with signal 11. However, when I (allow kdenlive to|manually) delete the clips in question and try to re-import them into the project, kdenlive refuses the import, complaining that the clip "is invalid". (Note the difference to the error message mentioned above -- nothing about the clip possibly missing!)

Should I file a separate bug report for this issue?

Regards --

tcrass

P.S. Did an "aptitude full-upgrade" earlier today; my kdenlive intallation is version 0.7.5-1 according to Debian nomenclature.
(0003803)
tcrass (reporter)
2009-08-16 20:34

OK, dunno if Debian's 0.7.5-1 version has incorporated any of the svn rev. 3660 changes, but here's what I find, anyway:

problem #1 (Crop start/duration time base problem) seems to be only partially fixed. After changing the speed to 140%, I initially get 00:00:01:00 - 00:00:00:18 - 00:00:01:10 (which is ok). But...
OK & reopen: 00:00:01:00 - 00:00:00:13 - 00:00:01:10
OK & reopen: 00:00:01:00 - 00:00:00:09 - 00:00:01:10
OK & reopen: 00:00:01:00 - 00:00:00:06 - 00:00:01:10
Apperently the crop start position does still refer to a different timebase than the duration.

Problem 0000002 (Duration fluctuation problem): seems to be fixed.

Problem 0000003 has not been fixed. Clip initially 00:00:01:00 - 00:00:00:00 - 00:00:03:00
Change speed to 140%, then undo: 00:00:01:00 - 00:00:00:00 - 00:00:02:23

Regards --

tcrass
(0006227)
Granjow (developer)
2010-12-26 10:39

Can you still reproduce that? I tried, and it worked fine with the current version.

- Issue History
Date Modified Username Field Change
2009-04-28 10:03 tcrass New Issue
2009-04-28 10:03 tcrass Build/Install Method => Distribution package
2009-06-25 21:43 administrator Note Added: 0003465
2009-06-25 21:43 administrator Status new => feedback
2009-07-19 19:36 tcrass Note Added: 0003682
2009-08-16 20:34 tcrass Note Added: 0003803
2010-12-26 10:39 Granjow Tag Attached: old
2010-12-26 10:39 Granjow Note Added: 0006227
2011-04-28 00:00 ttill Status feedback => resolved
2011-04-28 00:00 ttill Resolution open => unable to reproduce
2011-04-28 00:01 ttill Status resolved => closed


Copyright © 2000 - 2014 MantisBT Team
Powered by Mantis Bugtracker