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

[Daniel Ellis]

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.

[Daniel Ellis (danellisuk)]

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...

[Daniel Ellis (danellisuk)]

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?

[Daniel Ellis (danellisuk)]

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)

[Daniel Ellis (danellisuk)]

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

[Olivier Girard (eolinwen)]

Thanks for all.

[Andy Finch (fincha)]

Think this is fixed now.