Kdenlive   bug tracker Home page

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0001802KdenliveRenderingpublic2010-09-05 04:052010-09-05 04:05
Reporterjoeymorin 
Assigned To 
PrioritynormalSeveritymajorReproducibilityhave not tried
StatusnewResolutionopen 
Platform32 bit intel and alikeOSUbuntu LinuxOS Version9.04
Product Version0.7.7.1 
Target VersionFixed in Version 
Summary0001802: in/out boundary mismatch in xml sections within .kdenlive file
DescriptionWhile tracking down an uncooperative fade-to-black effect applied to an instance of a still-image clip, I discovered that the XML code of the project file had a discrepancy between the in/out as stated in two different sections.

The problem manifested itself as a 'stalled' fade-to-black. That is, the fade would start normally, but would stall before it was complete, and then snap out at the end. The problem shows up both in the Project Monitor, and in a normal render. The project tree was reporting a length of 5:00 seconds, and the instance was reporting the same length. Interestingly the clip monitor, when used to 'play' the still-frame clip, would end at roughly the same time that the fade was stalling. Creating a second instance of the clip (of the same 5:00 second length) and applying a fade-to-black effect yielded the same problem. However, re-loading the same file as a second clip, creating an instance of that newly loaded duplicate clip, and applying the fade effect seems to fix the problem.

As this problem appeared in a complex project I was developing, I could not easily solve the issue by deleting the clip (along with and every instance of it in the timeline, and dozens of associated effect), reloading, re-instantiating, and applying all the associated effects, so I dug deeper.

Deeper digging showed that the project file's XML code seems to have two separate sections that define the producer associated with a clip. For the problem clip, there were two code sections that referred to the problem clip:

-------begin 1st code fragment--------------
 <producer in="0" out="136" id="14" >
  <property name="mlt_type" >producer</property>
  <property name="aspect_ratio" >1</property>
  <property name="length" >15000</property>
  <property name="eof" >pause</property>
  <property name="resource" >kdenlive/titles/S7001096.side.by.side/frames/S7001096.Forward.motion.interpreted.as.zoom.png</property>
  <property name="ttl" >25</property>
  <property name="progressive" >1</property>
  <property name="mlt_service" >pixbuf</property>
  <property name="force_reload" >0</property>
 </producer>
-------end 1st code fragment--------------

-------begin 2nd code fragment--------------
  <kdenlive_producer audio_max="0" id="14" default_video="0" name="S7001096.Forward.motion.interpreted.as.zoom.png" in="0" resource="/home/joeymorin/kdenlive/titles/S7001096.side.by.side/frames/S7001096.Forward.motion.interpreted.as.zoom.png" default_audio="0" duration="150" groupid="3" file_hash="a3b12210b790fab350d771d7a7949f5b" aspect_ratio="1.000000" channels="0" frequency="0" out="149" video_max="0" groupname="First frames" type="5" frame_size="800x600" file_size="846072" />
-------end 2nd code fragment--------------

Note that the 1st fragment shows an out of 136, while the 2nd shows an out of 149. The project tree was reporting on the length defined in the 2nd fragment, but the render was stalling the fade at the frame defined in the 1st fragment. The clip monitor also appears to bind to the out defined int the 1st fragment.

Even deeper diggings shows that every single-frame clip in my project file has these two separate definitions, and that there is an in/out mismatch in every one. The fade-to-black stalling did not manifest itself in any of the instances of these other clips, because the mismatch had the 1st fragment defining a larger out than that defined in the 2nd fragment (whereas the opposite was true for the problem clip).

It is unclear how my project file got corrupted in this fashion, and I don't know the project file structure well enough to know why there are apparently two different sections that define the properties of clips.

I hope this is helpful to the developers. I've attached a variation of my project file containg only the clips and timeline objects that showed the in/out mismatch in the XML. The actual images I've included are not the original images from my project, but the problem is accurately represented. The project tree shows all the clips at 5:00 seconds, but the clip monitor shows them each at a different length. The clip named image 4 shows it as 4:16 seconds, and the 3rd item in the timeline (which is an instance of the same clip), contains a fade-to-black effect that stalls at the same point.
Additional Informationsee attached files
TagsNo tags attached.
Build/Install MethodDistribution package
Attached Filesgz file icon in.out.mismatch.tar.gz [^] (1,152,495 bytes) 2010-09-05 04:05

- Relationships

-  Notes
There are no notes attached to this issue.

- Issue History
Date Modified Username Field Change
2010-09-05 04:05 joeymorin New Issue
2010-09-05 04:05 joeymorin File Added: in.out.mismatch.tar.gz


Copyright © 2000 - 2014 MantisBT Team
Powered by Mantis Bugtracker