QTGMC Deinterlacing Script (v3.384)

[wonkey_monkey]

namely System32 and/or SysWoW64 which provide a clear distinction between 32/64 bit modules.

It's certainly a distinction, although I wouldn't say it's a "clear" one what with (on a 64-bit system) 64-bit DLLs going into System32 and 32-bit DLLs going into SysWow64.

[Groucho2004]

Originally Posted by wonkey_monkey

It's certainly a distinction, although I wouldn't say it's a "clear" one what with (on a 64-bit system) 64-bit DLLs going into System32 and 32-bit DLLs going into SysWow64.

Can you elaborate? I'm not sure if I understand your point.

[StainlessS]

Yep, M$ has their own unique [patent pending] way of keeping I.T. guys in work, the system/system32/SysWOW64 conundrum is not the only one of its kind.

EDIT: My own favourite is,
"The system drive is the drive you boot to, and the boot drive is the one your system is on".

[wonkey_monkey]

Originally Posted by Groucho2004

Can you elaborate? I'm not sure if I understand your point.

64 bit DLLs -> System32
32 bit DLLs -> Syswow64

It's confused plenty of people in its time.

[Groucho2004]

Originally Posted by wonkey_monkey

64 bit DLLs -> System32
32 bit DLLs -> Syswow64

It's confused plenty of people in its time.

Ah, I see what you mean. On that subject, here is a very good and compact explanation on how this came about:
https://stackoverflow.com/questions/...23671#37823671

[manolito]

Originally Posted by Groucho2004

I believe it's this one.

No, DO NOT use this version. It reintroduced the old seeking bug which has been fixed for a while. Take this version instead:
https://forum.doom9.org/showthread.p...79#post1891279

[MikeT]

I'm also running into issues with v210 10bit input through QTGMC, and would like to ask for any pointers that you guys could give me.

I have a recent and clean installation of VirtualDub2, AviSynth+ and QTGMC. All 64bit working in a Windows10 environment.

My simple Avisynth script works well with 8bit (uncompressed) input, but fails with 10bit v210 (uncompressed) input, giving the following error:

---------------------------
File open error
---------------------------
Avisynth open failure:
TemporalSoften: Scenechange not available on RGB32/64
(D:/Program Files (x86)/AviSynth+/plugins64+/QTGMC.avsi, line 468)
(D:\Users\miket\Videos\Process VHS Tapes\Files De-Interlaced\10bit Test 01.avs, line 10)
---------------------------
OK   
---------------------------

Basic AVI script is as follows:

AviSource("D:\Users\miket\Videos\Process VHS Tapes\Files Capture\10bit Test 01.avi") 
#
#Settings for use of de-interlacing using QTGMC via AviSynth
#
#Version()
SetFilterMTMode("QTGMC",2)	# Put QTGMC into multithreading mode 2
#ConvertToYUY2()
AssumeTFF()		# Top Frame First or BFF

QTGMC(Preset="Slower", Edithreads=2)

Prefetch(threads=6)

And AVSMeter info is as follows:

AVSMeter 2.9.7 (x64), 2012-2019, Groucho2004

VersionString:              AviSynth+ 3.4 (r2923, 3.4, x86_64)
VersionNumber:              2.60
File / Product version:     3.4.0.0 / 3.4.0.0
Interface Version:          6
Multi-threading support:    Yes
Avisynth.dll location:      C:\WINDOWS\SYSTEM32\avisynth.dll
Avisynth.dll time stamp:    2019-10-20, 13:58:12 (UTC)
PluginDir2_5 (HKLM, x64):   D:\Program Files (x86)\AviSynth+\plugins64
PluginDir+   (HKLM, x64):   D:\Program Files (x86)\AviSynth+\plugins64+


[CPP 2.6 Plugins (64 Bit)]  [Version, Time stamp]
D:\Program Files (x86)\AviSynth+\plugins64+\ConvertStacked.dll  [x.x.x.x, 2019-10-20]
D:\Program Files (x86)\AviSynth+\plugins64+\DirectShowSource.dll  [x.x.x.x, 2019-10-20]
D:\Program Files (x86)\AviSynth+\plugins64+\ffms2.dll  [x.x.x.x, 2016-12-29]
D:\Program Files (x86)\AviSynth+\plugins64+\ImageSeq.dll  [x.x.x.x, 2019-10-20]
D:\Program Files (x86)\AviSynth+\plugins64+\masktools2.dll  [2.2.18.0, 2018-09-05]
D:\Program Files (x86)\AviSynth+\plugins64+\mvtools2.dll  [2.7.41.0, 2019-05-02]
D:\Program Files (x86)\AviSynth+\plugins64+\nnedi3.dll  [0.9.4.53, 2019-06-06]
D:\Program Files (x86)\AviSynth+\plugins64+\RgTools.dll  [0.98.0.0, 2019-06-03]
D:\Program Files (x86)\AviSynth+\plugins64+\Shibatch.dll  [x.x.x.x, 2019-10-20]
D:\Program Files (x86)\AviSynth+\plugins64+\TimeStretch.dll  [x.x.x.x, 2019-10-20]
D:\Program Files (x86)\AviSynth+\plugins64+\VDubFilter.dll  [x.x.x.x, 2019-10-20]

