Convert 60FPS video to 30fps

[Rob105]

I want to convert this video (https://forum.videohelp.com/attachments/74614-1698757593/60fps%20on%2060fps%20timeline.mp4) from 60fps to 30fps, but not by simply dropping frames,

First i want to make smoothing or motion blur, something like blend each frame with next and previous one to make more smooth movement before i drop frames, how i achieve this in AviSynth+?

[poisondeathray]

One way for 50/50 simple blending would be


merge(selecteven, selectodd)


QTGMC has a shutterblur you can play with

[Rob105]

One way for 50/50 simple blending would be


merge(selecteven, selectodd)


That's bit too simplistic, i remember there were some filter in VirtualDub that allowed to merge frames and you could specify how many frames back and how many frames forth from each frame to use for merging together. I am trying to have same functionality in AviSynth+.

[poisondeathray]

Clipblend in avs+
http://avisynth.nl/index.php/ClipBlend

[anton_foy]

If you want motionblur-like, try temporalsoften?
Or maybe faster is Dogway's ex_fluxsmooth with zero spatial and high temporal radius.

[Rob105]

Actually my frames are so far apart (fast panning) that i am getting real mess merging just 2 frames together.

This is from merging one frame with the next one, you can see the tree stem on the left of the house is so far apart.

24fps panning speed 17.5° a second.


Source clip here: https://www.upload.ee/files/15883560/1I12288_ISO_1600.mp4.html
https://i.postimg.cc/Vk36Rkkj/photo-2023-10-31-17-32-45.jpg

Guess i am out of options here except using something like Topaz Video AI to rebuild the missing frames?

[FranceBB]

Source clip here: https://www.upload.ee/files/15883560/1I12288_ISO_1600.mp4.html

I wanted to help, but that's not the source clip.
That clip (1I12288_ISO_1600.mp4) is 24.255 FPS
Perhaps you meant going from 24.255p (odd framerate by the way) to 60p?


Actually my frames are so far apart (fast panning) that i am getting real mess merging just 2 frames together.

[...] you can see the tree stem on the left of the house is so far apart.

Yes, that's blending, it's "fine" 'cause it's what ConvertFPS() does.



Guess i am out of options here except using something like Topaz Video AI to rebuild the missing frames?


Of course not!
Never underestimate the power of Avisynth, what you need is linear interpolation and what can achieve it is MVTools! ;)


video=LWLibavVideoSource("1I12288_ISO_1600.mp4")
audio=LWLibavAudioSource("1I12288_ISO_1600.mp4", stream_index=1)
AudioDub(video, audio)

super=MSuper(pel=1, hpad=0, vpad=0)
backward_1=MAnalyse(super, chroma=false, isb=true, blksize=16, blksizev=16, searchparam=3, plevel=0, search=3, badrange=(-24))
forward_1 =MAnalyse(super, chroma=false, isb=false, blksize=16, blksizev=16, searchparam=3, plevel=0, search=3, badrange=(-24))
backward_2 = MRecalculate(super, chroma=false, backward_1, blksize=8, blksizev=8, searchparam=0, search=3)
forward_2 = MRecalculate(super, chroma=false, forward_1, blksize=8, blksizev=8, searchparam=0, search=3)
MBlockFps(super, backward_2, forward_2, num=60000, den=1000, mode=0)


https://i.imgur.com/Dk4wZNa.png

Output here (link valid for 7 days): https://we.tl/t-0MPICUz25M

[FranceBB]

Bonus comment:

Luma is out of range as the bushes in the lower part of the image are too low and the sky highlights are too high with the highlights above 0.7V (i.e above 235 in this 8bit footage).
In other words, realistically, the framerate conversion is not the only problem you're gonna have to deal with.

https://i.imgur.com/m8Z33gV.png

luckily it was possible to save some details with a soft highlight rollback, so the final encode is gonna be:



#Indexing
video=LWLibavVideoSource("1I12288_ISO_1600.mp4")
audio=LWLibavAudioSource("1I12288_ISO_1600.mp4", stream_index=1)
AudioDub(video, audio)

#Levels conversion
Levels(0, 1, 255, 16, 235, coring=false)

