FrameRateConverter (Official)

[Maxiuca]

Best motion adaptive engines are in XFile (ex Alchemist) and in Tachyon. Both GPU based. Apparently Nvidia neural based engine is also good.

That really depends on your source material. Tachyon is very fast, the quality is ok, but it does artifacts a lot.

I haven't seen what the software Alchemist can produce but results from the hardware Alchemist are just so-so.

If you have the time and the processing power, FrameRateConverter can give much better results.

BTW. You don't have to buy a license anymore, Tachyon along with other tools made by Cinnafilm are now available online and you just pay per minute of processed material: pixelstrings.com

The commercial tools are also useful when you need to downconvert the frame-rate, which the FrameRateConverter can't do directly. On the other hand, downconversion can be done indirectly with FRC and the results are really good.


I just tuned past a re-run of M*A*S*H on MeTV and they have used optical flow to make it look like it was shot on video rather than film. I assume they had access to whatever "best of breed" is available for professional use. It too doesn't look very good.

Don't assume they have any idea what they are doing or have access to the "best of breed". Most people (technicians) in Hollywood don't even know anymore what interlace or 3:2 pulldown is.
For example, if you look closely at a stock shot at 11:48 mark ("Surigacal Appliances" storefront) in Seinfeld episode 4x22 ("The Handicap Spot"), you'll see interlace, yet it's 23.976p. And it's not the only this one shot (that one I've remembered for some reason), the HD remaster is ridden with such issues and clearly shows that the company that prepared the 2006 HD remaster had no idea what they were doing. Fast-forward 14 years and nowadays most companies and their employees know even less about old formats and video in general.

[hahadoom]

Hi,
How to install FrameRateConverter on Windows with MPC-HC/BE ?

use AviSynth Filter + AviSynth+
https://github.com/CrendKing/avisynth_filter

Uncheck input formats 10bit 16bit for AviSynth Filter.

1080p avs:

#8 core CPU
global Threads=8
AvsFilterSource()
FrameRateConverter(last,BlkSize = 16,Preset ="Slow",Output ="auto",Stp =false,Dct = 0,FrameDouble=true)
AvsFilterDisconnect()
Prefetch(Threads)


amd 1700x smooth，but image error may occur for changing the playback progress.

[Selur]

Seeing that there are a few files over at https://github.com/mysteryx93/FrameRateConverter/tree/master/Src hinting at Vapoursynth I was wondering is there a way to use FrameRateConverter natively in Vapoursynth?

Cu Selur

[binba]

Thank you for developing this script, and for all the optimizations. It's a challenging field, but FRC absolutely seems to be one of the best tools out there, commercial or not.

As Maxiuca mentioned, I ran my same test clips on Tachyon via Cinnafilm Pixelstrings. ~$2/min. is IMO a fair and handy licensing model, and I could definitely afford running some tests. And FrameRateConverter was markedly better.

They cost serious money. Xfile is 10k$. Tachyon similar.
Only $10K for Xfile? My Googling said it was $125K. 🤑

[binba]

Some questions, and my apologies for reading only the Git readme and 40 out of the 300 posts in the thread (including the last of hfrforever’s adventure �� )… in case this had been answered earlier.


1. 10-bit support: No support for bit depths higher than 8bpc? What's missing for it to be possible?


2. Performance: I have a 24-core Threadripper, and use AviSynth+ with all-64bit plugins whenever possible. FRC was barely using 3% of 2 cores. I didn't expect stellar multicore/multithreaded performance, but is that the expected performance, with how optimization is at this point? On average, FRC ran x16 slower than real-time.

I was able to run multiple VirtualDub instances which was nice, I wonder if could process, say, 12 instances in parallel. :devil: But it also makes me wonder, can the .avsi be modified so at first there's a scene-detection-only pass, and then many instances are spun to motion-interpolate scenes in parallel? Then stitch them back into the final output file. This could help get around some of the limitations of MT.


