QTGMC Deinterlacing Script (v3.32)

[yup]

Octo-puss!
Try sequentially 1024, 1152,1280 and more and waiting no crash.
I am sure You find Your magic value.
Type Your script also.
yup.

[Octo-puss]

So far I am not getting crashes with 768, but I know 800 crashed before.

This is my script:
SetMemoryMax(768)
SetMTMode(3, 8)
LoadPlugin("F:\Programy\Audio & video\MeGUI\tools\dgavcindex\DGAVCDecode.dll")
AVCSource("D:\Black Symphony\F1_T2_Video - .dga")
SetMTMode(2)
QTGMC(Preset="Slow", EdiThreads=1)


I am also having really difficult time figuring out how to set the threads. For some weird reason I am getting the most CPU usage (or at least it seems so) with 3,8, but one of my previous experiments showed about 25% faster encode time with 3,4.

[Octo-puss]

Is it normal to get 0,5 FPS with very slow preset? With slower I get around 5.
My CPU is overclocked 3770K.

Also, when loading the script in MeGui, I get an error if I use SetMTMode(3, 8). It just gives some error on line 524 (possibly some other in other cases). If I switch to SetMTMode(3, 6), it finally works. Any explanation for this?

[LigH]

From one preset to another, QTGMC may use a whole different plugin for specific internal steps. So a huge difference is indeed possible.

[BeNooL]

Using MeGUI as well, I'm getting good results with scripts like the following:

SetMemoryMax(1200)
SetMTMode(5, 6)
<input>
SetMTMode(2)
QTGMC(preset="medium", EdiThreads=2,FPSDivisor=2)
<crop>
<resize>

Bumping to 8 threads slows things down actually (too many threads when encoding) and 4 is not enough. 6 really seems to be the sweet spot.

With x264 encoding running along, I get around 10fps on a i7 3770 (non K but still running at 3.7Ghz)

[Octo-puss]

Try with slower and tell me what result you get, I am interested. With 3770K@4,4GHz I get under 2FPS :D

[BeNooL]

Here you go. I tried with a DVB recording, so 1080i to 720p. This was avs file's content:

LoadPlugin("C:\megui\tools\ffms\ffms2.dll")
SetMemoryMax(1200)
SetMTMode(5, 6)
FFVideoSource("myvideo-1440x1080i.mkv", threads=1)
SetMTMode(2)
QTGMC(preset="slower", EdiThreads=2,FPSDivisor=2)
LanczosResize(1280,720)

Running a video analysis pass in VirtualDub it goes at about 5.50 fps. Using arount 70-75% CPU due to limiting to 6 main threads.

Using MeGui to perform encoding with X264 64bits (limited to 3 threads) it runs just a little under 5 fps.

[Music Fan]

Hi,
I need to de-interlace a video and I made tests on another video containing some little characters to compare tdeint(mode=1), qtgmc() and nnedi3(field=-2).
The original video is in 1080i @ 29.97 fps and I de-interlaced it in 1080p @ 59.94 fps. I cropped a lot of lines to keep a little part of the video.
Here is the result not resized, I gathered the 6 pictures with Photoshop.
On top, they are 2 consecutive images de-interlaced with tdeint ; in the midst, the same images de-interlaced with qtgmc ; at the bottom, the same images de-interlaced with nnedi3, it's the quality order (to my eyes) ;

http://nsa34.casimages.com/img/2013/11/04/131104040727928212.jpg

The same picture resized with Photoshop to see better ;

http://nsa34.casimages.com/img/2013/11/04/131104041125643209.jpg

I'm astonished by this result because I often read that qtgmc was the best de-interlacer.
But my script is very simple, just qtgmc().
With nnedi3, the characters shake a lot ; they are too big on a picture and too small on the next, as you can see.

I used TDeint 1.1, QTGMC 3.32 and nnedi3 0.9.4.

Is there a way to increase qtgmc's result quality with any settings ?

[Guest]

Can you please post a link to the unprocessed source so we can experiment with it?

[Music Fan]

It's a 56MB video I found a few months ago on another forum but it has been erased.
I can upload it if needed.
Anyway, do you know where does this difference between TDeint and QTGMC come from ? Is QTGMC more suitable with other types of videos ?