[Scripts (AVSI)]  [Time stamp]
D:\Program Files (x86)\AviSynth+\plugins64+\AnimeIVTC.avsi  [2020-01-05]
D:\Program Files (x86)\AviSynth+\plugins64+\colors_rgb.avsi  [2019-10-20]
D:\Program Files (x86)\AviSynth+\plugins64+\QTGMC.avsi  [2020-01-05]
D:\Program Files (x86)\AviSynth+\plugins64+\smdegrain.avsi  [2020-01-05]

[Uncategorized files]  [Time stamp]
D:\Program Files (x86)\AviSynth+\plugins64+\colors_rgb.txt  [2019-10-20]

Am I missing any crucial plugins or .dll's ? ffms2.dll looks a bit long-in-the-tooth. Could that be the issue?

Any help would be gratefully received.

[nhope]

HOW TO DEAL WITH ZOOMS?

I am deinterlacing 1440x1080-25i HDV with QTGMC 3.364. I am having problems deinterlacing one clip that includes a fairly rapid zoom. Here's a short sample. Below is the type of script I'm using (in reality I'm frameserving AVI and using AviSource but DirectShowSource works directly on the sample clip):

SetMemoryMax(16384)
DirectShowSource("e:\HDV-zoom-sample.m2t")
AssumeTFF()
ConvertToYV12(interlaced=true)
QTGMC(Preset="Medium", EdiThreads=4)
Spline36Resize(1920,1080)
AssumeFPS(50)
Prefetch(16)

When stepping through the deinterlaced file in 50p it zooms in and out with each frame.

Is there any way to deal with this?

As a workaround I threw half the frames away with fpsdivisor=2 and then doubled the framerate with MFlowFps but the result isn't great.

[Groucho2004]

Originally Posted by nhope

When stepping through the deinterlaced file in 50p it zooms in and out with each frame.

The clip you posted is BFF, change AssumeTFF to AssumeBFF. You can easily test the field order as described here.

Also, Directshowsource would not be my first choice as a source filter (in fact, it should be a last resort). DGIndex/DGDecode work just fine with this source.

By the way, your underwater videos are amazing.

[stax76]

Does anybody know if i7-3770K supports AVX2 and if any of the following plugins might crash using this CPU?

AddGrainC.dll
Average.dll
Decomb.dll
dfttest.dll
dither.dll
EEDI2.dll
EEDI3.dll
ffms2.dll
fft3dfilter.dll
KNLMeansCL.dll
LSMASHSource.dll
masktools2.dll
modPlus.dll
MPEG2DecPlus.dll
mvtools2.dll
Plugins_JPSDR.dll
RgTools.dll
TDeint.dll
yadifmod2.dll

Problem is somebody with Core i7-3770K gets 1114/0x45a ERROR_DLL_INIT_FAILED trying to use QTGMC.


Timestamps and versions are listed here:

https://docs.google.com/spreadsheets...it?usp=sharing


Github Issue is here:

https://github.com/staxrip/staxrip/issues/125


There have been minimum 5 bug reports with some terrible dfttest.dll error in recent months:

https://www.google.com/search?q=stax...hrome&ie=UTF-8


StaxRip isn't particular smart when it tries to figure out which plugins need to be loaded, it analyzes the script code for function names and loads all plugins a script supports and not only the ones the filter configuration will actually use.

[pinterf]

3770 is avx only

[pinterf]

Average, masktools2, mvtools, rgtools, fft3dfilter are automatic regarding cpu detection. Jpsdr plugins do have different builds for different processor architectures.

[nhope]

Originally Posted by Groucho2004

The clip you posted is BFF, change AssumeTFF to AssumeBFF. You can easily test the field order as described here.

I suspected that and had tried AssumeBFF before posting, but with a similar "in-out" result. Just checked the field order using the method in your link and it looks "wrong" ("in-out") with either AssumeTFF or AssumeBFF.

The original HDV is TFF (I hope, as I've been using AssumeTFF with it for 10 years!), it was rendered in VEGAS as TFF, and MediaInfo reports TFF. I'm wondering whether the problem is simply related to the rate of zoom of the clip somehow making the fields seem reversed

Also, Directshowsource would not be my first choice as a source filter (in fact, it should be a last resort). DGIndex/DGDecode work just fine with this source.

This was just a one-off sample file for my forum post. Usually I am frameserving from VEGAS Pro and using AviSource.

By the way, your underwater videos are amazing.

[Groucho2004]

Originally Posted by nhope

I suspected that and had tried AssumeBFF before posting, but with a similar "in-out" result. Just checked the field order using the method in your link and it looks "wrong" ("in-out") with either AssumeTFF or AssumeBFF.

The original HDV is TFF (I hope, as I've been using AssumeTFF with it for 10 years!), it was rendered in VEGAS as TFF, and MediaInfo reports TFF. I'm wondering whether the problem is simply related to the rate of zoom of the clip somehow making the fields seem reversed



This was just a one-off sample file for my forum post. Usually I am frameserving from VEGAS Pro and using AviSource.

Well, I can only use the clip you posted and my result is this:

Script:

Import("E:\Apps\VideoTools\AVSPlugins\QTGMC.avsi")
LoadPlugin("E:\Apps\VideoTools\DGDec\DGDecode.dll")
MPEG2Source("F:\HDV-zoom-sample.d2v")
AssumeBFF()
QTGMC(preset = "Slow")
Spline36Resize(1920,1080)
AssumeFPS(50000, 1000)

Encoded clip:
https://www.mediafire.com/file/swdxg...ample.mkv/file

[stax76]

@pinterf

Thanks, one user could make it run by replacing Plugins_JPSDR as suggested by another user, I had the avx2 version included and replaced it now with the avx version. The other user did not reply yet. I don't have a particular interest in CPUs otherwise I would have avoided the issue or found the solution myself.

[nhope]

@Groucho2004

That file is indeed BFF and I have absolutely no idea why. I checked others in my archive, including clips in the same sequence, and they are TFF, as they should be for HDV. I fixed it with the following script:

#Change field order in Vegas project to BFF and the clip on the timeline to BFF then frameserve
AVISource("D:\fs.avi")
AssumeBFF()
SeparateFields()
weave()

The output of that then worked nicely with QTGMC.

Thanks very much for your help.

[johnmeyer]

Nick, it's always nice to hear from you again. I miss all of our discussions in the old Vegas forum.

FWIW, whenever I have any problem, either with my own video or something someone gives me, I always first open it with this script:

AssumeTFF()
Separatefields()

and walk through it one field at a time. If I see a problem, I change to BFF and try again.

The number of videos out there with unexpected field order is enormous. In this country I still see video, every single day, that has field reversal, which gives you that funny, "juddery" look on any sort of fast movement.

[nhope]

@johnmeyer Hi John, nice to see you. Your old posts came up frequently whilst I was troubleshooting this.

I did suspect a field order problem before posting here, and did try BFF. But unfortunately, being out of the habit of using DGIndex/DGDecode, I chose to use DirectShowSource just for the purpose of getting the .m2t file open in AviSynth for troubleshooting. But DirectShowSource gets it totally wrong; it gives a weird and incorrect result for both TFF and BFF when stepping through the file at 50p; for example on that zooming clip, instead of "IN > OUT > IN > OUT etc" it goes "IN > DIFFERENT BUT NEITHER IN NOR OUT > OUT A BIT > IN > etc.".

[Sharc]

Originally Posted by johnmeyer

FWIW, whenever I have any problem, either with my own video or something someone gives me, I always first open it with this script:

AssumeTFF()
Separatefields()

and walk through it one field at a time. If I see a problem, I change to BFF and try again.

And avoid DirectShowSource as a source filter, especially for interlaced video. It should be ditched for video analysis. Also we must not blindly trust MediaInfo. For nhope's clip MediaInfo reports the field order as TFF which is obviously wrong.

Edit:
ffprobe (ffmpeg) also reports the field order like 'field_order=tt'.
Apparently the mpeg2 TFF flag is set but in fact the field order has been reversed . Don't know how this can happen.

[LigH]

DirectShowSource can only be trusted as far as you actively control the selection of filters ... which many users may not be able to achieve. There might be a Telecine you are not aware of, or frame skips due to performance, whatever.

But even the material might be a mess. There are norm conversions of the worst kind, and the most pervert is content stuffing to achieve more time for ads (in case of TV broadcasts).

Try to use a source filter one can trust. DG*Decode are among these, as well as FFMS2 or L-SMASH Works (with exceptions in rare cases, depending on the release).