FrameRateConverter (Official)

[hello_hello]

I was actually downscaling ie 720x576 to 704x396. Chances are it's not enough to matter but I thought I'd ask.
I still haven't had a chance to do more testing but I'll report back when I do.

Thanks.

[MysteryX]

Normally, interpolate at the end.

If the details are too low and interpolation is causing artifacts, then you can also try interpolating first. Let me know which works best.

You may want to use AvisynthShader's SSIM downscaler. I haven't tested it much myself but it's giving great results. (I'll use it to downscale 4K YouTube content to 1080p)

[SpoCk0nd0pe]

I tried your new script version and got a divide by 0 error in line 132 :/

1080p content at slower, stock settings

[MysteryX]

Originally Posted by SpoCk0nd0pe

I tried your new script version and got a divide by 0 error in line 132 :/

1080p content at slower, stock settings

Line 132 is

B = C.ConvertFps(NewNum, NewDen)

Did you specify valid NewNum and NewDen? What's your script?

[MysteryX]

I saw a movie clip with a calm background and high-artifact motions in the middle. The frame should get blended but because the background is calm the SkipOver value is too low.

The only way I can think to fix that would be to analyze the vectors data to determine what percentage of vectors are below a certain movement threshold. If it's a low-movement background, blending the whole frame doesn't degrade quality much. I could say if the amount of slow-moving blocks is above a certain percentage of the frame, reduce BlendOver by half. This should help in those scenes.

I have no idea what vectors data looks like though! Anyone knows how this works?

According to doc

outfile: name of file to write motion vectors data. This data may be used by some external program or may be by next MVTools versions for second pass coding, etc. Produced binary file has a header (MVAnalysisData structure, see MVInterface.h source code), and the data sequence:
frame number, vector data (Vx, Vy, SAD) of every block, next valid frame number, this frame vector data, and so on.

I was thinking to simply use YDifferenceFromPrevious to detect how much movement is in the frame but that would cause low-contrast action scenes to be blended.

As for Anime preset, perhaps we could simply double default BlkSize; this would have to be tested.

[hello_hello]

Originally Posted by manolito

The only difference with your command line between FRC 1.0 and my simplified script is the block size. FRC defaults to 12 for this frame size while my script uses 16 (a block size of 12 is not supported by older versions of MVTools2).

I may have done your version of the script a disservice. I didn't realise you'd updated it since I saved it. The version I was using is dated 18-May-2017. Is this the latest version of your version? https://forum.doom9.org/showthread.p...50#post1805050
I'll try again fairly soon with the newer version while I'm testing the newer FrameRateConverter and the settings suggested by MysteryX, but if that's the latest, you might want to go through it and replace all instances of trh with thr. I recall MysteryX doing the same thing. I think there's only one line where trh is used as an argument and causes an error, but it'd make sense to change MaskTrh to MaskThr and SkipTrh to SkipThr anyway.

Edit The 22-June-17 version of your version of the script is better in respect to the fade-out issue than the 18-May-2017 version I tried originally, so it's probably no worse than the official FrameRateConverter script in that respect.

Cheers.

[hello_hello]

MysteryX,
The help file seems to imply BlkSize=6 is supported, but FrameRateConverter(FrameDouble=true, BlkSize=6) results in this (version 1.2):

MVTools: no BLITCHROMA function for block size 1x1
(FrameRateConverter.avsi, line 153)

[hello_hello]

Originally Posted by MysteryX

As for Anime preset, perhaps we could simply double default BlkSize; this would have to be tested.

I tried it but I prefer the default block size (I think I even preferred the default to reducing it to 8 (I assume at 704x396 the default BlkSize is 12?).

BlkSize=24 seems to fix the fade-out issue, or at least improve it greatly, but it increases distortion in areas where one object is moving across another stationary object. I think I'd prefer some minor wobble during fade-outs.

Originally Posted by MysteryX

You may want to use AvisynthShader's SSIM downscaler. I haven't tested it much myself but it's giving great results. (I'll use it to downscale 4K YouTube content to 1080p)

I gave it a try but kept getting an error relating to a missing function. It was yesterday and I didn't make a note of it because I thought I'd work on one problem at a time, but I think it was "no function get_bitdepth" or something similar.

I tried switching MeGUI to using it's portable version of AvIsynth+ (I have the standard AVIsynth installed) but that didn't help. Apparently MeGUI is using r2508. Or maybe it's an XP thing?