[Guest]

Post the video! That's what will enable us to best answer your questions.

[Music Fan]

Ok ;
http://www21.zippyshare.com/v/41644375/file.html

[Guest]

Thank you. Downloading now for some experimentation/analysis...

[Music Fan]

Great.
Here is the crop I used ;
crop(500,50,-1290,-950)

[poisondeathray]

BTW, your crop is "illegal" , vertical interlaced YV12 crop must be mod4
http://avisynth.nl/index.php/Crop

You need to specify AssumeTFF() before QTGMC and TDeint or use order=1 for TDeint

[Guest]

Good points, poisondeathray.

Music Fan, can you repeat your testing with correct cropping and specifying the field order? Meanwhile, my encoding is in progress with no cropping and I know that DGSource() is setting the field order correctly. I will report the results of that shortly.

[kalehrl]

I've recently discovered QTGMC and use it to deinterlace SD MPEG2 material and remove noise.
The usual line I use is:
QTGMC(Preset="Super Fast", EZDenoise=2.5)
I like the quality of noise removal using EZDenoise and I wonder what plugin is it using to accomplish that?
Sometimes I process progressive material and I'd like to use only the noise removal part of QTGMC.
So, I would like to know what denoising plugin to use to get the results I get with EZDenoise=2.5.
Thank you

[Music Fan]

Music Fan, can you repeat your testing with correct cropping
BTW, your crop is "illegal" , vertical interlaced YV12 crop must be mod4
http://avisynth.nl/index.php/Crop
I made this crop after de-interlacing, so I guess it has no effect on de-interlacing quality. And before to crop, I had seen the same results.

and specifying the field order?
You need to specify AssumeTFF() before QTGMC and TDeint
I had done this, here is the complete script I used ;
LWLibavVideoSource("H:\video.MP4")
AssumeFPS(30000, 1001)
assumetff()
tdeint(mode=1)#or qtgmc() or nnedi3(field=-2)
crop(500,50,-1290,-950)

LWLibavVideoSource works with LSMASHSource.dll (I used rev693).

[HolyWu]

@kalehrl
The denoiser used is FFT3DFilter by default since you leave NoisePreset at its default("Fast"). The sigma value equals to the EZDenoise value if you don't specify it explicitly.

[kalehrl]

Thank you. I read the FFT3DFilter documentation and got it working.
Now I know what to use when I have a progressive source.
AvsPmod reports valid numbers for sigma from 0.1-10 whereas for QTGMC EZDenoise it is from 0.0-5.

[poisondeathray]

...

I'm astonished by this result because I often read that qtgmc was the best de-interlacer.
But my script is very simple, just qtgmc().
With nnedi3, the characters shake a lot ; they are too big on a picture and too small on the next, as you can see.

I used TDeint 1.1, QTGMC 3.32 and nnedi3 0.9.4.

Is there a way to increase qtgmc's result quality with any settings ?


All deinterlacers have pros/cons . There is no "perfect" deinterlacer. Some are good for some situations but poor at others

NNEDI3 used alone as an intrafield deinterlacer will result in up/down motion because of the odd/even field offset. Use it with yadifmod to address that
eg. yadifmod(order=1, mode=1, edeint=nnedi3(field=3))

The section you're looking at is ~bobbed frame 1300. The sample section you chose was a static section . Have a look at something in motion and you will see terrible flickery aliasing with tdeint

e.g in motion , bobbed frames 1260-1261

TDeint
http://i44.tinypic.com/25ptgu1.gif

QTGMC
http://i42.tinypic.com/aw4005.gif

The original TGMC was known for it's calming of bob flicker and aliasing, but the processing and antialising tended to smooth out fine details . Pros and cons. You can't have your cake and eat it too :devil: . There is no "perfect" deinterlacer for everything.

If you want to improve those static sections with QTGMC, you can set sourcematch and adjust TR to get cleaner static sections - but other types of content, other sections might not look as "calm"
e.g
QTGMC( Preset="slow", SourceMatch=2, Sharpness=0.2, TR2=1 )

tdeint/qtgmc with the above settings on bobbed frame 1300
http://i44.tinypic.com/se4lf7.png

