View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0002764KdenliveRenderingpublic2012-09-30 02:502013-01-28 19:51
Assigned Toj-b-m 
PlatformOSUbuntu 10.04.4 LTSOS VersionUbuntu 10.04.4
Product VersionRecent git 
Target VersionFixed in Version0.9.4 
Summary0002764: Renders nothing but black

Linux cz5000 2.6.32-42-preempt 0000096-Ubuntu SMP PREEMPT Wed Aug 15 20:07:54 UTC 2012 x86_64 GNU/Linux

Everything looks fine in the "Project monitor" but rendering produces only a black video (with sound).
Steps To ReproduceTry to render a video.
Additional InformationProject file attached.
TagsNo tags attached.
Build/Install Method3rd party package
Attached Files? file icon broken.kdenlive [^] (9,003 bytes) 2012-09-30 02:50

- Relationships
related to 0002755assignedj-b-m Adding some .kdenfiles as a clic shows up as "Invalid clip" in project monitor 

-  Notes
norms2 (reporter)
2012-09-30 17:44

I can confirm this with Saturday's update (as above) using Ubuntu 12.04.
j-b-m (administrator)
2012-09-30 23:31

This seems to be a regression in MLT. I can reproduce in MLT when trying to render a playlist containing a progressive clip. I am forwarding the info on MLT's mailing list.
BugRoss (reporter)
2012-10-01 10:39

Roger that, I am getting it also now.
It seems to be mostly with graphics (.png) what is weird is that it renders the first bit of a clip sometimes and all of the transitions. Also, it seems as if they was not happening until AFTER I did some system updates for Kubuntu this morning. It also still occurs with the latest PPA build. For now I am trying to render on a 0.8.3 and it seems to be working. I might also be able to figure out what system updates were done that may have caused the problem which was not happening before them.
atom (reporter)
2012-10-02 09:14

kdenlive - 0.9.3+git20121001.d3820e83-0ubuntu0~sunab~lucid1
melt - 0.8.3+git20121001.97511858-0ubuntu0~sunab~lucid1

Seems to be working now. Did it fix itself?
eddrog (developer)
2012-10-02 10:01

No. It was a regression in MLT deinterlacer code for progressive clips. It is fixed (by Dan) in recent MLT git. There are some tickets related to this regression.

Did it fix itself?

Sorry. There is no magic - it is hard work. Nothing happens by itself :-))
atom (reporter)
2012-10-02 10:20

Thanks all! I was just surprised to see it fixed with the latest updates, before anything was noted here.

- Issue History
Date Modified Username Field Change
2012-09-30 02:50 atom New Issue
2012-09-30 02:50 atom File Added: broken.kdenlive
2012-09-30 17:44 norms2 Note Added: 0008416
2012-09-30 23:31 j-b-m Note Added: 0008422
2012-09-30 23:31 j-b-m Assigned To => j-b-m
2012-09-30 23:31 j-b-m Status new => acknowledged
2012-09-30 23:39 j-b-m Relationship added related to 0002755
2012-10-01 10:39 BugRoss Note Added: 0008426
2012-10-02 09:14 atom Note Added: 0008429
2012-10-02 10:01 eddrog Note Added: 0008430
2012-10-02 10:20 atom Note Added: 0008432
2012-10-05 09:11 j-b-m Status acknowledged => resolved
2012-10-05 09:11 j-b-m Fixed in Version => Recent git
2012-10-05 09:11 j-b-m Resolution open => fixed
2013-01-28 19:49 j-b-m Fixed in Version Recent git => 0.9.4
2013-01-28 19:51 j-b-m Status resolved => closed

Copyright © 2000 - 2016 MantisBT Team
Powered by Mantis Bugtracker