#Linear Interpolation
super=MSuper(pel=1, hpad=0, vpad=0)
backward_1=MAnalyse(super, chroma=false, isb=true, blksize=16, blksizev=16, searchparam=3, plevel=0, search=3, badrange=(-24))
forward_1 =MAnalyse(super, chroma=false, isb=false, blksize=16, blksizev=16, searchparam=3, plevel=0, search=3, badrange=(-24))
backward_2 = MRecalculate(super, chroma=false, backward_1, blksize=8, blksizev=8, searchparam=0, search=3)
forward_2 = MRecalculate(super, chroma=false, forward_1, blksize=8, blksizev=8, searchparam=0, search=3)
MBlockFps(super, backward_2, forward_2, num=60000, den=1000, mode=0)



https://i.imgur.com/YJ34J20.png

[Rob105]

Problem of making 24FPS video was more smooth was important to me. Thanks for showing me how to solve it with AviSynth+

There's one observation i made that puzzles me, on the first code without Levels() adjustment there are some frames where still can see the effects of overlaying images.

e.g. frame #161
https://forum.doom9.org/attachment.php?attachmentid=18504&d=1699011100

However when Levels() adjustment line is added then this problem is not showing anymore.
Seems like overlay problem is fixed when when output levels for highlights are limited to 235, but the frame in question even without levels looks the same color to me, don't know why interpolation algorithm could not match it good enough?


I wanted to help, but that's not the source clip.
That clip (1I12288_ISO_1600.mp4) is 24.255 FPS

I got confused a bit, its a panning speed test on different FPS and shutter speeds i made so i have many source videos, here is the video at 60FPS. https://www.upload.ee/files/15890162/1I11520_ISO_2400.mp4.html

[FranceBB]

Problem of making 24FPS video was more smooth was important to me. Thanks for showing me how to solve it with AviSynth+

No problem. :)
The more the open source community grows and people move away from paid closed source proprietary solutions the happier I am.


There's one observation i made that puzzles me, on the first code without Levels() adjustment there are some frames where still can see the effects of overlaying images.

e.g. frame #161

However when Levels() adjustment line is added then this problem is not showing anymore.
Seems like overlay problem is fixed when when output levels for highlights are limited to 235, but the frame in question even without levels looks the same color to me, don't know why interpolation algorithm could not match it good enough?


That's correct.
This is frame 161 with MVTools and luma out of range:

https://i.imgur.com/oP49Ti1.png

and this is the same frame but passed to MVTools AFTER luma was brought back to limited tv range:

https://i.imgur.com/Q8c5WNQ.png