There are other options too ; have a look at the doucmentation. There are other apporaches too: for example you can combine TDeint with a motion mask (TMM) and QTGMC .

The bottom line is all approaches have pros/cons and you have to adjust for whatever works for your source and your goals

[Guest]

@Music Fan

My results from qtgmc, and those just shown by poisondeathray, are nowhere near as blurry as the screenshot you posted. I would suggest that you try to find the cause of this discrepancy, because I don't think it is fully accounted for by the factors discussed by poisondeathray.

[Music Fan]

I can't explain why we don't get the same results. Did you use the same script than mine, I mean tdeint(mode=1) and not just tdeint() ?

[Music Fan]

All deinterlacers have pros/cons . There is no "perfect" deinterlacer. Some are good for some situations but poor at others

NNEDI3 used alone as an intrafield deinterlacer will result in up/down motion because of the odd/even field offset. Use it with yadifmod to address that
eg. yadifmod(order=1, mode=1, edeint=nnedi3(field=3))

The section you're looking at is ~bobbed frame 1300. The sample section you chose was a static section . Have a look at something in motion and you will see terrible flickery aliasing with tdeint

e.g in motion , bobbed frames 1260-1261

TDeint
http://i44.tinypic.com/25ptgu1.gif

QTGMC
http://i42.tinypic.com/aw4005.gif

The original TGMC was known for it's calming of bob flicker and aliasing, but the processing and antialising tended to smooth out fine details . Pros and cons. You can't have your cake and eat it too :devil: . There is no "perfect" deinterlacer for everything.

If you want to improve those static sections with QTGMC, you can set sourcematch and adjust TR to get cleaner static sections - but other types of content, other sections might not look as "calm"
e.g
QTGMC( Preset="slow", SourceMatch=2, Sharpness=0.2, TR2=1 )

tdeint/qtgmc with the above settings on bobbed frame 1300
http://i44.tinypic.com/se4lf7.png

There are other options too ; have a look at the doucmentation. There are other apporaches too: for example you can combine TDeint with a motion mask (TMM) and QTGMC .

The bottom line is all approaches have pros/cons and you have to adjust for whatever works for your source and your goals
Thanks, very interesting ! :)
I'm testing your script but this is very slow : 0.02 fps :eek:
With tdeint(mode=1), I'm around 26 fps, 1300 times faster ! :eek:
It would need weeks to encode long videos.:scared:

[Music Fan]

Other question : to avoid a so slow de-interlacing, couldn't we use this kind of script when we need to remove noise on interlaced material (with filters working only on progressive videos) that we wanna keep interlaced ?
interlaced source
assumetff()#or bff
separatefields()
noise removing
weave()

And could it also work for resize ? I guess the answer is no because we can't resize an image including only a line on two.
interlaced source
assumetff()#or bff
separatefields()
resize
weave()

[Guest]

I can't explain why we don't get the same results. Did you use the same script than mine, I mean tdeint(mode=1) and not just tdeint() ? I used qtgmc and compared to your shots of qtgmc.

[StainlessS]

with filters working only on progressive videos) that we wanna keep interlaced
....
And could it also work for resize ? I guess the answer is no because we can't resize an image

You might like to take a peek at StickBoy script functions,
jdl-interlace.avsi,
JDL_UnfoldFieldsVertical, JDL_FoldFieldsVertical
and JDL_InterlacedResize.

Here:- http://www.avisynth.nl/users/stickboy/

[Music Fan]

Thank you, I tested both, JDL_InterlacedResize is great !
It seems a very good alternative to QTGMC (followed by a re-interlacing) when the main goal is to resize interlaced videos.
About UnfoldFieldsVertical() followed by FoldFieldsVertical(), do you believe it brings anything for noise removal filters compared to separatefields() with weave() ?
I see the difference of course, but both separate the fields whose lines are attached, thus I wonder if it wouldn't be the same stuff for filters.
The difference being that fields are processed together with UnfoldFieldsVertical() and one after the other with separatefields().

[StainlessS]

