SlowMo: Simple slow motion, using interpolation

[spoRv]

###########################################################################################
### SlowMo 1.01: Simple slow motion, using interpolation                                ###
###                                                                                     ###
### Usage:   SlowMo(clip,multiplier)                                                    ###
###                                                                                     ###
### Example: want to make clip to play at half rate                                     ###
###                                                                                     ###
###          SlowMo(clip,2) - or just SlowMo(clip) as 2 is the default value            ###
###                                                                                     ###
### AviSynth script made by spoRv (http://blog.sporv.com) - Created: 2016-12-05         ###
###                                                                                     ###
### Creative Commons 4,0 - Attribution-ShareAlike 4.0 International (CC BY-SA 4.0)      ###
### Link to the licence page: https://creativecommons.org/licenses/by-sa/4.0/           ###
###########################################################################################

function slowmo(clip clip, int "mul") {
num=clip.FrameRateNumerator
den=clip.FrameRateDenominator
mul=default(mul,2)
clip.assumefps(num,den)
backward_vec = clip.MVAnalyse(blksize=16, isb = true, chroma=false, pel=1, searchparam=1, idx=1)
forward_vec = clip.MVAnalyse(blksize=16, isb = false, chroma=false, pel=1, searchparam=1, idx=1)
last.MVFlowFps(backward_vec, forward_vec, num=num*mul,  den=den, mask=0, idx=1)
assumefps(num,den)
}

Needed to slow a shot in a clip, I searched for a proper script, but haven't found it; I thought to use InterFrame, and assumefps at half the final rate, but was too "heavy" for my old PC... I just needed something better than ConvertFPS...

Found a code here: http://www.avsforum.com/forum/26-hom...ame-rates.html - take it, slightly modified - with my limited knowledge - and corrected the most important thing, that nobody seems to take in account: when a film (23.976fps = 24000/1001) must be converted to double frame (for interframe purpose or, like in this case, for a slow motion) it should be 48000/1002 and NOT 48000/1001... with this error, an entire movie will have many frames less, and audio will be audibly out of sync after few minutes. I was wrong, 48000/1001 is the right number; corrected the code to reflect this.

My little contribution; hope this code is right (if not, feel free to correct/improve it) and could be useful for someone.

[FranceBB]

It's always good to have a filter to do this kind of things in avisynth.
I'm gonna try it tomorrow, as I'm at work right now

[jmartinr]

Originally Posted by spoRv

it should be 48000/1002 and NOT 48000/1001.

That can't be right. Please explain.

[ChaosKing]

(48000/1002) / 2 ~= 23,952
(48000/1001) / 2 ~= 23,976

[Groucho2004]

You guys realize that this "script" is an example from the MVTools2 manual with a simple AssumeFPS() at the end, right? There are also a shitload of variations of this all over this forum.

The "made by" and "creative license" are ridiculous.

[johnmeyer]

I agree that this doesn't really advance the state of the art much and, since it is a function, it really should have a little more packed into it that the average user might not think of doing if he or she was just going to use the cookbook code in the documentation.

But there is a MUCH bigger issue that even Groucho2004 didn't pick up on: this function uses the obsolete MVTools plugin!!! That plugin is ancient history, almost a decade old, and it has completely and totally been superseded by MVTools2.

I have over a dozen slow-mo scripts that I've written (or stolen), and I just scanned through them. Here are some things the OP might want to consider adding:

1. Use MVTools2 NOT the old MVTools!!!!
2. Normally the block size is large for doing slow motion, so having a fixed block size of 16 is probably OK. However, you can get different results by using the overlap parameter. That needs to be used.
3. There are variations on the slo-mo script which use MRecalculate (something introduced in MVTools2 as it was updated). The OP needs to try this out and see if it produces better and/or faster results.
4. Use prefiltering for the vector clip. Removegrain is often used, although I've seen fft3D and other filters used as well.
5. Once you update to use the much better (and multi-threaded) MVTools2, there are all sorts of other parameters you should play with, such as pel=2, search=3, etc.

I too am confused by the denominator of 1002. I don't think that is right, and would love to understand the thinking behind it. The 1000/1001 multiplier is required to accommodate the NTSC color convention. That same ratio is used for both 24 and 30 fps material, yielding 23.976 and 29.97 respectively (rounded). I sort of understand the thinking that may have lead to using 1000/1002 for 48 fps, but I don't think it is correct.

Finally, I would suggest making a generalized version of the function which can also handle interlaced video.

So, while I applaud the effort, I think it needs some serious rework before it can be useful for slow motion in the year 2016.

[johnmeyer]

P.S. Here is some code to get the OP started re-writing the function to use MVTools2. This is nothing special, and is only slightly more advanced than what is in the documentation:

prefiltered = RemoveGrain(source,2)
super = MSuper(source,hpad=16, vpad=16, levels=1) # one level is enough for MRecalculate
superfilt = MSuper(prefiltered, hpad=16, vpad=16) # all levels for MAnalyse
backward = MAnalyse(superfilt, isb = true, blksize=16,overlap=8,search=3,dct=0)
forward = MAnalyse(superfilt, isb = false, blksize=16,overlap=8,search=3,dct=0)
forward_re = MRecalculate(super, forward, blksize=8, thSAD=100)
backward_re = MRecalculate(super, backward, blksize=8, thSAD=100)
MFlowFps(source,super, backward_re, forward_re, num=30000, den=1001,ml=200,mask=2)

