Fade glitches caused by "out" attribute being greater than clip length

Bug #1013035 reported by Daniel Ellis
This bug affects 2 people
Affects Status Importance Assigned to Milestone
OpenShot Video Editor
Fix Released

Bug Description

Continuing from bug #520941. I have found another scenario which can cause glitches with fade when using an imported PNG sequence. The generated XML includes and out attribute which is longer than the clip, which causes problems for the rest of the timeline.

The issue affects 1.4.2 and trunk.

Attached is a simple patch (agains trunk) which solves the issue.

The code previously had three branches, but note that the first two branches where the same, so I have changed this to a simple if/else with just the two relavent branches, as well as fixing the out number which was off by 1.

Revision history for this message
Daniel Ellis (danellisuk) wrote :
Revision history for this message
Daniel Ellis (danellisuk) wrote :

Although my first patch fixes the stated issue, it causes problems for other scenarios. So leave this patch for now and I'll keep looking...

Revision history for this message
Daniel Ellis (danellisuk) wrote :

So that other patch was fine, the reason it caused issues for video clips was because all imported video clips have their max_frames property 1 less than they should be. The attached patch fixes this.

However the piece of code that determines the max_frames property is only run when the clip is imported. When you open an existing project, I think the value is deserialised, and so existing projects will still have the incorrect values.

To resolve this I think we will need to add a routine to update the max_frames property when the project is opened. That would be extra overhead that I guess we would prefer to avoid every time the project is opened. Alternatively we could use a file format version stored in the project file to run an upgrade routine when things like this need to be done. Does a routine like this exist already?

Revision history for this message
Daniel Ellis (danellisuk) wrote :

As this issue is based around indexing frames, it is important for us to be careful that every frame is included. To make this easier I have attatched an image sequence with the first and last frames clearly marked.

The image sequence is 80 frames long. The first frame marked with a large "1" and the final frame marked with "80".

On PAL this sequence should be 3.2 seconds long (80/25).
On NTSC this sequence should be 2.67 seconds long (80/29.97 then rounded to 2 decimal places)

Revision history for this message
Daniel Ellis (danellisuk) wrote :

And here is an MPEG video of the same image sequence for testing first/last frame issues. The video profile is widescreen PAL.

Revision history for this message
Olivier Girard (eolinwen) wrote :

Thanks for all.

Changed in openshot:
milestone: none → 1.4.3
Revision history for this message
Andy Finch (fincha) wrote :

Think this is fixed now.

Changed in openshot:
status: New → Fix Released
status: Fix Released → Fix Committed
importance: Undecided → High
Changed in openshot:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.