If you just separate fields then each field will be vertically offset from those either side
and will not produce good results if processing temporally. The unfold/fold duo align top and bottom
fields with those of it's neighbour frames. Flip is advised if doing spacial processing so the bottom scanlines
of each field are adjacent to each other (bottom before the flip).
To do temporal processing when only separating fields, you would want to process separately even and
odd field sets, before putting them back together. (EDIT: Which is essentially what the unfold/fold with
flip thing does, but does it simultaneously rather than separate even/odd processing).

[Music Fan]

Thanks for this clear explanation ;)
As a lot of filters work spatially (with or without temporal processing but rarely only temporal), I guess flip=true should be the default setting (instead of false), especially because treating a flipped field is not problematic for temporal filters.

[StainlessS]

Yep, thats what I would choose.

[Octo-puss]

Goddamnit, after like 28 hours of encoding it bugged out on me without any errors, but the process just stopped doing anything. Just sitting there.
Is there any way to troubleshoot this? I am pretty sure it's the deinterlacing that went nuts, but I have no way to prove it. MeGui works fine, I could abort the job without problems...

This is my script

SetMemoryMax(768)
SetMTMode(3,6)
LoadPlugin("F:\Programy\Audio & video\MeGUI\tools\dgavcindex\DGAVCDecode.dll")
AVCSource("D:\Black Symphony\F1_T2_Video - .dga")
SetMTMode(2)
QTGMC(Preset="Slower", EdiThreads=1)
SelectEven()

What can I possibly change?

[Octo-puss]

Also, what's up with various speed settings giving me nonsense error messages?
For example if I set "Ultra Fast", MeGui produces error saying there is no function called Yadif and sending me to two different lines of the main QTGMC script. If I use some other setting, it works fine. If I try to use the Very Slow, I get error saying something about FFT3D-something.dll.
Just what the heck is going on?

[Groucho2004]

Also, what's up with various speed settings giving me nonsense error messages?
For example if I set "Ultra Fast", MeGui produces error saying there is no function called Yadif and sending me to two different lines of the main QTGMC script. If I use some other setting, it works fine. If I try to use the Very Slow, I get error saying something about FFT3D-something.dll.
Just what the heck is going on?
The messages are not nonsense but indicate that you need to familiarize yourself with the term RTFM.
Hint: Have look at the notes in the first post of this thread, section "Full Plugin List".

[Groucho2004]

Goddamnit, after like 28 hours of encoding it bugged out on me without any errors, but the process just stopped doing anything. Just sitting there.
Are you overclocking your processor by any chance?

[Octo-puss]

The messages are not nonsense but indicate that you need to familiarize yourself with the term RTFM.
Hint: Have look at the notes in the first post of this thread, section "Full Plugin List".
All of the required plugins are in the Avisynth folder. But thank you for trying to make an idiot out of me.

[poisondeathray]

All of the required plugins are in the Avisynth folder. But thank you for trying to make an idiot out of me.

It doesn't go in the plugins folder . Please read the 1st post
http://forum.doom9.org/showpost.php?p=1423459&postcount=1