If I were to write a function, I'd look at every single parameter for each individual function in the MVTools2 slow motion chain, and play around with it in order to see its impact on slow motion. The key to writing this function is to produce something which produces the minimum number of artifacts. The place where these artifacts are most prominent are:

1. Strong vertical lines. A horizontal pan of a picket fence is a real torture test.

2. Object reveal. When a background object emerges from behind a foreground object, you often get all sorts of strange morphing.

I'd also look at adding some sort of masking to the function.

[Groucho2004]

Originally Posted by johnmeyer

5. Once you update to use the much better (and multi-threaded) MVTools2

Even though there is a version of MVTools2 (out of way too many floating around) that can make use of avstp.dll, all newer versions by Fizick and pinterf are not multi-threaded.

And yes John, I missed that the script is for MVTools(1).

[spoRv]

@Groucho2004:
Thanks for the input; "made by" because I simply copy&paste some code, and added some variation... not that difficult, I must admit, but I've done it, so, that's it. Creative Commons is a nice addition, albeit unuseful, I suspect!

@johnmeyer:
Constructive feedbacks are always welcome! As I'm not an avisynth programmer, this is a simple function I added to my library, concious that a very better version could be done; but, in comparison to the basic ConvertFPS, it's better, and it is sufficent for my purposes. So, I would be more than happy if you would like to make a complete rework using better/more efficient filters,

48000/1002 is the right calculation for the slow motion, half speed, of film rate, and NOT for the 48fps, that should be 48000/1001 - even if I don't know if there is any standard that supports it. For NTSC half speed, is 60000/1002, while for PAL a simple 50/1 - or 50000/1000
THIS IS NOT TRUE, my fault, going to correct the script right now; please, do NOT use avisynth during renal colis, it could happen your mind is not that lucid...

[Groucho2004]

There was a lot of discussion about this going on in the MVTools threads:
http://forum.doom9.org/showthread.ph...04#post1783504
http://forum.doom9.org/showthread.ph...95#post1785795

Originally Posted by spoRv

48000/1002 is the right calculation for the slow motion, half speed, of film rate, and NOT for the 48fps, that should be 48000/1001 - even if I don't know if there is any standard that supports it. For NTSC half speed, is 60000/1002, while for PAL a simple 50/1 - or 50000/1000

Where do you get the 1002 from? If you want to half the speed you need only double the numerator. The NTSC offset doesn't change.

[spoRv]

My fault! You are all right, and I'm a completely stupid...
Going to correct the script right now!

It was something like 48000/2002 which is equal to 24000/1001 - what I was thinking...

Originally Posted by spoRv

48000/1001/2 != 24000/1001

You're joking, right? Basic algebra proves you wrong.

ETA: Seems you've spotted your mistake.

[BetA13]

can i use this for realtime rendering with my videos?
lets say id use mpchc with ffdshow - avisynth.

where or how should i get started to use this with my videp player?

thanks for any help

[johnmeyer]

For real time rendering you might want to look into SVPFlow. That is what is was built for (i.e., real-time interpolation).

Groucho2004, thanks for those links. The second one, linking to StainlessS' code, is especially interesting.

[BetA13]

Originally Posted by johnmeyer

For real time rendering you might want to look into SVPFlow. That is what is was built for (i.e., real-time interpolation).

Groucho2004, thanks for those links. The second one, linking to StainlessS' code, is especially interesting.

yes, i do use svp, BUT, i do want slow motion..so, how do i do it..

[Groucho2004]

Here is a clip I have been using to test the slo-mo functions. Watch the motion estimation go nuts on the striped patterns.

[johnmeyer]

Originally Posted by Groucho2004

Here is a clip I have been using to test the slo-mo functions. Watch the motion estimation go nuts on the striped patterns.

Interesting test case. I played around with it and, while certainly not perfect, I could live with the results of this script:

prefiltered = RemoveGrain(source,22)
super = MSuper(source,hpad=16, vpad=16, levels=1) # one level is enough for MRecalculate
superfilt = MSuper(prefiltered, hpad=16, vpad=16) # all levels for MAnalyse
backward = MAnalyse(superfilt, isb = true, blksize=16,overlap=4,search=3,dct=0)
forward = MAnalyse(superfilt, isb = false, blksize=16,overlap=4,search=3,dct=0)
forward_re = MRecalculate(super, forward, blksize=8, overlap=2, thSAD=100)
backward_re = MRecalculate(super, backward, blksize=8, overlap=2, thSAD=100)
output=MFlowFps(source,super, backward_re, forward_re, num=48000, den=1001,ml=200,mask=2)
output=output.selectodd()
interleave(source,output)

As you can see, I made sure that every other frame is an original, so you can easily see the merging and breaking of the stripes.

At the end of the clip, where she lowers her leg, the script does produce ghosting, although when played, this artifact will not look too bad, at least compared to the "morphological" artifacts that you get when the stripes break.

[Groucho2004]

Originally Posted by johnmeyer

Interesting test case. I played around with it and, while certainly not perfect, I could live with the results of this script

That's better than all my attempts. Very nice.

[johnmeyer]

Originally Posted by Groucho2004

That's better than all my attempts. Very nice.

Thanks! Unfortunately, as you well know, this code will fail on some other clip. It's just the nature of the current state of the art, I guess.