This clearly shows that during the motion vector calculations when luma is actually sitting perfectly inside the limited tv range references are found and the frames are correctly interpolated, however when luma is out of range, those matches are not found.
It's not really a matter of limited vs full range but rather the fact that the stream is signalled as limited tv range and has out of range values. If it was actually full range flagged as full range, you wouldn't have seen this difference 'cause it would have found the matches.
I guess (but I'm speculating here) that MVTools actually doesn't analyze the "out of range" part if the stream is flagged as limited to speed things up in the processing, however if you wanna have a definitive answer you gotta ask DTL as he's far more familiar with MVTools than I am.

[Frank62]

I guess (but I'm speculating here) that MVTools actually doesn't analyze the "out of range" part if the stream is flagged as limited to speed things up in the processing, however if you wanna have a definitive answer you gotta ask DTL as he's far more familiar with MVTools than I am.

Interesting speculation. I sometimes had situations when MVTools simply didn't interpolate, but only with some frames of a video, and I couldn't find out why.

[StainlessS]

Nice one FaBB, I never dreamed that simple levels would provide such a great improvement, kudos, truly FaBBulous :)

I also note,

From MvAnalyse on Wiki,
dct (default 0)

Using of block DCT (frequency spectrum) for blocks difference (SAD) calculation. In particular it can improve motion vector estimation at luma flicker and fades.
0 Usual spatial blocks, do not use DCT.
1 Use block DCT instead of spatial data (slow for block size 8x8 and very slow for other sizes).
2 Mixed spatial and DCT data; weight is dependent on mean frame luma difference.
3 Adaptive per-block switching from spatial to equal-weighted mixed mode (experimental, a little faster).
4 Adaptive per-block switching from spatial to mixed mode with more weight of DCT (experimental, a little faster).
5 SATD instead of SAD for luma.
6 Same as 2 only use SATD.
7 Same as 3 only use SATD.
8 Same as 4 only use SATD.
9 Similar to 2, use SATD and weight ranges from SAD only to equal SAD & SATD.
10 Similar to 3/4,use SATD weight is on SAD, only on strong luma changes.

Modes 5 to 10 were added in v1.9.5.3.


But DCT of non 0 can be very slow.

Just curious, Does dct (any of above non 0) provide clean image for that frame ? [if so, which ?]
(EDIT: without the Levels whotsit)

[johnmeyer]

There are several issues that could cause MVTools2 to break when levels are out of range. I ran into this one many years ago:

https://forum.doom9.org/showpost.php?p=1576930&postcount=14

The other is scene change detection. If that gets triggered, MVTools2 turns off for that frame. You might be able to solve the problem just by changing the scene detection threshold.

[StainlessS]

Yeah the 127 pixels (pel 2) and 63 pixels (pel 4) thingy [EDIT vector max] is very restricting and one of the major reasons that you
always had problems with your rapid panning football games.
I presume that the problem would though disappear (to some degree) if pre-converted to eg 16 BitsPerComponent.

EDIT: Where for 16 bit, pel 2 vector restriction would be 32767 (instead of 127) and pel 4 vector would be max 16383 (instead of 63) pixel pan.
EDIT: You might also have to increase search radius (maybe called SearchParam), not sure.

EDIT: From MvTools, Manalyse(int "search"=4,int "searchparam"=2,int "pelsearch"=pel)

search, searchparam, pelsearch

search decides the type of search at every level, searchparam is an additional parameter (step, radius) for this search, and pelsearch is the radius parameter at finest (pel) level. Below are the possible values for the search type:
0 'OneTimeSearch'. searchparam is the step between each vectors tried (if searchparam is superior to 1, step will be progressively refined).
1 'NStepSearch'. N is set by searchparam. It's the most well known of the MV search algorithm.
2 Logarithmic search, also named Diamond Search. searchparam is the initial step search, there again, it is refined progressively.
3 Exhaustive search, searchparam is the radius (square side is 2*radius+1). It is slow, but it gives the best results, SAD-wise.
4 Hexagon search, searchparam is the range. (similar to x264).
5 Uneven Multi Hexagon (UMH) search, searchparam is the range. (similar to x264).
6 pure Horizontal exhaustive search, searchparam is the radius (width is 2*radius+1).
7 pure Vertical exhaustive search, searchparam is the radius (height is 2*radius+1).

[Rob105]

No problem. :)
The more the open source community grows and people move away from paid closed source proprietary solutions the happier I am.
I am not into video production, not understand what "TV range" means, if i want to use MvTools again how can i tell if my other video's luma is within TV range limits, is TV range equals 16-235?

Tired this video its high resolution and its 10 bit, MvTools show's entire screen green. Apart from that its a 60FPS video so how do i smooth out panning frame flow when panning, do i need to convert to lower/higher fps or i can keep fps same?
https://www.upload.ee/files/15894838/Untitled.mp4.html

[StainlessS]

is TV range equals 16-235?
For 8 bit, Yes. [0->255 is PC Range]

how can i tell if my other video's luma is within TV range limits
See FranceBB profile (click on his name above his avatar, and select "View Public Profile")
Then at bottom of his profile, click the Videotek link. [Also try click on "Statistics" tab]
(Just showing you [or others] how to find his threads/posts, just incase you did not know).
Or, direct link here [Videotek]:- https://forum.doom9.org/showthread.php?t=175249

EDIT: Videotek link is also present in FranceBB sig, under each and every one of his D9 posts.

[manolito]

Hi folks,

just out of curiosity, can someone point out the basic difference between FranceBB's frame rate interpolation script and the older johnmeyer script?


## JM_FPS (johnmeyer)

