QTGMC Deinterlacing Script (v3.32)

[fusebyte]

To better understand,forgive my less experience,
this is Mediainfo analyzed content of my MPEG-TS 1080i.TS but don't see info about Frame sequence.

Generale
ID : 1 (0x1)
Complete name : D:\Documents and Settings\Administrator\Desktop\Working\MyHDTV_1080i.ts
Format : MPEG-TS
File size : 16,0 GiB
Duration : 2h 3min
Overall bit rate : 18,6 Mbps
Maximum Overall bit rate : 35,5 Mbps

Video
ID : 4113 (0x1011)
Menu ID : 1 (0x1)
Format : MPEG Video
Format version : Version 2
Format profile : Main@High
Format settings, BVOP : Si
Format settings, Matrix : Predefinited
Format settings, GOP : M=3, N=15
Codec ID : 2
Duration : 2h 3min
Bit rate mode : Variable
Bit rate : 17,1 Mbps
Nominal bit rate : 80,0 Mbps
Width : 1 920 pixel
Height : 1 080 pixel
Display aspect ratio : 16:9
Frame rate : 29,970 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Interlaced
Scan order : Top Field First
Bits/(Pixel*Frame) : 0.275
Stream size : 14,8 GiB (92%)

[firebo14]

I cant seek the video (vid doesnt show) nor save the video. Am i missing plugins or wrong script?

Someone help please... i really want to deinterlace the vid with double fps.

Here is my .avs script:

FFVideoSource("C:\Documents and Settings\Extra\Desktop\New Folder\Gantz.2011.1080i.DD.5.1\Gantz.2011.1080i.DD.5.1.ts")

QTGMC( Preset="Slower" )

My video interlace type is:

Scan type                        : MBAFF

Is it possible to do triple fps or more? If yes, please tell me... I love the smoothness of high fps.

Thank you for the deinterlacing script.. i really want to use it... :]

[Didée]

1) "You shall not have multiple versions of the same plugin in the autoload folder."

- Keep RemoveGrainSSE2.dll. Delete all other RemoveGrain(XXX).dll files.
- same for Repair.dll
- same for Rsharpen.dll
- similar for mt_masktools-26.dll

2) Remux *.ts to *.mkv. FFmpegSource can have problems with *.ts container. (not necessarily, but it can happen)

3) Browse through the last few pages. -Vit- has given lots of useful pointers about stability.

[firebo14]

Thanks for the quick reply... i will try what you said.. now...
:]

Edit 1:
Thanks alot!.. it seems to be working, but i have to wait until i see if it works...




Wow, 0.07 fps. This is going to take a while.. T-T

[Mini-Me]

Originally Posted by firebo14

Thanks for the quick reply... i will try what you said.. now...
:]

Edit 1:
Thanks alot!.. it seems to be working, but i have to wait until i see if it works...




Wow, 0.07 fps. This is going to take a while.. T-T

OMFG. Is that 0.07 FPS of input or 0.07 FPS of output? If we're talking 0.07 FPS of 60 FPS output (which is probably the case), that would take 23 years for all 235 hours of my footage. I mean, not that 11.5 years is much better, but...wow. I'd better get started NOW.

[Boulder]

The higher the resolution, the more likely you could get away with using "lower quality" presets which are much faster. This issue has also been discussed in this thread a few times.

[Mini-Me]

Originally Posted by Boulder

The higher the resolution, the more likely you could get away with using "lower quality" presets which are much faster. This issue has also been discussed in this thread a few times.

Qualität über alles! What's a couple decades, anyway? I can wait.

Seriously though, I hope that firebro14 is testing this on an Atom netbook or something. He may be deinterlacing 1080i, but that 0.07 FPS isn't even using the very slow or placebo presets. firebro, would you mind posting your specs?

Also, does anyone know the time complexity of the filter with respect to resolution? Is it linear in terms of source or output pixels or lines, or is it higher order? (This might have been mentioned in the discussion you refer to, but just in case anyone knows off the top of their head...)

[-Vit-]

Most operations are per-pixel, but there is the motion search and NNEDI3, the complexity of which depends on your settings. It's a bit tricky to give a practical complexity scaling because it depends on hardware, choice of settings, number of threads (even if you single-thread QTGMC, NNEDI3 uses threads) and whether you're simultaneously trying to x264 the result or encoding to lossless. CPU underutilization can cause low encoding fps on faster machines for HD, which would make fps comparisons with SD unrepresentative. Many people's fps will scale worse than ideal because they haven't tweaked for all these factors.