Anyway, that'll be a problem for another day. I'll keep playing around with FrameRateConverter settings for the moment.

Thanks.

[MysteryX]

hello_hello, when testing settings, set debug=true to see what it's doing

"no function get_bitdepth" that means you didn't load AvisynthShader.dll

[hello_hello]

There's shader.dll in the zip file but no AvisynthShader.dll, is that something different again? I definitely had shader.dll in the Avisynth plugins folder. Maybe it's a dependency problem. My video card is pretty ancient so I'm not to optimistic as to how well it'd work anyway.

I tried version 1.50 just to see what'd happen and it resulted in "no function named ConvertToShader" and when I went back to 1.6.2 it was "no function named shader_GetBitdepth".

Best as a can tell, and keeping in mind I have no idea what I'm talking about, the Dependency Walker clues seem to indicate it's an XP issue.
https://msdn.microsoft.com/en-us/lib...=vs.85%29.aspx

Not to worry, I'm not fussed about that for the moment. I'm still playing around with FrameRateConverter.

PS This: FrameRateConverter(FrameDouble=true, BlkSize=6, debug=true)
still results in this error:
MVTools: no BLITCHROMA function for block size 1x1
(FrameRateConverter.avsi, line 153)

(mvtools2 2.7.22)

[hello_hello]

This doesn't relate to my animation problem as such, but while playing around with various settings I had a couple of thoughts....