prefiltered = RemoveGrain(source, 22)
super = MSuper(source, hpad = 16, vpad = 16, levels = 1, sharp = 1, rfilter = 4) # one level is enough for MRecalculate
superfilt = MSuper(prefiltered, hpad = 16, vpad = 16, sharp = 1, rfilter = 4) # all levels for MAnalyse
backward = MAnalyse(superfilt, isb = true, blksize = BlkSize, overlap = 4, search = 3, dct = Dct)
forward = MAnalyse(superfilt, isb = false, blksize = BlkSize, overlap = 4, search = 3, dct = Dct)
forward_re = MRecalculate(super, forward, blksize = 8, overlap = 2, thSAD = 100)
backward_re = MRecalculate(super, backward, blksize = 8, overlap = 2, thSAD = 100)
out = MFlowFps(source, super, backward_re, forward_re, num = fps_num, den = fps_den, blend = false, ml = 200, mask = 2)

return out


## FranceBB

super=MSuper(pel=1, hpad=0, vpad=0)
backward_1=MAnalyse(super, chroma=false, isb=true, blksize=16, blksizev=16, searchparam=3, plevel=0, search=3, badrange=(-24))
forward_1 =MAnalyse(super, chroma=false, isb=false, blksize=16, blksizev=16, searchparam=3, plevel=0, search=3, badrange=(-24))
backward_2 = MRecalculate(super, chroma=false, backward_1, blksize=8, blksizev=8, searchparam=0, search=3)
forward_2 = MRecalculate(super, chroma=false, forward_1, blksize=8, blksizev=8, searchparam=0, search=3)
MBlockFps(super, backward_2, forward_2, num=60000, den=1000, mode=0)



The main difference I see is that for the last line FranceBB uses MBlockFps while johnmeyer uses MFlowFps. Maybe someone can test these different scripts with a few sources and point out the differences...


Cheers
manolito

[johnmeyer]

That script of mine, though extensive trial and error, ended up with a "magic" set of parameters which produced far fewer artifacts than other scripts in a thread I participated in about ten years ago. What this means is that each and every parameter in that script matters.

Therefore, in addition to looking at the different type of motion estimation, you have look at all the other differences, of which there are many.