However, on preset="Slower", with properly tweaked multi-threaded scripts using 100% CPU, I get ~42fps SD and ~6fps HD (i7 930@3.7Ghz). So the scaling there seems to be linear per-pixel, about 1.2x. Edit: That was in MeGUI, encoding to lossless (via mencoder, they've recently changed to ffmpeg, which is slower). So you would need to add an x264 (or whatever) encoding pass, but the speed of that would be pretty much independent of QTGMC.

[Mini-Me]

Originally Posted by -Vit-

Most operations are per-pixel, but there is the motion search and NNEDI3, the complexity of which depends on your settings. It's a bit tricky to give a practical complexity scaling because it depends on hardware, choice of settings, number of threads (even if you single-thread QTGMC, NNEDI3 uses threads) and whether you're simultaneously trying to x264 the result or encoding to lossless. CPU underutilization can cause low encoding fps on faster machines for HD, which would make fps comparisons with SD unrepresentative. Many people's fps will scale worse than ideal because they haven't tweaked for all these factors.

However, on preset="Slower", with properly tweaked multi-threaded scripts using 100% CPU, I get ~42fps SD and ~6fps HD (i7 930@3.7Ghz). So the scaling there seems to be linear per-pixel, about 1.2x. Edit: That was in MeGUI, encoding to lossless (via mencoder, they've recently changed to ffmpeg, which is slower). So you would need to add an x264 (or whatever) encoding pass, but the speed of that would be pretty much independent of QTGMC.

Wow, that's a night and day difference compared to firebro14's setup with the same preset. It's almost 100x faster, so I imagine he must have been directly encoding the result with e.g. x264, using a weak computer with single-threading and a very unoptimized...something. I was kind of shocked when I saw his FPS, and I thought maybe the recent versions with source match (which I don't have yet) might have taken heavy hits at slower presets or something.

Anyway, thanks for your perspective on the scaling.

[Didée]

Try any "slow" preset with "blocksize=16,search=5,searchparam=8,DCT=1".

0.0xx fps are almost guaranteed, even with SD content.

[fusebyte]

I tried with EAC3TO. Very good output and remuxable with MKVMERGE to add SRT sub track without any playback problem but I would wish try with QTGMC encoder
and don't understand how start avs script with cmd QTGMC inside.
I always obtain errors, I'm sure that's just my fault.

[dragon_warrior]

Originally Posted by fusebyte

I tried with EAC3TO. Very good output and remuxable with MKVMERGE to add SRT sub track without any playback problem but I would wish try with QTGMC encoder
and don't understand how start avs script with cmd QTGMC inside.
I always obtain errors, I'm sure that's just my fault.

and

[Lyris]

First time user here.

That is magnificent. Thank you.

[Aktan]

First off, great job on this script. It does wonders. Now I do see it as being very very slow. I'm curious to know if it would be faster if it was combined into one plugin instead. I would think some of the work is redundant because you are using different plugins and they aren't talking to each other.

Minor comment bug report:

for MatchPreset2 table, the Very is on top of Placebo, making it look like "Very Placebo" instead of "Very Slow"

[dirk362]

I get a DLL error with only certain Presets ???

The example AVS below works fine

LoadPlugin("E:\Tools\Applications\DGMPGDec\DGDecode.dll")
SetMemoryMax(1024)
SetMTMode(5,6)
MPEG2Source("D:\temp\inputfile temp files\inputfile.d2v", CPU=6)
SetMTMode(2)
AssumeTFF()
ConvertToYV12(interlaced=true)
Import("C:\Program Files (x86)\AviSynth 2.5\plugins\QTGMC3.11.avsi")
QTGMC( Preset="Slower", EdiThreads=3 )
SelectEven()

However, if I change to

QTGMC( Preset="Very Slow", EdiThreads=3 )

I get the error message of

FFT3DFilter: Can not load FFTW3.DLL !
(C:\Program Files (x86)\AviSynth 2.5\plugins\QTGMC3.11.avsi, line 632)
(D:\temp\inputfile temp files\inputfile.avs, line 9)

This occurs for Placebo and Very Slow only. All other presets work fine.
I'm fairly confident I've not messed up any of the pre-reqs. And the file does exist in both the plugins directory for AviSynth and also in the path.

Any ideas anyone ?

Thanks in advance

[dirk362]

Originally Posted by dirk362

I get a DLL error with only certain Presets ???

FFT3DFilter: Can not load FFTW3.DLL !
(C:\Program Files (x86)\AviSynth 2.5\plugins\QTGMC3.11.avsi, line 632)
(D:\temp\inputfile temp files\inputfile.avs, line 9)

OK - I've been a bit thick for which I apologise. The issue was that as this is 64-bit Windows I need to have FFTW3.DLL in the C:\Windows\SysWOW64 directory (even though that's not in the path as an environment, the OS sorts this out by recognising it's a 32-bit app).

So thought I'd post for those on 64-bit OS but still using 32-bit AviSynth that you need to think about SysWOW64 directory as well. Doh !

[-Vit-]

Atkan: it's only as slow as your preset and computer. Seriously though, regarding plugins "talking to each other", there's not much redundancy in the script - that's not really the problem. It's the enormous number of operations that makes it slow. Some ideas I have for speed are:
- Using the GPU to do the simpler per-pixel tasks
- Using simpler algorithms for the chroma deinterlacing
- Reducing the cache load, to improve performance on very complex settings
I'm working on all three of those ideas.

Writing a QTGMC-custom plugin might bring some benefits, most notably being able to combine some of the simpler operations. That is partly what I'm intending to do with the GPU point above...

EDIT: Well spotted on that typo! Hmmm, "Very Placebo", I'm sure there are some people who would like that option...
____

dirk362: easy mistake to make - I've updated the requirements in the OP to briefly note the issue

[kypec]

Originally Posted by -Vit-

EDIT: Well spotted on that typo! Hmmm, "Very Placebo", I'm sure there are some people who would like that option...

Sorry for being such numb but what exactly is affected by this bug (seeing that you did not mention any bug-fix released yet)?
If there is preset "Very Slow" used in the script, does it work as intended or not?

[-Vit-]

It was just a mistake in a comment. No effect on the script.

[Vitaliy Gorbatenko]

Bad way to connect their modules through the autoload and :\windows\* directory
It is better to copy its modules to the selected directory, for example:
x:\Knot\AviSynthPluginsx64\
and connect them in a script:
SetWorkingDir ("x:\Knot\AviSynthPluginsx64\")
LoadPlugin ("average.dll")
...
and so on.
And with the re installation of the system problems will not arise and can be accurately select Plug-ins, and syntax is reduced.

PS: but this is my personal opinion.