QTGMC Deinterlacing Script (v3.32)

[aegisofrime]

-Vit-: Just to clarify, ChromaNoise works without needing NoiseProcess to be enabled?

[-Vit-]

Originally Posted by aegisofrime

-Vit-: Just to clarify, ChromaNoise works without needing NoiseProcess to be enabled?

ChromaNoise is only relevant if NoiseProcess is non-zero. I'll clarify the docs again... :sigh:

[nhope]

Originally Posted by -Vit-

Yes with FPSDivisor=2 you can drop the SelectEven (I will make that clearer in the docs)

The answer to the first question is either both to 360 or both to 180. I would tend to suggest the latter, which is the default.

That question is one of the main reasons why I didn't use shutter speeds for the settings. In researching the shutter motion blur I found some confusion about shutter speeds when shooting interlaced material. Some suggest that a shutter speed matching the field rate (e.g. 1/50 shutter for 50i, also called "shutter off") implies a 360 degree shutter angle. However, I also found comment that the frame rate is relevant, in which case a 1/50 shutter speed on 50i footage implies a shutter angle of 180 degrees (film-like). There even seemed to be differences in how different cameras behaved with the same apparent settings. I have no opinion, this is not my area of expertise. So I went for shutter angle which is at least consistent if not the most widely known.

I would appreciate if anyone else can shed light on this one. If you shoot footage in this format, is the shutter effectively held open for 50% (180 degree) or 100% (360 degree) of the time between fields?

I asked the folk on the Sony Vegas forum and the general consensus is that 50i @ 1/50 or 60i @ 1/60 equates to a 180 degree shutter angle.

I've been doing some testing with it and it seems to be right. All just done single-threaded on my laptop. One thing I noticed was that the ShutterBlur setting didn't seem to make much difference to speed at all, so I left it at 3 for most tests. I didn't see much difference between using SBlurLimit or not on this particular clip. The table more or less speaks for itself:



I zipped up the 3 x 10 second tests I've highlighted in yellow and put them here if anyone is interested. Footage used with permission from Stringer (Gregory) on the Vegas forum. I would be interested to hear which people prefer.

By the way Vit, are you making a general recommendation for FPSDivisor=2 over SelectEven (which is currently in your "Getting Started" section)? I just want to be consistent with you in my guide.

[aegisofrime]

Originally Posted by -Vit-

ChromaNoise is only relevant if NoiseProcess is non-zero. I'll clarify the docs again... :sigh:

Sorry! I have read and re-read the Noise part of the docs and nowhere does it say that NoiseProcess has to be non-zero for ChromaNoise to work. If it's supposed to be obvious due to the nature of Chroma noise... Well it's lost on us newbie types who don't really understand the finer points of video

[-Vit-]

nhope: Thanks for the clarification that 180 degrees is the norm for shooting that kind of footage. Reading your thread over at Sony just confirms that there can be some confusion over shutter speeds. I'm going to stick with using shutter angle for the settings as it makes people think and/or ask rather than use the settings blindly...

The default setting for SBlurLimit should be OK for most sources, it's just an extra tweakable in case difficult motion is causing unwanted distortion/smearing. Similar with the higher shutter blur settings (2,3).
Edit: As noted in the docs, increasing those settings will likely reduce the level of blur a little from where it should be for the requested shutter angle. Looking at your motion blur samples - the 1/30s shutter version seems to have a little less blur than I would expect. I would stick to the (faster) ShutterBlur mode 1 and a lower SBlurLimit value (default is good). It doesn't harm to change ShutterAngleOut to get a bit more or less blur as you wish [The ideal would be to make some actual footage with known shutters and compare]. However, that particular footage is quite soft already and the motion is smooth, it doesn't benefit much from extra blur. I found motion blur works better on higher contrast video, with swift or sudden motion. It's also excellent for footage shot with a fast shutter, which really suffers when dropping to single rate.

