|Anonymous | Login | Signup for a new account||2014-03-08 00:03 CET|
|Main | My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0001802||Kdenlive||Rendering||public||2010-09-05 04:05||2010-09-05 04:05|
|Priority||normal||Severity||major||Reproducibility||have not tried|
|Platform||32 bit intel and alike||OS||Ubuntu Linux||OS Version||9.04|
|Target Version||Fixed in Version|
|Summary||0001802: in/out boundary mismatch in xml sections within .kdenlive file|
|Description||While 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>
-------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 Information||see attached files|
|Tags||No tags attached.|
|Build/Install Method||Distribution package|
|Attached Files||in.out.mismatch.tar.gz [^] (1,152,495 bytes) 2010-09-05 04:05|
|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|