MaskThr=0 disables artefact masking according to the help file, but the script is very insistent on SkipThr being lower than MaskThr, yet the range for each is stated as being 0-255. It turns out setting SkipThr to -1 bypasses the error (hopefully that's all it does), but I wondered if it might be an idea to limit settings when it's required? For example if you set MaskThr=100, the script would ensure SkipThr doesn't exceed 99, even if you specify something larger.

IMHO it would be awesomely awesome if the debug info included the current frame number, for those times when you have two instances of a script open with slightly different settings (I do that quite a bit using multiple instances of MPC-HC). And also because the debug info and Info() both want to display in the upper left hand corner....

Cheers.

[hello_hello]

MysteryX,
I've played around some more, but so far I don't think I've come up with anything that does a better job than your new animation tuning, so I think I'll just go with that for the moment.

Thanks.

PS. You've probably had a good look at the inner workings of Interframe. If so, do you know what the difference between the default tuning and the animation tuning might be? I ask, because the default tuning does a reasonable job on my animation sample (not as good as FrameRateConverter though, aside from the fade-out problem), whereas the animation tuning is just horrible. Stuff wobbles around all over the place near any object that's moving. I can't imagine when it'd be an improvement over the default tuning, or when you'd want to use it.

Thanks again.

[MysteryX]

Yes, it's shader.dll. Somehow it's not loading. Are you using Windows XP? AvisynthShader requires Windows Vista or above.

BlkSize=6 is valid; but MRecalculate with BlkSize=3 isn't. That's the problem. You can only use BlkSize with Preset="faster" where MRecalculate is disabled.

Why would you set SkipTrh to 0? If you want to disable scene change detection, set SkipOver=0

To get or set current frame number, in MPC-HC or VirtualDub, press CTRL+G. I often find it easier to compare in VirtualDub.

From my test the new animation settings work pretty well, only exception being the woman "warping out" after the planet moves to the right. If I end up implementing a "dynamic blending threshold", it might help with cases like that with still backgrounds and high-artifacts motions.

As for Interframe's Anime tuning, AFAIK, it mostly tunes the settings way down. I don't know the details.

[hello_hello]

Yes, I'm using XP.

I wasn't wanting to set SkpThr to zero as such, but I wanted to try disabling MaskThr by setting it to zero and if you do that, this line kicks in, effectively preventing you from setting MaskThr=0.

Assert(SkipThr < MaskThr, "FrameRateConverter: SkipThr must be lower (stronger) than MaskThr")

Plus it seemed to me it might be better for the script to automatically reduce SkpThr if required according to the MaskThr value, but either way, if you set MaskThr=0, the specified SkipThr range of 0 to 255 will always result in an error.

There's a similar relationship between SkipOver & BlendOver (from memory) I thought could maybe be handled in a similar manner rather than result in an error. Plus the error states SkipOver must be greater than BlendOver, but it doesn't tell you what BlendOver is.

Ctrl+G isn't quite the same thing as having the frame number constantly displayed. The latter just makes it a little easier to compare two videos when stepping through frames. I created a little function called FrameNum() a long time ago and it's easy enough to stick it at the end of the script, but I thought adding the frame number to debug mode might be a nice touch.

The main reason I prefer to use MPC-HC for previewing/comparing scripts is it has a fullscreen mode, and from memory there's no way to prevent VirtualDub from locking scripts when it opens them. If you disable MPC-HC's internal AVS source filter it doesn't lock them. I'm quite used to a script displaying in MPC-HC while I edited it with Notepad and save the edited version, then use CTRL+E to re-load it.
There's probably advantages to VirtualDub I'm unaware of as I've not used it much.

I think I know what you mean about the woman "warping out", or something similar. For frame 241 the slowest preset doesn't distort the planet at all, but the guy "warbles in", whereas the slow preset seems to blend the planet movement, but the guy "appears" nice and cleanly. Some sort of dynamic handling might be nice for that sort of thing, but I don't know how hard it'd be to implement. Mind you it's only a single frame so it passes quite quickly and isn't the end of the world.

I guess this frame interpolation stuff isn't easy.

Preset="slow", BlendOver=40, SkipOver=140


Preset="slowest", BlendOver=40, SkipOver=140

[MysteryX]

For "anime", use preset=slow (DCT=4) because DCT=0 generally gives crap. Slowest only inserts some of that crap back in. If you want to see the output without artifact masking, use Output="flow"

[hello_hello]

Originally Posted by MysteryX

If you want to see the output without artifact masking, use Output="flow"

No problem.

Although I still think it'd be an idea to change this in the script, given it's impossible to set MaskThr to 0 without it resulting in an error (or unless you also set SkipThr to -1)

@ MaskThr - The threshold where a block is considered bad, between 0 and 255. Smaller = stronger. 0 to disable artifact masking. (Default = 120)

Thanks.

[pinterf]

Originally Posted by MysteryX

BlkSize=6 is valid; but MRecalculate with BlkSize=3 isn't. That's the problem.

It can be valid if the source is 4:4:4 (YV24). BlkSize=3 for YV12 format means that chroma block size is 1 (3/2) which is not supported.

[urukazuto]

Hello I'm trying to encode 720p anime by using megui with this setting:
x264 = CRF 23, Very Slow Preset at 8 bit.
Avisyth :

SetMemoryMax(512)
SetMTMode(3,4)
PluginPath = "D:\Program Files (x86)\MeGUI_2715\tools\avisynth_plugin\"
LoadPlugin(PluginPath+"FrameRateConverter.dll")
LoadPlugin(PluginPath+"mvtools2.dll")
LoadPlugin(PluginPath+"masktools2.dll")
LoadPlugin(PluginPath+"GRunT.dll")
Import(PluginPath+"FrameRateConverter.avsi")
<input>
SetMTMode(2)
<deinterlace>
<crop>
<denoise>
<resize>
FrameRateConverter(NewNum=60, NewDen=1, Preset="Anime")

And When I trying to encode, the speed encode is only 1 fps... is this normal?

is there a way to increase speed without changing the preset / setting on framerateconverter?

Edit:
I'm kind of new to this things, i will try to tweak setting a bit.

My Specs:
Intel Core i5-4690 3.5Ghz
MSI Geforce GTX 960 2048MB DDR5 - Gaming 100ME - Limited Edition
8GB DDR3 RAM
Windows 10 Pro 64 Bit (Build 14393)

and yes the Avisynth i'm using is x86 one... version 2.6.0 from Official Builds : https://sourceforge.net/projects/avisynth2/
and after that using the MT one from here : https://forum.doom9.org/showthread.php?t=148782

For filters i dunno which version I'm using....

[burfadel]

Whether it is 'normal' depends on the other filters used that you haven't listed, in addition to the versions of the filters and Avisynth, and in particular, your system specs. I see you are using x86 Avisynth, that isn't 'ideal' for performance. Also is there any reason specifying SetMemoryMax? Is your system short on memory?

[MysteryX]

I also use x86, AFAIK it doesn't make much of a difference.

However, for Anime you're using DCT=4, which isn't working well with MT. Not only are you getting slow performance, but it will crash as well at some point. Currently all presets from Normal to Slowest use some DCT=4 or DCT=1 (it remains to be tested whether MRecalculate DCT=4 has the same issues as MAnalyze... probably)

So you're limited to single-threaded mode. You can however run several instances at once. On a 8-CPU system, I get best performance by running 4 instances in parallel. However, cutting the video in segments and running these segments in parallel isn't something MeGUI supports