Original subtitles

In this video we're going to be changing the speed of a clip.

We have this footage of two guys playing basketball.

It was shot at a high frame rate,

so it's slow motion when we play it back at 24 frames a second.

We're going to look at ways that we can speed it up,

so it plays back in real-time.

I think the footage was shot at 96 frames a second,

which is four times more than the usual 24 frames a second.

This means that for every frame in our 24 frame a second

project there are 4 frames from the footage,

so we are going to need to speed it up by a factor of 4

to get it to play back in real-time.

If you remember back to the first class,

I've already shown you one way to speed a clip up by

using an expression in the Read node, so let's try that.

Before we go any further, though,

let's add a frame number burn-in with a Text node,

so we can see what is happening.

I'll add a Text node and type value frame in square brackets on one line and

metadata input/frame in square brackets on the next line.

The top number is based on the timeline in Nuke,

whereas the bottom number is reading the metadata that is

embedded in the actual frame being passed through the Read node

after any expression has been applied.

Before we enter the expression the two numbers will match.

We can open the Read node and choose expression,

and type frame multiplied by four.

Now frame one on the timeline is going to show frame four of the footage.

On frame two we will see frame eight of the footage.

Notice how the top number in the Text node hasn't changed

because it's based on the new timeline,

and we are effectively applying the retime to the

footage before it gets to our timeline.

When we hit play you can see the clip is playing back real-time now.

You'll also notice that the clip ends much sooner because we've

effectively removed three-quarters of the frames.

This works, in this case, because the footage starts at frame 0.

If the frame numbering with the footage starts at 1001,

like it often does in Visual Effects, this isn't going to work.

If I load in this version of the same clip,

which is identical, except that it does start on frame 1001,

you can see the problem.

One thousand and one multiplied by 4 is 4004,

and this clip ends at frame 1337,

so we are already way beyond our frame range on our first frame.

We could fix the expression by subtracting 1000 from the

frame number before we do the multiplication,

then adding it back on afterwards.

That expression would look like this, frame-1000 in brackets,

multiply by 4, add 1000, but like before,

there are dedicated nodes that give us more options than just

trying to do everything in the Read node.

Let's remove the expression from the Read node,

and delete the second line from the Text node.

From now on our retimes will be based on the numbers in the Nuke timeline.

The simplest way to apply a constant speed change to

a clip is to use the Retime node, which we looked at in the previous video.

Let's bring that in and set the speed to four.

I'm also going to set the filter to nearest for now,

and we'll come back to this later.

Now you can see that the clip plays back at real speed.

Notice that the output end frame now shows 1085.

Using the speed slider is a very logical way of working,

and other nodes that we'll cover later also have the same option,

but it is often more practical to deal with frame numbers rather than speed.

Working with frame numbers instead of speed makes it easier to use

expressions to apply these changes in time to other nodes or to pass

the retime data on to other applications.

This is why the time TimeWarp node is probably the most used node in

Visual Effects when it comes to setting up retimes.

It's an incredibly simple node,

and we don't often use it to render the final result,

but we usually use it to set up the retimes,

and then link the output to other nodes.

In the TimeWarp node we simply define which frame of the source

we want to view at each frame of the timeline.

By default,

you'll notice that Nuke automatically creates two

key frames on the input property,

one for the first frame and one for the last frame of our timeline.

The value of these key frames matches the frame numbers of

the first and the last frames of the clip,

and if you look in the Curve Editor you can see that the

interpolation between the key frames is linear,

so currently the input frame of the clip matches

the output frame of the timeline, a one to one relationship,

so there is no speed change on the clip.

As we scrub through it you'll see that the input value matches the output value.

The slope of this graph represents the speed of the clip.

The x-axis of the graph is the output frame,

and the y-axis of the graph is the input frame.

As it is,

an increase of one on the x-axis results in an increase of one on the y-axis.

This means that the gradient of the graph is one,

and therefore the speed of the clip is one.

The gradient of a graph for any point is called the derivative.

Nuke will calculate this for us,

and we can display it in a Text node in a similar way

to how we display the frame numbers.

Let's create a new Text node, below the TimeWarp this time,

and enter value TimeWarp1.

lookup.

derivative in square brackets.

The word lookup is actually the name of the input

frame variable in the TimeWarp node,

so this expression is telling the Text node to display the

derivative of the input frame value on the current frame.

We need to move this text down a little bit,

so it's not covering up the frame numbers.

We want to apply a constant speed change of four to the clip,

so we want the gradient of our graph to be four.

We do this by changing the relationship between the input and the output.

If you remember,

the Retime node told us that when we sped the clip up by a

factor of four our clip ended on frame 1085,

so we need to map frame 1337 of the input to frame 1085 on our timeline.

We can do this in multiple ways.

The first way is to use the controls in the node directly.

We can move to frame 1085 in the timeline, and type 1337 into the dialog box.

If you hit play now you'll see that the footage plays

back faster until 1085 and then freezes,

which is what we would expect,

but if you look at the frame number burn-in you'll see that the frames

aren't always increasing by 4 whole frame numbers,

and the gradient is changing on every frame,

and after 1085 it isn't frozen at all.

It's reading in frames beyond the end of our clip and around 1190

the frame numbers are actually going backwards,

so what's going on here?

If we look at the Curve Editor we can see that the

graph is no longer a straight line.

When we added a third key frame Nuke created a nice,

smooth curve between it and the other key frames.

This curved line means that the retime isn't linear.

It's going to vary on every frame.

It will be faster where the graph is steeper,

slower where it's flatter,

and it will actually run backwards when the graph starts sloping downwards.

Luckily, there's an easy way to fix this.

We can select all of the key frames and set the interpolation

of the graph to linear by right-clicking on one of the key

frames and choosing Interpolation, Linear.

We could also just hit L with all our key frames selected.

I like typing numbers into the node directly,

as it's' easy to be very specific, but as you can see,

it can lead to some unexpected results,

so let's look at the other ways we could change the value.

Let's start with a fresh TimeWarp node.

We could change the key frame values directly in the Curve Editor.

We can drag the key frames around or we can click on

them and type in specific values.

This is great, but sometimes I find working in the Curve Editor too fiddly,

especially when I'm using a Wacom tablet,

so instead we could also use the Dope Sheet.

If we make sure that the key frames for the lookup values are visible,

we can drag them along the timeline.

So now we have our clip sped up by a factor of four,

so it's playing back at the read speed.

We can change the length of our project to match the new length of this clip,

1001 to 1085.

Let's do that in our Project Settings panel.

So let's summarize what we've covered in this module.

You want to have nailed down the exact footage you want

to work with before getting to Nuke.

It's much easier to go through large chunks of footage in an edit

application than it is in a compositing tool.

Like most things that we'll do in Nuke,

there are many different ways to achieve the same result,

but even if the result is the same each option will

have its advantages over others.

Always try to make your Nuke script as clear and concise as you can,

and that doesn't always mean just using as few nodes as possible.

It's good practice to separate major operations into individual nodes.

You can use expressions and Text nodes to help you keep

track of your retimes and troubleshoot anything that isn't

working the way you expected.

Where possible, try not to trim off extra frames in a permanent operation.

Also, try to set up your scripts,

so that you can extend the frame range easily if necessary.

If you have the option,

try to set up your retimes using frame numbers rather than speed values.

It will allow you to be much more flexible with your project.