3. 30p to 24p
The commercial tools are also useful when you need to downconvert the frame-rate, which the FrameRateConverter can't do directly. On the other hand, downconversion can be done indirectly with FRC and the results are really good.

Um I just ran a frame rate reduction directly... fed it a 29.97p video (via LSMASHVIdeoSource) and ran FrameRateConverter(Preset="Slow", FrameDouble=false, NewNum=24000, NewDen=1001) and got a 23.976p file. AviSynth/VDub/FRC definitely never complained and I didn't see any obvious artifacts. Was I doing it wrong?... Or skipped every 5th frame without noticing or something of that sort?

[manolito]

3. 30p to 24p

Um I just ran a frame rate reduction directly... fed it a 29.97p video (via LSMASHVIdeoSource) and ran FrameRateConverter(Preset="Slow", FrameDouble=false, NewNum=24000, NewDen=1001) and got a 23.976p file. AviSynth/VDub/FRC definitely never complained and I didn't see any obvious artifacts. Was I doing it wrong?... Or skipped every 5th frame without noticing or something of that sort?

This depends on the fps reduction ratio and on the FRC settings. The underlying fps conversion routine by johnmeyer certainly has no problems with downconversions. It is the mask creation which can cause errors.

I found 2 possible causes. The first one can happen when the blend routine calls ConvertFPSLimit outside of the conversion ratio restrictions, and the other one lies in creating the artifact correction mask. In some cases the blocksize has to be corrected to make this routine work.


Attached is a fixed FrameRateConverter.avsi which took care of downconversion errors for me...


//EDIT//
For better speed you can try the parameter "DCT=0". Your preset "Slow" uses DCT=4 which in my experience does not always improve quality. The fftw3.dll filter is the major speed block for FRC, and if you do not use it by specifying "DCT=0" your conversion speed will improve considerably.

//EDIT2//
Not impressed with the attachment approval speed...
Here is another download link:
https://files.videohelp.com/u/172211/FrameRateConverter_fixed.zip

//EDIT3//
Sorry, I mixed up some calling parameters between different FRC versions. The current version of the fixed AVSI is now tested to work with the latest FRC v. 1.3. Please redownload...

[binba]

Thanks, manolito! I'll see when I find myself back in this research, since the main release happened to work quite well for my fps reduction. (I try to avoid using the term "downconversion" since it's mostly used to mean resolution, and some times bitrate, conversions; but not frame rate.)

I do hope MysteryX takes a look at it and possibly incorporates it into the production release, or else it will get buried in post #306 of thread 174793.. Makes you wonder how much Doom9 wisdom & effort gets lost because it's not always possible to read thousands of posts..

[manolito]

...since the main release happened to work quite well for my fps reduction.

I do hope MysteryX takes a look at it and possibly incorporates it into the production release...

Try to reduce the framerate from 60 fps to 23.976... :devil:

I believe that MysteryX did not really care for fps reduction (at least he does not mention it in the header of the script). Most users were also more interested in doubling the rate or doing slow motion conversions. Anyways, MysteryX has not been active in this forum for more than 6 months, so I do not know if he will take a look anytime soon.

My fixes just use the "try ... catch" construct of the AVS script language. Probably a little clumsy, but it works.

[kolak]

Thank you for developing this script, and for all the optimizations. It's a challenging field, but FRC absolutely seems to be one of the best tools out there, commercial or not.

As Maxiuca mentioned, I ran my same test clips on Tachyon via Cinnafilm Pixelstrings. ~$2/min. is IMO a fair and handy licensing model, and I could definitely afford running some tests. And FrameRateConverter was markedly better.


Only $10K for Xfile? My Googling said it was $125K. ��

125K$ is an old price for hardware box which was about always made to order as stocking them was simply too expensive.
XFile gives better quality and needs just fairly good GPU.

[kolak]