** For FFT3DFilter and ddftest you also need the FFTW3 library (main page / windows zips). On Windows the file needed for both is libfftw3f-3.dll. However for FFT3DFilter, it needs to be called FFTW3.dll, so you will need two copies and rename one. On Windows put the files in your System32 or SysWow64 folder (which depends on your OS and the version of AviSynth that you're running)

[Octo-puss]

Yes I have that as well, just didn't feel like it was needed to mention, because otherwise the whole thing wouldn't even start, as far as I know.

[poisondeathray]

Then post the full error message. Verbatim .

When you say something is in the plugins folder, do you mean the megui avisynth plugins folder or the default avisynth install plugins folder ?

[Octo-puss]

You know what? I solved it myself.
Apparently the new (newest) plugin package is completely bugged and just messes everything up.
I downloaded the normal one (still with MT enhancements though) and ALL errors disappeared. Someone should remove that from the first post.

[johnmeyer]

SetMTMode(3,6)
LoadPlugin("F:\Programy\Audio & video\MeGUI\tools\dgavcindex\DGAVCDecode.dll")
AVCSource("D:\Black Symphony\F1_T2_Video - .dga")
SetMTMode(2)Glad you have solved it, at least for now. I was a little puzzled by the SetMTMode(3,6) line prior to opening the video. Most scripts I've seen use SetMTMode(5,6). Mode 5 is, apparently, more compatible with frame requests and less likely to cause a problem. Perhaps your problem was indeed entirely due to the plugins you were using, but it also may be true that using the more usual mode for SetMTMode prior to reading the video frames might have solved the problem.

[Octo-puss]

I took the mode from the first post. It says 3... Checking help file from the package shows 5. I think I took what I thought was more recent info. This is confusing as hell.

[Taurus]

@Octo-puss
Which plugin package gave you headache?
The experimental for avisynth 2.6 or the modded MT optimized one?
Just had bad luck with the experimental version....

[Octo-puss]

Yup the experimental, which if I understand it correctly are the updated MT ones. I got couple more crashes but eventually found out I forgot to replace those in syswow64 folder as well. Trying again now, hopefully it will work.
I hope all of this will get an update soon.

[Octo-puss]

No way, avs4x264mod crashed anyway.

Also,
Useful MT modes:
1 - one filter instance per call in script, no guarding from Avisynth, only for filters that are designed for this mode, like distributor().
3 - one filter instance per call in script, Avisynth guards requests for output. The mode to use with source filters. (Mode 5 will do for them too, but is overkill and should be avoided.)
2 - each call in script produces N (number of threads) instances of filter. Use for the rest.

Taken from AVS MT thread. I guess this is why I picked mode 3 after all.

I think the other problem causing crashes is SetMemoryMax. I can't seem to find value that doesn't crash. I tried almost everything from 512 (they say that's default) to 1024 in 128MB increments.

[LigH]

Since I assumed the same (that Mode 3 is generally preferable), I discussed this already in the MT thread and learned that I was wrong believing that Mode 3 works equally well for all kinds of source filters. No, there is a difference. There are source filters which may require Mode 5 or even 6 or else might randomly fail (e.g. return bad frames), like DGDecNV (due to the required special handling of decoder hardware access).

After all, knowing which mode might be "best" (both reliable and not too slow) for a specific source filter may be a matter of experience. Even the version of the plugin might be an important factor, as you never can exclude "bugs" (or design flaws) which only appear in rare multi-threading situations. In case of AviSource, it may even be related to the specifically used VfW codec implementation (e.g. Microsoft or ffdshow decoder for ancient formats like Video1 or Cinepak).

In addition, there are functions which can reduce concurrent frame requests at the expense of some frame buffer RAM, like RequestLinear() in TIVTC.dll or Prefetch() in the MT kernel.

[Octo-puss]

What's the purpose of SetMTMode(2) after that though. I never really understood that. I thought commands are executed in the order they appear in script, so the first calling doesn't matter and the crashes happen after the second, when the deinterlacing is being done.

[LigH]

Using an MT mode >= 3 for source filters is recommended to avoid them running in several threads and one thread of the decoder receiving a request for frame B while another thread of the decoder is decoding the source for a previous request for frame A. Many decoders are not made to survive that.

Following filters, instead, should "in general" be able to apply filters to different parallel subsets of frames delivered by the source filter respectively any possibly existing previous filters in the filter chain. So after the source filter, MT Mode 2 should be safely useable (except for filters which are programmed in a bad style, e.g. use global variables, which may lead to data corruption in multi-threaded use).

Issues may arise when filters have a large temporal radius (need many frames before and after the current), and the stream of source frames is not contiguous (e.g. due to the use of Trims and Splices), here one thread may be ahead of the other and access frames distant to the current frame of other threads. Here the source filter may receive requests which lead to seeking forth and back in the video source file. Not all decoders are reliable under such circumstances, and many will be slow (because they have to decode again from the previous GOP start).

[Octo-puss]

I might as well wait a few months for something more stable to come out, really. I don't feel like experimenting with stuff that takes way over 24 hours to encode :D
But the problem really seem to be AVS.

[BeNooL]

Pro-tip: you can remux the partial output before a crash occurred.

- remux partial output with mkvmerge and cutoff 5-10Mb to get a clean cut
- get the number of frames
- trim original avs script of the same amount
- resume encoding of remainder part of video
(- repeat if new crash occurs)

Once you have all your parts, append them to each other in mkmerge. Voila.

That's how I dealt with some problematic video streams.