Is ConvertFPS(25) a no-op on a 25fps clip?

[leoenc]

If I use ConvertFPS(25) on a footage that is already 25 fps, will the function try to do a conversion or will it ignore it completely?

The reason for this is batch encoding of clips with different FPS, so I would like to know if there's any reason not to always include ConvertFPS(25) in my scripts.

[Gavino]

It will blindly go ahead with the 'conversion', but this will just return the original frames. The overhead will be very small, so you may choose just to ignore it. If you want to avoid it, you can check the framerate in the script and make the conversion conditional.

[JohannesL]

last.FrameRate() == 25 ? last : last.ConvertFPS(25)

[leoenc]

@Gavino
Following your comment I have ran some benchmarks and found out that the performance hit is 15%, which is quite a lot to me.

@JohannesL
Thanks, this is exactly what I needed!

[Gavino]

Following your comment I have ran some benchmarks and found out that the performance hit is 15%, which is quite a lot to me.
I would call that quite a lot too, and it surprises me.
What are the two scripts you are comparing to get this figure?

[leoenc]

Quite simple scripts (with and without the ConvertFPS function):

DGdecode_mpeg2source("water.d2v")
Lanczos4resize(1920,1080)
ConvertFPS(25)
Trim(0,1500)

[Gavino]

I can see nothing in the implementation that would make an unnecessary ConvertFPS() suffer a noticeable performance hit. It should take no longer than Trim(), for example (ie virtually no time at all).

How are you measuring the performance? I did a quick test using VirtualDub's 'video analysis pass' and found variations in speed even with repeated runs of an unchanged script, so maybe the results are not conclusive.

[leoenc]

Using x264 encode.

[kemuri-_9]

shouldn't ConvertFPS() be gathering prev and next frames to cache them for the frame blending it would perform (were the FPS rate different than the source)?

that could be affecting the speed...

[Gavino]

Normally it does, yes, but when the input frame rate is the same as the output rate, it is smart enough just to return the corresponding input frame.

More precisely, if it realises the blending for the current output frame will be (close to) 100% of one frame and 0% of the other, it only fetches the '100%' frame. This will always be the case when the input and output frame rates are the same.