Update QTGMC(2) to latest

[DonCanjas]

Latest commits for realfinder's QTGMC to set frame property _FieldBased to 0 and add OpenCL versions of NNEDI3 and EEDI3

realfinder/AVS-Stuff@113f964
realfinder/AVS-Stuff@72822a3

[DTL2020]

Added in https://github.com/DTL2020/QTGMC/releases/tag/m_0.2

[Pernicio]

Hi,

I was wondering would this speed up the M_QTGMC at all, if you used the QTGMC+ from Dogway as it's base? It seems to have been cleaned up and optimized to work specifically with the AVS+ architecture.

There is also new EdiModes available, for example BWDIF+BOB+NNEDI3, that I haven't tried yet, but must, for curiosity's sake. Could be a good upgrade path to make this M_QTGMC achieve even slightly better quality, at faster rates.

https://github.com/Dogway/Avisynth-Scripts/blob/master/MIX%20mods/QTGMC%2B.avsi

[DTL2020]

Because M_QTGMC is only a wrapper over some QTGMC calls with different params sets it can use any underlying QTGMC engine. But because I was too lazy to pass all about 100 params the QTGMC typically uses - it required some more text typing (and testing after). Also some params of QTGMC are internally used by M_QTGMC and can not be exposed to users at the level of M_QTGMC() params.

If someone has time - the redesign is only required (non-used explicitly inside M_QTGMC) params passing from QTGMC calls to M_QTGMC() params list. And pull requests are welcome.

Also you can try to use any QTGMC version as imported script in simplified version (for mvtools pinterf and old branches) and see if it already working - https://github.com/DTL2020/QTGMC/blob/main/M_QTGMC_old_mvt.avsi .

It imports QTGMC.avsi -

QTGMC/M_QTGMC_old_mvt.avsi

Line 10 in 228578d

Import("QTGMC.avsi")

from current (working ?) folder so you can put any version for import. Though if the function name is not QTGMC() it will not load and script edition for the new name is required.

The only current limitation is no easy way for any custom params passed from M_QTGMC() call to configure underlying QTGMC calls if some non-default params are required (like non-default EDI modes and others).

In July 2025 if/when I will have time I will try to make a version somehow working with QTGMC+ from Dogway but do not know when.

[DTL2020]

Second idea - you can also ask Dogway to add M_QTGMC() function (or several functions-presets line M_QTGMC_low() and others) in the QTGMC+ script. It is possible and even better to be in single maintainable .avsi file instead of several scripts by different authors. I will try to open an issue with feature request.

[Pernicio]

Thank you, hopefully he can make it happen. At first, I thought I'd do it by my self, but this would take too long with practicing totally new things, especially now that I'm in the middle of upscaling quest with a 200+ videos and that requires a lot of practice and experimentation by it self. But yeah, it is much more streamlined if the main responsibility is with someone who knows what they do.

By the way, did you make the modded (I assume) MVtools2 that's in the M_QTGMC package? I was wondering if there is a more recent version anywhere, that supports the features which are missing from the pinterf -version?

I'm not entirely sure how many, but it seems that this version of MVtools2.dll has some advanced functionality that the Pinterf's doesn't. Also, if that is true, then I'm hoping that the development of this version of MVtools doesn't get stuck or at least somehow ends up bringing new functionality to Pinterf's Mvtools2 at some point. I could swear that I see a tiny bit of difference in the end result when I add some basic settings that are as non-destructive as I have currently found out. Running it in the basic or plus version of QTGMC does improve the video, but your M_QTGMC wrapper/method seems to have a slight edge on sharpness with no downsides, that I have yet discovered anyway.

I just wish the plugins that are required for it would be more multicore friendly some day, even though you do have a point (If I understood one of your posts on Doom9 forums) in that this M_QTGMC method isn't so slow if you have many cores and you have many videos that each use 1 core per video, then it evens out the speed penalty of a single video.

Do you know if these wrappers can "fake" the non-multicore or poorly multithreaded plugins to do parallel processing somehow with the plugins, if the wrappers are cleverly set up? Or are they going to be the bottleneck as long as the multithreading functionality is hardcoded in them?

[DTL2020]

did you make the modded (I assume) MVtools2 that's in the M_QTGMC package? I was wondering if there is a more recent version anywhere, that supports the features which are missing from the pinterf -version?

Yes. List of new features are really long enough (some planned - some implemented) - https://github.com/DTL2020/mvtools/blob/mvtools-pfmod/new_features_list.ods

I'm hoping that the development of this version of MVtools doesn't get stuck or at least somehow ends up bringing new functionality to Pinterf's Mvtools2 at some point.

I also hope. But open source development resources of former great white civilization looks like going to the end and no programmers left to continue development. Pinterf currently busy with AVS+ core (when he have time to do anything at all). As I see the last programmers of the civilization may exist in Asian region - you may try to ask there. But they mostly play with AI/NN tools/software and not with strict logic old 'linear' software.

M_QTGMC wrapper/method seems to have a slight edge on sharpness

Its most benefit in details saving is on complex moving areas where single run of MAnalyse with single set of params typically fail a lot and provide many bad MVs to motion compensation engine and this cause details blurring and losses.

About better multithreading - I do not have any good ideas how to make it better. It both depends on the multithreading design of mvtools and AVS+ core and as we have not any good required programmers resources to make it better it is mostly likely will continue as today. The only possible speedup is using hardware MAnalyse acceleration using DX12 ME API and compatible GPU. But its quality may be more or less lower in comparison with onCPU MAnalyse and because M_QTGMC was designed to get better quality it may be not good to use lower quality ME engine. Though ME quality of GPU depends on the chip design (and may be better in new generations of chips) and finally you may get both better performance and quality running M_QTGMC with hardware accelerated ME. It is all subject of testing but we looks like not have testers resources too (as we had in 200x and 201x when home video production by consumers was active).