You must use FPSDivisor if you're using shutter motion blur whilst cutting to single rate - it needs to know that information along with the shutter angles to calculate the correct amount to blur. If you're not using shutter motion blur it makes little difference whether you use SelectEven or FPSDivisor - whichever makes your tutorial easier.

[BTW: Ouch on those fps... Time to upgrade...]

____

Originally Posted by aegisofrime

Sorry! I have read and re-read the Noise part of the docs and nowhere does it say that NoiseProcess has to be non-zero for ChromaNoise to work. If it's supposed to be obvious due to the nature of Chroma noise... Well it's lost on us newbie types who don't really understand the finer points of video

I'm not sure which bit you were re-reading. Did you miss this bit?

Originally Posted by documentation

Important: You must use a non-zero value in one of EZDenoise, EZKeepGrain or NoiseProcess or no noise processing will occur

[aegisofrime]

Originally Posted by -Vit-

I'm not sure which bit you were re-reading. Did you miss this bit?

Ouch, I missed that. My fault

[Overdrive80]

Hi, thanks for your update.

This version throw an exception:



With version 3.20 doesnt pass me.

I do two scripts and run both, with rendering pass(lagarith).

1st script

DirectShowSource("E:\Pruebas Ghost Hound\16\F8_T2_Video - .mkv")

AssumeFPS(30000,1001)

QTGMC(preset="very fast" )

Selecteven()

threads=2

	x=(framecount()/threads)

	A=trim(0,x)
	B=trim(x+1,0)

	

return A

2nd script

DirectShowSource("E:\Pruebas Ghost Hound\16\F8_T2_Video - .mkv")

AssumeFPS(30000,1001)

QTGMC(preset="very fast" )

Selecteven()

threads=2

	x=(framecount()/threads)

	A=trim(0,x)
	B=trim(x+1,0)

	

return B

Any bug?

[-Vit-]

I have not seen an error like this before. Does it happen with preset "Faster" or "Ultra Fast"?

You could try this:

QTGMC( preset="very fast", SafeMode=true )

Or try making a second copy of your video to use in the second script.

[Overdrive80]

Originally Posted by -Vit-

I have not seen an error like this before. Does it happen with preset "Faster" or "Ultra Fast"?

You could try this:

QTGMC( preset="very fast", SafeMode=true )

Or try making a second copy of your video to use in the second script.

In safemode run fine but decrease speed process, around of 2 frames/second. Now, my process is of 2.30 hours before was of 1.50 hours, more or less.

[-Vit-]

The bug is in MVTools2. Make sure you have the latest version of MVTools2 and try again without SafeMode.

If it still crashes then this line will restore the behavior of the last version (3.2):

QTGMC( Preset="Very Fast", Overlap=16, SLMode=1, SrchClipPP=0 )

This is a problem in MVAnalyse when the Overlap is not 1/2 the Blocksize. It crashes sometimes. I added the SafeMode setting just for this problem, but I haven't actually seen it for a while. It had assumed it was fixed in more recent versions...

[Overdrive80]

I already installed last version MVtools. In fact, i don know that new features in this version, but in my case, deinterlaced bad in the same mode. Snapshots:

Version 3.20, preset very fast



New version, preset very fast

[-Vit-]

Final Edit (I hope): I can reproduce the MVTools crash, I'll look into that later.

However, I cannot reproduce the major ghosting shown in your images. Could you upload part of your source please?

[henryho_hk]

I also found some problem bobbing a 1080i source. The field order is correct as confirmed by separatefields(). But the motion jumps "backward" in some scenes. I am using Preset="Faster" and tr2=2. Setting EdiMode="Yadif" solves the problem.

[nhope]

Originally Posted by Overdrive80

This version throw an exception:
...
I do two scripts and run both, with rendering pass(lagarith).

You didn't change your Lagarith version by any chance? There were recent updates to it that caused some of us some problems.

[-Vit-]

henryho_hk: Try different source filters - I have often found that strange temporal effects are source filter related. Otherwise upload some source footage for me to test.

[henryho_hk]

It's ffvideosource() 2.15 over a MKV muxed from m2ts. I will try dss2() (i have ffdshow h264 decoder only, though).