As for MFlow vs. MBlock, look at the MVTools2 Documentation (http://www.avisynth.nl/users/fizick/mvtools/mvtools2.html). Here are the relevant quotes from that document:

MFlowFps
"The function uses pixel-based motion compensation (as MFlow, MFlowInter)."

MBlockFps
"The function uses block-based partial motion compensation."

MFlowFPS is what you want to use for any sort of frame rate conversion, unless all you care about is speed.

[Sharc]

Case 60fps to 30fps, by interlacing (60p -> 30i):
SeparateFields()
SelectEvery(4,0,3).Weave()

Case 24fps to 60fps by interpolation:
You may want to try RIFE. Gives less interpolation artifacts than mvtools2.
http://avisynth.nl/index.php/RIFE
Something along the line
ffms2("1I12288_ISO_1600.mp4")
assumefps(24)
RGB=z_ConvertFormat(pixel_type="RGBPS", colorspace_op="709:709:709:l=>rgb:709:709:f") # RIFE requires RGB floating point
RIFE=RGB.RIFE(gpu_thread=1, model=9, fps_num=60000, fps_den=1001, sc=true, sc_threshold=0.3) # motion interpolation
YV12=RIFE.z_ConvertFormat(pixel_type="YUV420P8", colorspace_op="rgb:709:709:f=>709:709:709:l") #back to YV12
return YV12
https://mega.nz/file/eJMHUSqA#LoeDtAJ_v_gSIu1nOge2EhET2UcBXUE6WxqcxrVmEaw


(Edit:
Or if the purpose is just to make the 24fps NTSC (29.97i) compliant, apply 3-2 pulldown.)

[Sharc]

how can i tell if my other video's luma is within TV range limits, is TV range equals 16-235?
In Avisynth
Histogram("classic") #puts the waveform monitor (luma) sideways
or
turnright().histogram("classic").turnleft() #puts the waveform monitor (luma) on top


The white wavy traces should not extend into the brown bars but stay within the black area.

Edit:
or use
Histogram("levels") to show the distribution of Y,Cb,Cr

[DTL]

More correct FPS 2x downsample is filter or manual motion blur (low-pass temporal filtering) and next downsample.

Filter-based is
MFlowBlur()
SelectEvery(2,1)

Manual is creating many (10..20..100 ?) time-sampled intermediate frames (+- half of temporal filtering window around current real time sampled frame) with MCompensate and apply weighted-average convolution with Average() (using equal or non-equal time coefficients).

Number of frames to create may be decreased if apply directional blur (for each MV for each block/sample) but it looks still not implemented in mvtools.

And yes - if mvtools not process some frames it may mean scenechange detector active and invalidate some frames. To adjust it thSCD1 param may be tested to higher values.

About levels 'range' - as I understand mvtools not use this metadata and always process in 0..255 range (for 8bit). So it should work equally good with any levels range mapping.

[StainlessS]

Maybe Levels reduction just reduces SAD below the SAD thresholds.

[DTL]

If user compress range - yes. It can cause more quantization noise with 8bit samples calculation. But if user expands range - it may cause clipping of overwhites/underblacks and also add large 'quantization noise'. Possible best safe solution is to apply auto-range for each frame (analyse all samples range and apply expansion to 0..255 if possible). But 8bit -> 8bit operations of levels tweaking also adds significant quantization noise. So better is work with immediate 16bit domain after 'auto-levels' operation (it will make MAnalyse slower).

[manolito]

I am still interested in the differences between the old and trusted johnmeyer script and the more current FranceBB script for frame rate conversions. To test these two scripts side by side I converted the FranceBB script to a function which accepts the same parameters as the johnmeyer script and made a few test conversions.

These were my scripts:

johnmeyer:
# Motion Protected FPS converter script by johnmeyer from Doom9
# Slightly modified interface by manolito
# Requires MVTools V2 and RemoveGrain
# Also needs fftw3.dll in the System32 or SysWOW64 folder for Dct values other than 0


function jm_fps(clip source, float "fps", int "BlkSize", int "Dct")
{
fps = default(fps, 25.000)
fps_num = int(fps * 1000)
fps_den = 1000
BlkSize = default(BlkSize, 16)
Dct = default(Dct, 0)

prefiltered = RemoveGrain(source, 22)
super = MSuper(source, hpad = 16, vpad = 16, levels = 1, sharp = 1, rfilter = 4) # one level is enough for MRecalculate
superfilt = MSuper(prefiltered, hpad = 16, vpad = 16, sharp = 1, rfilter = 4) # all levels for MAnalyse
backward = MAnalyse(superfilt, isb = true, blksize = BlkSize, overlap = 4, search = 3, dct = Dct)
forward = MAnalyse(superfilt, isb = false, blksize = BlkSize, overlap = 4, search = 3, dct = Dct)
forward_re = MRecalculate(super, forward, blksize = 8, overlap = 2, thSAD = 100)
backward_re = MRecalculate(super, backward, blksize = 8, overlap = 2, thSAD = 100)
out = MFlowFps(source, super, backward_re, forward_re, num = fps_num, den = fps_den, blend = false, ml = 200, mask = 2)

return out
}



FranceBB:
# Motion Protected FPS converter script by FranceBB from Doom9
# Slightly modified interface by manolito


function fbb_fps(clip source, float "fps")
{
fps = default(fps, 25.000)
fps_num = int(fps * 1000)
fps_den = 1000


super = MSuper(source, pel=1, hpad=0, vpad=0)
backward_1 = MAnalyse(super, chroma=false, isb=true, blksize=16, blksizev=16, searchparam=3, plevel=0, search=3, badrange=(-24))
forward_1 = MAnalyse(super, chroma=false, isb=false, blksize=16, blksizev=16, searchparam=3, plevel=0, search=3, badrange=(-24))
backward_2 = MRecalculate(super, chroma=false, backward_1, blksize=8, blksizev=8, searchparam=0, search=3)
forward_2 = MRecalculate(super, chroma=false, forward_1, blksize=8, blksizev=8, searchparam=0, search=3)
out = MBlockFps(source, super, backward_2, forward_2, num=fps_num, den=fps_den, mode=0)

return out
}


I made a couple of test conversions using some HD source clips. I did not change the video resolution of 1280x720, I just converted the frame rate to 30 fps. The results for both scripts looked both very good to me, I could not see any quality differences. The FranceBB script was a bit faster though.

I wonder if some of you guis could test both functions and try to identfy the differences between the two scrips.


Cheers
manolito

[DTL]

I think none of the working scripts in this thread above solve initial task of thread starter about creation of motion blur before FPS decreasing. It is expected with either MFlowBlur() or script-based intermediate frames convolution.

I also see users typically prefer block-based motion compensation + overlap instead of Flow implementation in the mvtools. So for manual motion blur convolution MCompensate expected to make better results. Also degraining mostly work with block-based motion compensation + overlap.

[DTL]

Eh - MCompensate still can run only full timesteps compensation (it is really +1 new feature in the list of new features of mvtools required). And as I not like MFlow so I tried MBlockFPS to create immediate frames for motion blur convolution. Though it looks I do not select all frames correct so length of blur is not equal at different frames (also for unknown reason it starts to work only from output frame 10).

Also attempt to use non-1 blur kernel still not work (output green color - may be bug in Average if provide non-normalized sum of weights ?).

Here is current script for 10 immediate phases for motion blur:

LoadPlugin("ffms2.dll")
LoadPlugin("mvtools2.dll")
LoadPlugin("Average.dll")

FFMpegSource2("1I12288_ISO_1600.mp4")

ConvertToYV12()

mb_steps_tr=5

Function MBKrn(float time)
{
mb_steps_tr=5
return Float(Float(1)/Float(mb_steps_tr*2)) # maxblur

#arg=Pi()*time
#return Float(Sin(arg)/Float(mb_steps_tr*2)) # cos-attempt, need normalizing sum=1

}

super=MSuper(pel=2)
bw_1=MAnalyse(super, chroma=true, isb=true, delta=1, searchparam=3, search=3, overlap=4)
fw_1=MAnalyse(super, chroma=true, isb=false, delta=1, searchparam=3, search=3, overlap=4)

high_fps=MBlockFps(super, bw_1, fw_1, num=last.FrameRateNumerator*mb_steps_tr*2)


ph_1d10=SelectEvery(high_fps, 10,0)
ph_2d10=SelectEvery(high_fps, 10,1)
ph_3d10=SelectEvery(high_fps, 10,2)
ph_4d10=SelectEvery(high_fps, 10,3)
ph_5d10=SelectEvery(high_fps, 10,4)
ph_6d10=SelectEvery(high_fps, 10,5)
ph_7d10=SelectEvery(high_fps, 10,6)
ph_8d10=SelectEvery(high_fps, 10,7)
ph_9d10=SelectEvery(high_fps, 10,8)
ph_10d10=SelectEvery(high_fps, 10,9)



ph_1d10 = Trim(ph_1d10, 0, 90)
ph_2d10 = Trim(ph_2d10, 0, 90)
ph_3d10 = Trim(ph_3d10, 0, 90)
ph_4d10 = Trim(ph_4d10, 0, 90)
ph_5d10 = Trim(ph_5d10, 0, 90)
ph_6d10 = Trim(ph_6d10, 0, 90)
ph_7d10 = Trim(ph_7d10, 0, 90)
ph_8d10 = Trim(ph_8d10, 0, 90)
ph_9d10 = Trim(ph_9d10, 0, 90)
ph_10d10 = Trim(ph_10d10, 0, 90)


#Average(ph_1d10, 0.1, ph_2d10, 0.1, ph_3d10, 0.1, ph_4d10, 0.1, ph_5d10, 0.1, ph_6d10, 0.1, ph_7d10, 0.1, ph_8d10, 0.1, ph_9d10, 0.1, ph_10d10, 0.1)
Average(ph_1d10, MBKrn(0.1), ph_2d10, MBKrn(0.2), ph_3d10, MBKrn(0.3), ph_4d10, MBKrn(0.4), ph_5d10, MBKrn(0.5), ph_6d10, MBKrn(0.6), ph_7d10, MBKrn(0.7), ph_8d10, MBKrn(0.8), ph_9d10, MBKrn(0.9), ph_10d10, MBKrn(1.0))


SelectEvery(2,0)


Also Average() requires equal number of frames to work so poor Trim() currently used to make all immediate clips equal in frame count.

With MFLowBlur it is

LoadPlugin("ffms2.dll")
LoadPlugin("mvtools2.dll")
LoadPlugin("Average.dll")

FFMpegSource2("1I12288_ISO_1600.mp4")

ConvertToYV12()

super=MSuper(pel=2)
bw_1=MAnalyse(super, chroma=true, isb=true, delta=1, searchparam=3, search=3, overlap=4)
fw_1=MAnalyse(super, chroma=true, isb=false, delta=1, searchparam=3, search=3, overlap=4)

MFlowBlur(super, bw_1, fw_1, blur=100)

SelectEvery(2,0)


But do not have controllable motion blur kernel (of shape and size) and also to make blur length more blur > 100 may be tested, Like blur=200 (though it looks number of artifacts are higher). FlowBlur as expected provides higher number of defects in compare with block-based compensating + full 4x overlap in MBlockFPS.

Edit: MCompensate also have non-documented (?) time-param and can do partial motion compensation. So working script with manual temporal width of motion blur (different Average() lines comment/uncomment) is

LoadPlugin("ffms2.dll")
LoadPlugin("mvtools2.dll")
LoadPlugin("Average.dll")

FFMpegSource2("1I12288_ISO_1600.mp4")

ConvertToYV12()

mb_steps_tr=5

Function MBKrn(float time)
{
mb_steps_tr=5
return Float(Float(1)/Float(mb_steps_tr*2 + 1)) # maxblur

#arg=Pi()*time
#return Float(Sin(arg)/Float(mb_steps_tr*2)) # cos-attempt, need normalizing sum=1

}

super=MSuper(pel=2)
bw_1=MAnalyse(super, chroma=true, isb=true, delta=1, searchparam=3, search=3, overlap=4)
fw_1=MAnalyse(super, chroma=true, isb=false, delta=1, searchparam=3, search=3, overlap=4)

ph_1d10=MCompensate(super, bw_1, mt=false, time=50)
ph_2d10=MCompensate(super, bw_1, mt=false, time=60)
ph_3d10=MCompensate(super, bw_1, mt=false, time=70)
ph_4d10=MCompensate(super, bw_1, mt=false, time=80)
ph_5d10=MCompensate(super, bw_1, mt=false, time=90)
ph_6d10=MCompensate(super, fw_1, mt=false, time=90)
ph_7d10=MCompensate(super, fw_1, mt=false, time=80)
ph_8d10=MCompensate(super, fw_1, mt=false, time=70)
ph_9d10=MCompensate(super, fw_1, mt=false, time=60)
ph_10d10=MCompensate(super, fw_1, mt=false, time=50)

#Average(ph_5d10, 0.333, last, 0.333, ph_6d10, 0.333)
#Average(ph_4d10, 0.2, ph_5d10, 0.2, last, 0.2, ph_6d10, 0.2, ph_7d10, 0.2)
#Average(ph_3d10, 0.1429, ph_4d10, 0.1429, ph_5d10, 0.1429, last, 0.1429, ph_6d10, 0.1429, ph_7d10, 0.1429, ph_8d10, 0.1429)
#Average(ph_2d10, 0.1111, ph_3d10, 0.1111, ph_4d10, 0.1111, ph_5d10, 0.1111, last, 0.1111, ph_6d10, 0.1111, ph_7d10, 0.1111, ph_8d10, 0.1111, ph_9d10, 0.1111)
Average(ph_1d10, 0.0909, ph_2d10, 0.0909, ph_3d10, 0.0909, ph_4d10, 0.0909, ph_5d10, 0.0909, last, 0.0909, ph_6d10, 0.0909, ph_7d10, 0.0909, ph_8d10, 0.0909, ph_9d10, 0.0909, ph_10d10, 0.0909)

#Average(ph_1d10, MBKrn(-0.5), ph_2d10, MBKrn(-0.4), ph_3d10, MBKrn(-0.3), ph_4d10, MBKrn(-0.2), ph_5d10, MBKrn(-0.1), last, MBKrn(0), ph_6d10, MBKrn(0.1), \
ph_7d10, MBKrn(0.2), ph_8d10, MBKrn(0.3), ph_9d10, MBKrn(0.4), ph_10d10, MBKrn(0.5))
SelectEvery(2,0)


The auto-calculation of kernel coefficients still not designed. So only manual for each temporal width of 'box' shaped kernel (max blur with current tr).