Audit script to catch final keyframe bug

johnmeyer wrote on 7/7/2005, 12:30 PM
[Edit] I added a line (which you can comment out) that actually automatically fixes the problem. It still adds the "***" markers so you can go through the project and check the events that have been changed.

I finally got sick and tired of the bug that has long been in Vegas that moves the final keyframe in the pan/crop dialog whenever you lengthen an event. Specifically, if you place two keyframes in the pan/crop dialog, one at the beginning of the event and one at the end of the event, the keyframe at the beginning always stays at the beginning, regardless of whether you later shorten or lengthen the event. The keyframe at the end will stay at the end if you shorten the event, but if you lengthen it, that final keyframe stays at the same time location, and as a result, there is no longer a keyframe at the end of the event.

When you are using the pan/crop keyframes to animate a still photo, this bug completely ruins the effect. Sometimes you can catch the problem, but often -- if you lengthen the event only slightly, or if the end of the event dissolves into the next event, it is very difficult to catch the problem until the entire project has been rendered. This is especially true because high resolution still photos don't playback at 30 fps on the timeline, and therefore the jerkiness from normal playback and the jerkiness from a mis-placed keyframe cannot be easily distinguished.

The script below simply puts markers on the timeline at the beginning of each video event where the final keyframe is not exactly at the end of the event. It also highlights each problem event. I could easily modify the script to actually move the final keyframe to the end of the event, and I may do that someday. However, I wanted to use this script on a few dozen projects to see if there are any instances where such an automatic fixup might cause more problems than it cures.

Here's the script. Like most of my scripts, it is patched together and therefore not particularly elegant.

=====================
/**
* When placing stills on the video track in Vegas, most users
* want to animate those stills using keyframes in the pan/crop dialog for
* that event. Normally, there should be a keyframe at the beginning
* and at the end of such an event (there can be additional keyframes
* in the middle for more complicated moves). Unfortunately, Vegas contains
* a bug whereby when you change the length of such a still event after
* you have already added keyframes to the beginning and the end of the
* event, the keyframe at the start of the event stays at the start (as
* it should), but the keyframe at the end of the event does not stay
* at the end. This results in still picture animations that suddenly
* appear to freeze at the end of the event. These are sometimes
* difficult to spot, especially if the end of the event overlaps the
* next event.
*
* This script looks at each event on all video tracks.
* The script looks to see if there is a keyframe at the exact end
* of the event. If there is not, the script flags that event by placing
* a marker at its start.
*
* Written By: John H. Meyer
* Date: July 7, 2005
*
**/

import System;
import System.IO;
import System.Windows.Forms;
import Sony.Vegas;
var myMarker : Marker;

try {

//Go through the list of Tracks
var trackEnum = new Enumerator(Vegas.Project.Tracks);
while (!trackEnum.atEnd()) {
var track : Track = Track(trackEnum.item());

// Only look at video tracks
if (track.IsVideo()) {
//Go through the list of events on this track
var eventEnum = new Enumerator(track.Events);
while (!eventEnum.atEnd()) {
var evnt : TrackEvent = TrackEvent(eventEnum.item());
evnt.Selected = false; // De-select events in order to make problem events stand out
var MyFilePath = evnt.ActiveTake.MediaPath;
var extFileName = Path.GetFileName(MyFilePath);
var baseFileName = Path.GetFileNameWithoutExtension(extFileName); // Media file name for this event
var EventLength = evnt.Length;
var videoEvent = VideoEvent(eventEnum.item());
var keyframes = videoEvent.VideoMotion.Keyframes;
var cKeyframes = keyframes.Count;

// Only look at events that have more than one keyframe
if (cKeyframes > 1 ) {
var KeyLength = keyframes[cKeyframes-1].Position;
if (KeyLength < EventLength) {
evnt.Selected = true;
myMarker = new Marker(evnt.Start);
Vegas.Project.Markers.Add(myMarker);
myMarker.Label = "*** "+baseFileName;

keyframes[cKeyframes-1].Position = EventLength; // Optional line to actually move last keyframe

} // End If KeyLength
} // End If cKeyframes

eventEnum.moveNext();

} // End While !eventEnum

} // End if track.IsVideo

trackEnum.moveNext();

} // End While trackEnum

} catch (e) {
MessageBox.Show(e);
} // End try

Comments

JohnnyRoy wrote on 7/7/2005, 2:46 PM
I appreciate your frustration but I’m not sure why you consider this a “bug”. There is nothing buggy about it that I can see. Keyframes are absolute values. Why is the end special? Why not the middle? What about thirds?

What you really want is a function that keeps the keyframes relative if the event length changes. Here’s why: Let’s say you place a keyframe at the beginning, the center, and at the end of an event. If I lengthen the event, then simply moving the last keyframe doesn’t help the fact that the center keyframe no longer happens in the middle of the event. What is really needed is an option to keep the keyframes relative to the event length.

So this is NOT a bug. It is the expected behavior of absolute keyframes. Therefore, what you want is not a bug FIX. It is a NEW behavior for relative keyframe placement, which is sometimes desirable and sometimes not (i.e,. I lengthen an event to actually add more keyframes in which I don’t want them to move).

~jr
johnmeyer wrote on 7/7/2005, 3:22 PM
Johnny,

All your points are valid, and as a result I suppose Sony could classify this as expected behavior. This is definitely true with keyframes that lie between the beginning and the end point: Should the time between keyframes "stretch" or "shrink" when the event is re-sized, or should it remain absolute (which is what it does now)? That is an excellent point that you make.

However, the reasons I consider the special case of the keyframe at the end of the event a bug rather than a "behavior" are twofold:

1. It is NEVER (in my experience) the right thing to do to leave the keyframe, which is at the last frame of the event, on the same time location relative to the beginning of the event. I can think of no reason why I would want movement up to the exact end of an event and, only after extending that event, now want that movement to end prior to the finish of that event.

2. It is inconsistent with how the keyframe at the beginning of the event works. This is probably my strongest argument for why it is a bug rather than a feature. If you stretch the event by grabbing the left side of the event and making it longer, the keyframe at the beginning of the event stays at the beginning. If you do the same thing with the right side of the event and make it longer, the keyframe at the end of the event does not move to the end. To me, if a program takes two parallel scenarios -- which these two definitely are -- and gives you one behavior under the first, and a different behavior under the second, then that is, almost by definition, a bug.

Regardless of semantics, I'll bet that most people have been bitten by this -- a lot -- and many of them many not have found out until too late that there is a nasty little "hiccup" at the end of several of their lovely still photo "Ken Burns" effects.

Erk wrote on 11/12/2005, 6:57 PM
Well, whether its a bug, feature, or annoyance, this is a very useful script johnmeyer! I was recently struggling with this very problem as I overlapped some keyframed stills on the timeline.

This will save lots of time! Thank you!

Greg
johnmeyer wrote on 11/13/2005, 8:32 AM
You're welcome. I've tried for almost two years to get Sony to treat it as a bug and change the behavior. I cannot think of one situation where not moving a keyframe located at the exact end of the event (i.e., not keeping it at the end) as the event is made longer is the right thing to do. Glad the script was useful.
tceaves wrote on 1/20/2006, 9:01 PM
Thank you! Thank you! Thank you!

It is late I'm trying to finish up a project and all my key frames got moved. Thanks for ths script it saved my sanity tonight and I will get some sleep yet.
johnmeyer wrote on 1/21/2006, 12:07 AM
It always makes me feel good when I can help someone. Glad you liked it!