[Overdrive80]

Originally Posted by nhope

You didn't change your Lagarith version by any chance? There were recent updates to it that caused some of us some problems.

Yes, I already installed lagarith 1.3.23. I dont think that could be for this reason.

@Vit. My source is 1080i@29.97. I upload a part of interlacing credits, compress in x264 @ 5000 Kb/s. If you need that upload in other format, only say me. ^^

http://www.megaupload.com/?d=ZJSXS36E

[-Vit-]

Overdrive80: The field parity needs to be reversed. This worked fine for me:

FFVideoSource( "E:\Video\Test\Original.mp4" )
ComplementParity()
QTGMC( Preset="Very Fast" )

Try "ComplementParity()" whenever you see "back & forward" jumping effects like this.

[Overdrive80]

Originally Posted by -Vit-

Overdrive80: The field parity needs to be reversed. This worked fine for me:

FFVideoSource( "E:\Video\Test\Original.mp4" )
ComplementParity()
QTGMC( Preset="Very Fast" )

Try "ComplementParity()" whenever you see "back & forward" jumping effects like this.

With this code, the ghost effect is gone.

My question is for curiosity... because is necesary add a filter for autodetecting dominant field but not with previous version?

[johnmeyer]

I am using a script based on Nick Hope's work. However, I have made it multithreaded. Everything works with the older version of QTGMC, but only with Very Fast. When I use Fast, I get problems. Here's the script:

#Script to deinterlace video based on QTGMC deinterlacing script
#Designed to produce 1280x720 progressive video

loadplugin("C:\Program Files\AviSynth 2.5\plugins\MVTools\mvtools2.dll")

#---------------------------
#Import("E:\Documents\My Videos\AVISynth Scripts\QTGMC3.20.avsi")  #older script
Import("E:\Documents\My Videos\AVISynth Scripts\QTGMC3.25.avsi")

#Serve out from Vegas in RGB24
SetMemoryMax(768)
SetMTMode(5,4)
AVISource("e:\frameserver.avi").assumetff().ConvertToYV12(interlaced=true,matrix="PC.709") #
SetMTMode(2)

LanczosResize(1280,height)

#---------------------------
QTGMC( Preset="Very Fast", FPSDivisor=2, EdiThreads=0, ShowSettings=false )
#QTGMC( Preset="Faster", FPSDivisor=2, EdiThreads=0, ShowSettings=false )

LanczosResize(width,720)
ColorYUV(levels="PC->TV")  #Scale levels from [0,255] to [16,235]. Compensates for Flash Player scaling [16,235] to [0,255].

I have tried four combinations in the above script (by changing which lines are commented out):

Script Version    Script Preset
QTGMC3.20.avsi    QTGMC( Preset="Very Fast" ... )
QTGMC3.20.avsi    QTGMC( Preset="Faster" ... )
QTGMC3.25.avsi    QTGMC( Preset="Very Fast" ... )
QTGMC3.25.avsi    QTGMC( Preset="Faster" ... )

The first combination is the only one that works without crashing, when tested using a 1440x1080 1,000 frame input file. I test by reading the script into VirtualDub and then doing a video analysis pass. This eliminates any small interaction that might be happening with an output codec.

I have tried changing the SetMemoryMax number and also tried changing the number of cores in the first SetMTMode, but all that does is change how long it takes before the crash happens. It usually takes about 200-500 frames before the crash begins (the fps counter drops for about a dozen frames prior to the crash).

For the third test listed above (your newest script with the Very Fast setting), here is the relevant line (I think) from the crashinfo.txt log:

Crash reason: Access Violation

Crash context:
An out-of-bounds memory access (access violation) occurred in module 'mvtools2'...

...reading address 247EF1D2.

I read your earlier post about needing to update to the latest MVTools2, so I download the latest release (2.5.11.1), but still had the problems.

Oh, and prior to the beginning of the crash, the newer script runs considerably slower, probably about 30% slower, with each of the settings.

Let me know if you need any other information.