I haven't seen what the software Alchemist can produce but results from the hardware Alchemist are just so-so.

If you have the time and the processing power, FrameRateConverter can give much better results.



Problem with old hardware box was fact that it had to work in real time. It was a compromise as they could not make it faster (to keep it been realtime), so they had to reduce quality.

It's not the case for Xfile anymore, so quality is better. It's similar to Tachyon or open source tools, but also quite fast and can work over many GPUs.

I did not use FrameRateConverter itself, but original InterFrame. I think Xfile was bit better (if we take many different source types). You also don't have to play with it as it's quite consistent and has not many settings.

[MysteryX]

Can someone test: how does RIFE compare to FrameRateConverter?
https://github.com/HomeOfVapourSynthEvolution/VapourSynth-RIFE-ncnn-Vulkan

[poisondeathray]

Can someone test: how does RIFE compare to FrameRateConverter?
https://github.com/HomeOfVapourSynthEvolution/VapourSynth-RIFE-ncnn-Vulkan



Better in some ways , worse in others

In general, RIFE is better with occlusions, object boundaries, y-axis rotational vectors than mvtools2 based tools. I use RIFE to solve problems that FRC or mvtools2 has and composite the results

There are some video comparisions and discussion in the vapoursynth sub forum, with "picket fence" backgrounds . Object boundaries are much cleaner, basically usable with RIFE

RIFE is slower, but ok and usable with a decent GPU. Less tweakable , no settings to adjust (you can use 1 version of a model at a time), and it can fail on some "simple" things. You need to combine /composite results to get the "best" of everything

I tested the non vulkan, non vpy, cuda version of RIFE which is supposedly faster if you have a compatible card. I tried the RIFE vpy version quickly , but I couldn't get the .dll to load, I'll revisit it later when I have time

DAIN is similar to RIFE in terms of results, but 20-30x slower. But there are cases where DAIN produced better results

[kedautinh12]

I think need mix ver of RIFE and FRC or mvtools2 :D :D :D

[MysteryX]

Are you saying that RIFE could replace frame blending for artifact masking?

FRC is currently using 3 clips. One fast to calculate, one much slower -- merging both based on a mask. And then frame blending. RIFE could then replace 1 or 2 of those?

First, would have to get RIFE to work in Avisynth.

[ChaosKing]

First, would have to get RIFE to work in Avisynth.

You have always the http://avisynth.nl/index.php/VapourSource option.

[poisondeathray]

Are you saying that RIFE could replace frame blending for artifact masking?

FRC is currently using 3 clips. One fast to calculate, one much slower -- merging both based on a mask. And then frame blending. RIFE could then replace 1 or 2 of those?

First, would have to get RIFE to work in Avisynth.

I'm saying in some cases it can. Very clean object edges. That's the main strength. Much better than mvtools2 as a starting point in some cases.

But in other cases - not so much, other BG parts of same scene can have problems too where mvtools2 with mrecalculate did not.

You need to mix/match composite versions with mvtools2 / other optical flow to get the best results. I've been using RIFE to fix mvtools2 (and other traditional optical flow) "fails" such as picket fence, or object rotation, where mvtools2 is basically unusable

[MysteryX]

in the case of picket fence -- it's basically RIFE vs Frame Blending. Not a tough competition to win.

On a side note; "the highs don't help as much as the lows hurt". Better quality is great; but it's the artefacts and consistency that matter even more.

[poisondeathray]

in the case of picket fence -- it's basically RIFE vs Frame Blending. Not a tough competition to win.


If you force interpolation, the foreground object boundaries are clean. That's a seriously impressive result. Mvtools2 just can't do it. zorr looked at avs optimizer and running iterations and settings, but it looks like it just can't be done with mvtools2

Rotoscoping is the most time consuming and tedious post production activity. RIFE cuts hours/days/weeks of work off



On a side note; "the highs don't help as much as the lows hurt". Better quality is great; but it's the artefacts and consistency that matter even more.

