FrameRateConverter (Official)

[poisondeathray]

Yes, 2 versions . The Pytorch/CUDA version is significantly faster than Vulkan if you have a Nvidia GPU. But Vulkan is accessible to everyone - so that version should definitely be included for general use

The other issue is model availability - I'm finding 2.3 and 2.4 generally better than the 3.x versions . But we can probably ask HolyWu to make other models available for the Vapoursynth Pytorch version

There was some discussion on why original Vulkan version was slower, but apparently it just is
https://github.com/nihui/rife-ncnn-vulkan/issues/22

[MysteryX]

Originally Posted by poisondeathray

I can't get vapoursynth version to run, never seen this error before

I thought I was storing Core from the initializer and using it elsewhere; perhaps from wrong thread or something. I looked through the code. There was 1 instance where I was storing Core in a field, and it wasn't used at all. So it's not that.

I don't know then...

[ChaosKing]

vs-rife was just updated with 1.8, 2.3 and 2.4 models. https://github.com/HolyWu/vs-rife

[Selur]

Nice! btw. is there some info about what the differences are between the models? (I mean is model xy better suited for content wz?)

--
I also think it would be nice to choose whether
https://github.com/HomeOfVapourSynth...FE-ncnn-Vulkan
or
https://github.com/HolyWu/vs-rife
would be used.

Cu Selur

[Selur]

As a side note, using Beta11:

clip = FrameRateConverter.FrameRateConverter(clip, frameDouble=True, preset="rife", blkSize=8, blkSizeV=8, rife=1, rifeModel=1, rifeTta=False, rifeGpu=0) # new fps: 50

causes blending while

clip = core.rife.RIFE(clip)

does not with this file (Frame 359).
Neither does 'FrameRateConverter.FrameRateConverter(clip, frameDouble=True, blkSize=8, blkSizeV=8)'.

Cu Selur

[Selur]

Any news on RIFE incorporation into FrameRateConverter?

[poisondeathray]

Originally Posted by Selur

As a side note, using Beta11:

clip = FrameRateConverter.FrameRateConverter(clip, frameDouble=True, preset="rife", blkSize=8, blkSizeV=8, rife=1, rifeModel=1, rifeTta=False, rifeGpu=0) # new fps: 50

causes blending while

clip = core.rife.RIFE(clip)

does not with this file (Frame 359).
Neither does 'FrameRateConverter.FrameRateConverter(clip, frameDouble=True, blkSize=8, blkSizeV=8)'.

Cu Selur

You can disable some or all of the frc features . Adding output="flow"gives you interpolation only.

You can set individual masking features you don't want to "0" , such as maskThr, maskOcc, skipThr, blendOver, skipOver



There is an issue with stp ; stp=0 to disable strip detection produces error, but values >0 produce no error msg

File "PATH\FrameRateConverter.py", line 285, in FrameRateConverter
EMstp = havs.ChangeFPS(EMstp, newNum, newDen)
UnboundLocalError: local variable 'EMstp' referenced before assignment

[Dogway]

MysteryX, what's the point of having different mask settings for different clip sizes as shown here? Does it have to do with the MAnalyse vectors?
I ask because it would make sense to have the same mask for the same clip whatever its size is.

This was my test code:

msk="C.BicubicResize(Round(C.Width()/blk/4.0)*4, Round(C.Height()/blk/4.0)*4)
\       .mt_expand(mode= mt_circle(zero=true, radius=1))
\       .mt_binarize(thr,u=-128,v=-128)
\       .Blur(.6)
\       .BicubicResize(1280, 720)"

a=bicubicresize(640,360,-0.5,0.25)   # 12 blksize
b=bicubicresize(854,480,-0.5,0.25)   # 12 blksize
c=bicubicresize(1280,720,-0.5,0.25)  # 16 blksize
d=bicubicresize(1920,1080,-0.5,0.25) # 24 blksize

a=Eval(ReplaceStr(msk,"thr,","120-10").ReplaceStr("blk","11").ReplaceStr("C.","a."))
b=Eval(ReplaceStr(msk,"thr,","120-10").ReplaceStr("blk","12").ReplaceStr("C.","b."))
c=Eval(ReplaceStr(msk,"thr,","120"   ).ReplaceStr("blk","16").ReplaceStr("C.","c."))
d=Eval(ReplaceStr(msk,"thr,","120+10").ReplaceStr("blk","24").ReplaceStr("C.","d."))

StackVertical( \
StackHorizontal(a,b), \
StackHorizontal(c,d))

[pintcat]

Tried a very simple script on beta 11 and got this error:

Avisynth open failure:
Script error: Invalid argument to function "StipeMaskPass"
(FrameRateConverter.avsi, line 376)
(FrameRateConverter.avsi, line 219)

Script was something like

directshowsource(test.mp4)
framerateconverter()

Nothing fancy and it used to work with FrameRateConverter v1.3.

[manolito]

The correct function name should be "StripeMaskPass"...

[pintcat]

Yeah, that's a typo on my side. I did not copy/paste the error message. Yet, I have no idea what's wrong here. Am I the only one getting this error?

[Floatingshed]

Just downloaded version 1.3 zip, but the avsi file states that it is version 1.21...

[manolito]

This is just a small oversight by MysteryX. The script is really version 1.3.

[Floatingshed]

Great, thanks for letting me know.

[MysteryX]

Originally Posted by Dogway

MysteryX, what's the point of having different mask settings for different clip sizes as shown here? Does it have to do with the MAnalyse vectors?

Not sure I understand your question; but at the link you pointed to, I take blkSize into the equation so that the resulting frame is resolution-independent; meaning a "mask zone" will be about let's say 1/20th of the width on a 480p clip and 1/20th of the width on a 4K clip. Will look similar when looking at that clip full-screen without regards to input resolution.

[MysteryX]

I got tired of Windows and switched to Linux.

For when I get back to this; does RIFE work under Linux? It will be a bit more of an adventure to get all the plugins working in Linux.

[manolito]

Originally Posted by MysteryX

I got tired of Windows and switched to Linux.

Alright, I guess you will continue support for the upcoming Linus version in the Linux section at Doom9. Just one question:

Will you publish a final stable Windows version 2.0, or will you just abandon it and refer Windows users to the old stable version 1.3 ?

Whatever, thank you very much for your work on FrameRateConverter.

Cheers
manolito

[StainlessS]

or will you just abandon it and ...

Of course he would not just abandon it, MX is a very respectable person
with very strong principles and would not ever do that,
a final stable ver$ 2.0 is the least you can expect from the noble gentleman.

[MysteryX]

I also have Windows running within Linux with near-native performance with QEMU+KVM with GPU passthrough; enough to play games with native Windows performance.

Been busy with lots of other stuff. Including porting some of my software to Linux by switching UI from WPF to Avalonia, and porting MvvmDialogs to support Avalonia and other UI platforms. Oh, and converting the Media Player UI to work on Avalonia/Linux was a pain too (and not completed).

There's FrameRateConverter to finish, and xClean to finish.

Not counting my usual work in the astral realms.

[StainlessS]

There's FrameRateConverter to finish, and xClean to finish.

"Complete", better than 'finish".
And Good Luck in the "Astral Realms", [EDIT: whatever the hell they are {I'm guessin' close friend of Mystic Meg}],
also see U at some point in the Linux Realm
(Thank you MX)