And that's why you need to combine/composite them to get ideal results

Different people have different usage cases. eg. For playback, svpflow scenarios, artifacts might be acceptable.

I'm looking for clean interpolation. Not blending. Post work if necessary

[Milardo]

I tried to use the RIFE vapoursynth filter for video playback, but it doesn't work.

[Selur]

I tried to use the RIFE vapoursynth filter for video playback, but it doesn't work.
I would be surprised if any ML based method was usable for real time playback,... (at least on any hardware I know)

[zorr]

If you force interpolation, the foreground object boundaries are clean. That's a seriously impressive result. Mvtools2 just can't do it. zorr looked at avs optimizer and running iterations and settings, but it looks like it just can't be done with mvtools2

TBD. I'm still running tests and I have only reported the first batch which didn't even use all the available options of MVTools2 (starting from this post (https://forum.doom9.org/showthread.php?p=1942410#post1942410) for those who are interested). No holy grail findings yet but the results are improving. Now testing MRecalculate. There are a couple of tricks that can be used to improve the results even further (and I have like 10 more ideas I haven't tested).

That being said, my bet is that MVTools will not beat RIFE when it comes to object boundaries.

[poisondeathray]

TBD. I'm still running tests and I have only reported the first batch which didn't even use all the available options of MVTools2 (starting from this post (https://forum.doom9.org/showthread.php?p=1942410#post1942410) for those who are interested). No holy grail findings yet but the results are improving. Now testing MRecalculate. There are a couple of tricks that can be used to improve the results even further (and I have like 10 more ideas I haven't tested).

That being said, my bet is that MVTools will not beat RIFE when it comes to object boundaries.



Thanks, looking forward to the additional testing



If you have time to conduct other testing - some other situations where DAIN/RIFE tend to do better/cleaner (I mean, besides "picket fence") - are general FG/BG/FG object boundary delineation such as objects crossing over. Even something simple such as walking. Often a person's arms/hands/legs will look like 3 arms instead of 2 (3 legs instead of 2) using traditional optical flow methods. Or dancing, rotation - as person "spins" their arms/leg look blended or become artifacts. Any one that uses mvtools2 for motion interpolation or other optical methods in the past should be familiar with this category of artifacts. Maybe zorr can find some mvtools2 settings which "solve" this scene or at least improve on the results

This one is from John Meyer. Sample link down in original thread
https://forum.doom9.org/showthread.php?t=167914

src mirror (with frc and rife @ 60000/1001 libx264 crf 16 "normal speed") in zip
https://www.mediafire.com/file/8ty526fot6jixhr/fashionshow_src,frc,rife.zip/file

YT comparison, slow down to 6fps
https://www.youtube.com/watch?v=N8LpwRiix8M

Object (person) boundaries are cleaner with DAIN and RIFE. There are negligble artifacts as the hands/arms cross over the body (FG/FG layers), and also the background vertical lines on the wall (FG/BG). No need to resort to blending coverups or other fixes




Sample walk, 23.976p with motion blur .

src, (with frc and rife @ 48000/1001 libx264 crf 16 "normal speed", and "moving window" crop comparison) in zip
https://www.mediafire.com/file/cnt8g2laplu3sae/high_heel_walk_src,frc,rife+windowcomparison.zip/file

YT comparison, slowed down to 6fps, moving crop window (HD version might take a while to show up on YT, but higher quality file in the zip anyways)
https://www.youtube.com/watch?v=7GI-Xc7cSsQ

There are typical mvtools2 artifacts when using default settings (maybe zorr can find some magical settings). Arms, legs are doubled up and BG objects like wall lines, electrical outlet move around and are not stationary. FRC with default settings does a decent job of making FG artifacts more palatable with blending instead of jarring artifacts .

RIFE is not perfect on this sample, but it produces cleaner in terms of edges, objects, BG. Note 1 frame near the end is bad because it's almost "reverse" motion





DAIN/RIFE are not the "holy grail" either. They can make mistakes on some parts of frames that mvtools2 does not. Some cue just messes up the neural net and it makes a big mistake, whereas mvtools2 breezes through some scenarios with flying colors. YMMV. Mix/match for better results

I mentioned these "cons" in another thread - but other ones - DAIN/RIFE are less flexible, fewer settings, currently only 2x multiples, 8bit RGB for official internal version only (not sure if VPY version has other conversions in the background). Scene change detection also not very good (but it looks like VPY version has sc and misc.SCDetect to repeat last frame)



Something like RIFE with secondary mvtools2 fallback (or vice-versa), then tertiary artifact blend fallback would be cool

[zorr]

Often a person's arms/hands/legs will look like 3 arms instead of 2 (3 legs instead of 2) using traditional optical flow methods. Or dancing, rotation - as person "spins" their arms/leg look blended or become artifacts. Any one that uses mvtools2 for motion interpolation or other optical methods in the past should be familiar with this category of artifacts. Maybe zorr can find some mvtools2 settings which "solve" this scene or at least improve on the results

That artifact is familiar - I did one test with a similar case (it's actually in the Zopti introduction). Perhaps not completely "solved" but much better. This was with a basic MAnalyse + MFlowFPS script so it can be improved.

https://i.postimg.cc/T2Zg6s1y/ezgif-2-85352ef164.gif

DAIN/RIFE are less flexible, fewer settings, currently only 2x multiples, 8bit RGB for official internal version only (not sure if VPY version has other conversions in the background).

That 8bit limitation could be circumvented by using MCompensate - let DAIN/RIFE create a good target for MCompensate, calculate vectors in 8bit and apply them in HBD clip.

Something like RIFE with secondary mvtools2 fallback (or vice-versa), then tertiary artifact blend fallback would be cool

Yeah I have already thought about combining them. Nothing concrete yet - still trying to comprehend MVTools. It's a monster and it takes time to tame it.

Those example clips look good test cases and I'm sure I will try them. They also don't look unreasonably hard - MVTools should be able to handle them quite well. The high heel walk clip is also an interesting special case, it has a (mostly) stationary background which can be extracted with temporal median. Once we have that we can build masks of moving objects. By making the background completely black it should be much easier for MVTools to track objects.

[poisondeathray]

That artifact is familiar - I did one test with a similar case (it's actually in the Zopti introduction). Perhaps not completely "solved" but much better. This was with a basic MAnalyse + MFlowFPS script so it can be improved.

Yes, I remember, good improvement.

Here is FRC vs. RIFE to compare, basically an even bigger improvement
https://i.postimg.cc/zBBm9pbB/handwave-frc-rife.gif



That 8bit limitation could be circumvented by using MCompensate - let DAIN/RIFE create a good target for MCompensate, calculate vectors in 8bit and apply them in HBD clip.


Interesting approach, not sure how to go about it yet.

But really 8bit is a minor issue , I'd take clean edges over 8bit RGB as a tradeoff any day of the week.

They VPY version only supports RGB float, so I'm not sure how that is navigated

I've been using the CUDA/Pytorch implementation, not Vulkan (which the VPY version is based on). CUDA version is supposed to be ~3x faster, not sure if there are quality differences. I can't get the VPY plugin to load... trying to figure out the VPY version

[MysteryX]

RIFE does look impressive on the hand! Where FRC is really good at is building artefact masks. The problem is that there wasn't a good back-up to replace them, other than Frame Blending.

The image also looks better defined with MVTools2 in the non-artefact areas.

btw I'm currently porting FRC plugins DLL to VapourSynth. It's almost done. Remains to rewrite the AVSI file...

Then can try swapping out the Frame Blending clip with RIFE.

Looking at RIFE clips, it looks like for easy linear surfaces (panning), MVTools2 is just moving the texture linearly without distortion, whereas RIFE is trying to move it in all kinds of subtle ways that blur some of the details.

[kedautinh12]

Thanks

[Selur]

btw I'm currently porting FRC plugins DLL to VapourSynth. It's almost done. Remains to rewrite the AVSI file...:goodpost:

[kedautinh12]

New mod FrameRateConverter.avsi from Dogway for spped and HBD
https://github.com/Dogway/Avisynth-Scripts/blob/master/MIX%20mods/FrameRateConverter.avsi
It's request extools to work
https://github.com/Dogway/Avisynth-Scripts/blob/master/ExTools.avsi

[real.finder]

btw, https://github.com/mysteryx93/FrameRateConverter#conditionalfiltermt for last avs+ conditionalfiltermt is not needed since mt problem fixed with AvisynthNeo changes

[MysteryX]

btw how do you convert this into Expr (for VapourSynth)?
ColorYUV(gamma_y = ((1.0 / 2.2) - 1.0) * 256.0)

[MysteryX]

OK guys, here's a beta DLL working for both Avisynth and VapourSynth. The same DLL works in both. Requires FMTC (https://forum.doom9.org/showthread.php?t=166504).

>> Download here (https://mega.nz/file/iFoUmZgT#8OluWsf0hY2A2Rq43RE_ce4-0iBK14WKpLZbJRFNnVU)

StripeMask isn't currently converting the mask back to HBD when input is HBD, and more work is needed to handle errors properly, but otherwise it's usable.

As for converting the AVSI file, could someone work on converting it? I do not know Python syntax and it would take me a while to get it done. The DLL is the hard part; many people can do the scripting part.

One issue came to my attention with StripeMask: level range PC vs TV. Take the same script, and the strength of the mask applied will be very different depending on whether the input is PC or TV. Is this negatively affecting other parts of the script?

The Avisynth gamma-to-linear solution of "ColorYUV(gamma_y = ((1.0 / 2.2) - 1.0) * 256.0)" is completing ignoring the level range. For VapourSynth, I'm using FMTConv instead. It produces a different output that serves as source for mask processing. It's more accurate but considerably brighter if converting to RGB before converting to Linear. It's brighter but less if converting to Grey16 and converting that to Linear. Might have to see whether it's worth doing Linear conversion in RGB or Grey16 is fine. More importantly, PC vs TV level needs to be taken into account.

And can the same solution be done in Avisynth to have consistent output? FMTConv is only for VapourSynth I think.

If someone can work on converting the AVSI file, that would be great! You can then swap out the Frame Blending clip with RIFE and dance.

[Dogway]

This is a simple gamma expression in RPN. You need to use scale_inputs="allf" in order to work. You can also take out "1 {gamma} /" from the expression to speed it up slightly.

rangePC = tv_in ? "x ymin - ymax ymin - /" : "x range_max /"
rangeTV = tv_out ? "ymax ymin - * ymin +" : " range_max *"

Format(""+rangePC+" 1 {gamma} / ^ "+rangeTV+"")

[Selur]

New mod FrameRateConverter.avsi from Dogway for spped and HBD
https://github.com/Dogway/Avisynth-Scripts/blob/master/MIX%20mods/FrameRateConverter.avsi
It's request extools to work
https://github.com/Dogway/Avisynth-Scripts/blob/master/ExTools.avsi
there are more dependencies,...
you also need Utils-r41 (http://avisynth.nl/images/Utils-r41.avsi)

[kedautinh12]

Or link github: https://github.com/raffriff42/AvisynthPlusUtilities/blob/master/Utils-r41.avsi

[MysteryX]

Dogway, do your have VapourSynth versions of your scripts?

[Dogway]

No, unfortunately I'm on Win7 but VS already has ported masktools2 and also has fmtconv. I think VS has AVX2 accelerated Convolution() function so it's already very fast.

[MysteryX]

This is a simple gamma expression in RPN. You need to use scale_inputs="allf" in order to work. You can also take out "1 {gamma} /" from the expression to speed it up slightly.

rangePC = tv_in ? "x ymin - ymax ymin - /" : "x range_max /"
rangeTV = tv_out ? "ymax ymin - * ymin +" : " range_max *"

Format(""+rangePC+" 1 {gamma} / ^ "+rangeTV+"")

I'm trying to use this, but it says "failed to convert ymin to float". How do you use this?

rangePC = "x ymin - ymax ymin - /"
rangeTV = " range_max *"
query = ""+rangePC+" 1 {gamma} / ^ "+rangeTV+""
video = core.std.Expr(clips=[video], expr=[query, ""])

[Dogway]

I don't know how vapoursynth deals with constants, you can replace them with this table (https://forum.doom9.org/showthread.php?p=1945324#post1945324)based on bitdepth.

I think you need (http://www.vapoursynth.com/doc/functions/expr.html)to replace with 8-bit values and set output format.

[real.finder]

vapoursynth depends on python for this, those keywords are avs exclusive

[MysteryX]

I'm trying to get consistent linear conversion output between Avisynth and VapourSynth.

Best way is to first convert to Y8 and then apply gamma correction, to give an Y8 output in full range.


ConvertToY()
ColorYuv(levels="TV->PC")
Levels(0, 1/2.2, 255, 0, 255)



video = core.resize.Point(video, format=vs.GRAY16)
video = core.fmtc.transfer(video, transs="709", transd="linear", fulls=0, fulld=1)
video = core.resize.Point(video, format=vs.GRAY8)


There's just a very slight contrast difference between the 2 methods. Shouldn't be an issue.

Now, if I want slightly better conversion, Levels doesn't work in 16-bit, and using ColorYUV instead of Levels gives a much darker output for some reason


ColorYUV(gamma_y=((1.0 / 2.2) - 1.0) * 256.0)


Other option is to use Expr for both and have perfectly consistent output without needing FMTC dependency.

This is a simple gamma expression in RPN. You need to use scale_inputs="allf" in order to work. You can also take out "1 {gamma} /" from the expression to speed it up slightly.

rangePC = tv_in ? "x ymin - ymax ymin - /" : "x range_max /"
rangeTV = tv_out ? "ymax ymin - * ymin +" : " range_max *"

Format(""+rangePC+" 1 {gamma} / ^ "+rangeTV+"")

Format isn't an Avisynth function, and I can't get this to work. Can you write the exact syntax that I can put into the Avisynth script?

[Dogway]

Format() (http://avisynth.nl/index.php/Internal_functions#Format) is AVS+ only I think, don't know from what version.

This is an HBD aware TV<->PC levels conversion function. link (https://github.com/Dogway/Avisynth-Scripts/blob/6963044760236bc7226a6151935b891fce060e86/TransformsPack.v1.0.RC17.avsi#L1116)

And here is an HBD aware Levels function. link (https://github.com/Dogway/Avisynth-Scripts/blob/6963044760236bc7226a6151935b891fce060e86/GradePack.v1.9.avsi#L189)

They both require ExTools found in the repo.
I'm in the middle of a rebase so I'm taking my time and preparing an elaborated post for possible solutions, so if something triggers an error let me know, or use an earlier version of ExTools (v1.6 or v1.7).

EDIT: Oh by the way, this all to linearize an image/source right? I'm also in the middle of a refactor for Transforms Pack but the gamma function (https://github.com/Dogway/Avisynth-Scripts/blob/6963044760236bc7226a6151935b891fce060e86/TransformsPack.v1.0.RC17.avsi#L580) is very functional at this state. Pick the alpha and gamma value from this list (https://github.com/Dogway/Avisynth-Scripts/blob/6963044760236bc7226a6151935b891fce060e86/TransformsPack.v1.0.RC17.avsi#L949).

[MysteryX]

I got gamma correction working with Levels. That's probably the best option.

[Dogway]

Good luck!

[MysteryX]

Releasing FrameRateConvert v2.0-Beta (https://github.com/mysteryx93/FrameRateConverter/releases/tag/v2.0-beta), DLL only. Works in both VapourSynth and Avisynth.

- Ported to VapourSynth
- Fixed a bug in StripeMask
- StripeMask linear gamma correction is now more accurate
- StripeMask now accounts for PC vs TV range
- StripeMask: added fullRange parameter, set to True if input is in full range

For VapourSynth, FMTC dll is required. For Avisynth, you can use the previous AVSI file and the StripeMask will have a few corrections. Note that StripeMask thr parameter default is now 28 instead of 26, and possibly could use further adjustment.

[kedautinh12]

Thanks

[ChaosKing]

Thx for the port.
I see some warnings / problems in vsedit :D

clip = core.frc.StripeMask(clip)
Core freed but 6 filter instance(s) still exist
Core freed but 1075200 bytes still allocated in framebuffers
Plugin C:/Users/anato/AppData/Roaming/VapourSynth/plugins64/FrameRateConverter-x64.dll tried to register 'ConvertFpsLimit' more than once. Second registration ignored.
Plugin C:/Users/anato/AppData/Roaming/VapourSynth/plugins64/FrameRateConverter-x64.dll tried to register 'ConvertFpsLimit' more than once. Second registration ignored.
Plugin C:/Users/anato/AppData/Roaming/VapourSynth/plugins64/FrameRateConverter-x64.dll tried to register 'ConvertFpsLimit' more than once. Second registration ignored.

and if I want to preview the mask I get
Error on frame 0 request:
Resize error -1: invalid graph state L910: !m_state.has_chroma() || m_state.plan


core.frc.ContinuousMask(clip, 24000, 1000) #crashes the editor
Log shows this msg
setVideoInfo: The frame rate specified by ContinuousMask must be a reduced fraction. (Instead, it is 24000/1000.)

[MysteryX]

Fixed most of those bugs.

Error on frame 0 request:
Resize error -1: invalid graph state L910: !m_state.has_chroma() || m_state.plan

This error is in FMTC.transfer; but it works when run in VirtualDub.


video = core.resize.Point(video, format=vs.GRAY16)
video = core.fmtc.transfer(video, transs="709", transd="linear")
video = core.resize.Point(video, format=vs.GRAY8)


There's the option of converting to RGBS but it would be slower and would produce a slightly brighter output than in Avisynth.

I released a new beta at the same link. (https://github.com/mysteryx93/FrameRateConverter/releases/tag/v2.0-beta)

[ChaosKing]

Is 16bit int or 32bit float input supported? Output of ContinuousMask() looks strange with non 8bit input.


The parameter seems to be ConvertFpsLimit(clip, num, den, ratio) but I get this error msg when calling ConvertFpsLimit(clip, 24000, 1000, 1)
vapoursynth.Error: ConvertFpsLimit: Can only set one of the following parameters: num/den (fraction), fps (float), preset (string) or match (clip).

+ it crashes with just ConvertFpsLimit(clip)

[MysteryX]

ContinuousMask gives strange output on regular clips. It's meant to process masks. I didn't document it either -- don't remember what it did exactly :P Works in the context it's used for though. Gives same output as it did before in Avisynth.

Since I can't register ConvertFpsLimit several times like in Avisynth, the syntax is now


"clip:clip;"
"num:int:opt;"
"den:int:opt;"
"fps:float:opt;"
"preset:data:opt;"
"match:clip:opt;"
"ratio:int:opt;"

Forgot to validate if none is set; fixed it.

[ChaosKing]

ContinuousMask gives strange output on regular clips. It's meant to process masks.
I'm pretty sure this output is stranger then it should be :p
https://i.imgur.com/BzCFDvk.png