QTGMC for film based?

[Atlantis]

First I have to say that I recently discovered QTGMC and I'm amazed by its simplicity and quality. I always had problems deinterlacing and now it's done perfectly and I'm not afraid by interlaced sources!

Next comes film based materials like my Frasier DVDs I'm trying to backup. It's a real mess. No matter what I use like inverse telecine, it seems impossible to go to 23.976. There is always a few frames here and there jumping or jerking.

Then I read Decomb manual and it says
One thing to be aware of is that you may not always want to decimate 30fps material. For example, if your clip is a hybrid of 3:2 progressive and normal interlaced video, if you decimate it you'll make the video portions jerky. Often with such clips it is better to leave them at their original frame rate by omitting Decimate().

I think I have to stay in 29.97 and forget decimate with these DVDs. That's the only smooth result with no jumping I get.

2 Questions.

1- Is there any complicated script like QTGMC that is easy and can do all itself with perfect results for film based material? It doesn't matter if it's slow like QTGMC.

2- Imagine that I have to keep my shows in 29.97. Should I inverse telecine or use QTGMC? I used it and it gave a very smooth and nice result. What does QTGMC do on film based source? Does it simply consider it interlaced and I lose details or is it smarter and do some kind of inverse telecine?

[johnmeyer]

Everyone does things differently. For me, I would not choose QTGMC if all I needed to do was IVTC. I do IVTC quite frequently and have had great success with:

TIVTC (http://forum.doom9.org/showthread.php?t=82264&highlight=tivtc)

For movies stored on videotape or DVD in telecined format, this is often all you need:

tfm(display=false)
tdecimate()

While it is true that some material, such as documentaries, often have a mix of telecined film and video, most Hollywood style movies are generally 100% film cadence.

I think there is another plugin that many users on this forum prefer over TIVTC, and hopefully one of them will mention that alternative.

[Guest]

@Atlantis

For best help please post a link to an unprocessed source stream sample.

[Atlantis]

I was hoping for an easy solution like QTGMC that would fit all where you don't need to provide a sample, where you don't need to inspect the video closely.

[ajk]

Well, even with QTGMC() you have various quality levels to choose from. But if you just want to keep a backup of the DVDs, why not just copy the .vobs over or make complete .iso images of the discs?

[Overdrive80]

You can use:

QTGMC( Preset="Slower", SubPel=2, Sourcematch=3, Lossless=2).assumefps(60000,1001)
srestore(24000.0/1001.0)

[Atlantis]

Thanks Overdrive80. I am trying your script now. It's real slow at 2.5 FPS but if it gives great result I will be happy. I will let you know in 4 hours.

I don't want to watch the original vobs because they are interlaced. I prefer progressive material.

[johnmeyer]

I was hoping for an easy solution like QTGMC that would fit all where you don't need to provide a sample, where you don't need to inspect the video closely.Did you try the solution I posted? It does IVTC and does it MUCH faster than 2.5 fps.

[poisondeathray]

But if your description was accurate (a mix of film and video) , it will still be choppy with that script

Having a single 24 fps frame rate means video sections will be choppy due to missing frames.

Having a single 30 fps frame rate means most of it will be have slight choppiness (24p sections in 30p means every 5,6th frame repeated) .

Leaving it at 60 fps mean 24fps sections have the "normal" 3:2 judder on a 60Hz display, but 30fps sections will look ok because they are evenly spaced in time

The other option is to make it VFR. 24fps sections play properly at 24fps. 30fps sections play properly at 30fps.

[Atlantis]

Here are results:

Finished Overdrive80 script. The result is not good. It's actually the worst result that I have gotten so far. The individual frames look good but it plays jerky with jumps at 23.976 fps.

@johnmeyer. Yes I did try tfm. As I said in my original post, I did try all kind of inverse telecine. I tried all the options available in MEGUI partially interlaced partially film and more.

As I said I do get good results with tfm or decomb at 29.97fps. All the problem comes from decimate. If I try to convert that smooth progressive 29.97 result to 23.976, I get bad slight jumps here and there. I get only smooth motion at 29.97 fps.

Source as I said is Frasier (Season 3 to be exact) and the 5-6 seconds of the beginning title must have been created on video but the show is recorded on film for sure. I'm not even talking about the title sequence, just the main body of the show, the part that is recorded on film, doesn't run smooth at 23.976.

Where can I upload a sample for you guys? What site do you recommend?

[johnmeyer]

Mediafire

[Atlantis]

Here is an original untouched sample:

http://www.mediafire.com/download/p3ojhaqapb31qn2/test.mkv

[Overdrive80]

Here are results:

Finished Overdrive80 script. The result is not good. It's actually the worst result that I have gotten so far. The individual frames look good but it plays jerky with jumps at 23.976 fps.

In this case, you can use:

QTGMC( Preset="Slower", SubPel=2, Sourcematch=3, Lossless=2).assumefps(30000,1001)

You get double-framecount at 30fps, a big file but I think without jerkiness.

Or like says poyson, should use VFR.

[Atlantis]

Not working. The result is in slow motion. I posted the original file, please check on it.

[poisondeathray]

The only video section in that sample is the title sequence (the animated graphics) . The rest is film . Unless you cut the wrong sample, I don't see the problem

[Atlantis]

The only video section in that sample is the title sequence (the animated graphics) . The rest is film . Unless you cut the wrong sample, I don't see the problem

I know. You will see the problem if you do it yourself. Try to get a smooth 23.976 fps playback from that. I posted exactly the problematic part. I'm not even talking about the title sequence. I consider it doesn't exist. Just try to get a 23.976 file from that sample I posted and you will see. The title sequence is not the problem, it's the rest!

[poisondeathray]

I know. You will see the problem if you do it yourself. Try to get a smooth 23.976 fps playback from that. I posted exactly the problematic part. I'm not even talking about the title sequence. I consider it doesn't exist. Just try to get a 23.976 file from that sample I posted and you will see. The title sequence is not the problem, it's the rest!


It's fine here, frame by frame. You can tell right away when looking at the fields, it's a perfect 3:2 . Ignoring the title sequence, the only problem might be the last frame in your sample (but that might be the way you cut the sample)

Index with "honor pulldown flags"

Mpeg2Source()
AssumeTFF()
TFM()
TDecimate()

I can post an encode if you don't believe me

Script as above, title sequence trimmed off
https://www.mediafire.com/?cc53u5u2b8978dj

[Atlantis]

Thanks for taking your time. I watched your clip and it's perfect. That's what I want but I am unable to get that result. I used what you said

LoadPlugin("xxxxxxxxx\MeGUI\tools\ffms\ffms2.dll")
FFVideoSource("xxxxxxxxxx\test\test.mkv", fpsnum=30000, fpsden=1001, threads=1)
LoadPlugin("xxxxxxxxxxxxxx\MeGUI\tools\avisynth_plugin\TIVTC.dll")

AssumeTFF()
TFM()
TDecimate()

Strange I don't get the same result as you with this script. I can only think of 2 things. Either ffms2 messes things up, or because I do it from the beginning that includes the titles, it messes the rest up.

Could you please try again and do the whole clip? Please don't trim anything.

[turbojet]

Interesting dgindex+tivtc handles it but not tivtc itself. Never seen that. It's also mostly film so you can speed it up using tfm's d2v parameter.

This is the steps I took:
1. demux mkv with mkvextractgui2 (http://sourceforge.net/projects/mkvextractgui-2/)
2. dgindex the mpg file with output>honor pulldown
3. used this avsmpeg2source("test.d2v")
TFM(d2v="test.d2v")
TDecimate()
autocrop(0,threshold=20,hMultOf=4)
4. encode

While some use assumetff/bff before tivtc, I never saw the use as tivtc auto detects it but maybe it's a safety valve.

[Atlantis]

Ok I did more tests and I found the problem. The problem is with ffms2/FFVideoSource. FFMSIndex is buggy and I had many problems with it. I also had a lossless UT Video file and when opened with FFVideoSource, it gives jumpy encodes. I'm going to avoid FFMSIndex from now on.

Could you please try and index the MKV file with FFMSIndex and then encode? Can you replicate the bug? use my script above.

When I use
LoadPlugin("xxxxxx\MeGUI\tools\dgindex\DGDecode.dll")
DGDecode_mpeg2source("xxxxxxxx\test\test_track1_eng.d2v")
all is good.

[Atlantis]

I did not write that line. MeGUI file indexer created it. So I used this instead
FFVideoSource("test.mkv", rffmode = 1, threads=1)

And now it works correctly with FFVideoSource too.

1- How can I make MeGUI use FFVideoSource correctly? I'm going to batch encode.

2- And also since you seem an expert at FFMSIndex, do you have any idea why my Ut Video 23.976 fps is jumpy when encoded? No processing is done. Only import.

[Atlantis]

No I don't want to use FFMSIndex. When I open the mkv file in MeGUI file indexer, DGIndex is disabled, it's grayed. Zathor said this should be fixed in build 2439, so I am using MeGUI 2467 and DGIndex still disabled when I use that MKV.

Please open test.mkv in MeGUI file indexer and see what happens.

http://forum.doom9.org/showthread.php?t=170118

[Atlantis]

Oh ok. I didn't know that DGIndex can't directly open mkv. So that's why it's grayed.

I will extract my streams from my MKVs before I open them then. It will be an extra step but it's better that the MeGUI indexer open the file correctly without you having to manually edit the avs file.

[poisondeathray]

Why don't you rip the DVD's as VOB's ? That's the native DVD format, not MKV container. They open directly in DGIndex

[Atlantis]

What I like about MakeMKV is that I rip all the videos present on the DVD as individual files. I can quickly watch them and delete the unwanted stuff and keep the things I want to encode as separate files.
I also want the chapter lists.

What software do you suggest to rip them as VOB? And is it possible to rip each episode/video as a single file?

[Groucho2004]

What I like about MakeMKV is that I rip all the videos present on the DVD as individual files.
You can do the same with DVD Shrink. It creates a new DVD structure but you can just grab the VOBs and use them in DGIndex.

[Atlantis]

Is there anyway I can add the name of the file in here?
tfm(d2v=filename)

By use of MeGUI avisynth profiles.
http://forum.doom9.org/showthread.php?t=112496

I want to use it in one click encoder. The only variables I see are
<input>
<deinterlace>
<crop>
<resize>
<denoise>

[sajara]

Would you care to test your clip? I've encoded directly from the Mkv.
I can't see any visual artifacts on my system.

http://www.mediafire.com/?rkmkl0g57i569y8

# Set DAR in encoder to 6480 : 4739. The following line is for automatic signalling
global MeGUI_darx = 6480
global MeGUI_dary = 4739
LoadPlugin("G:\Documents\1_Downloads\1_Video Tools\Encoders Frontends\MeGUI_2153_x86\tools\ffms\ffms2.dll")
FFVideoSource("D:\Documents\Downloads\test.mkv", cachefile="D:\Documents\Videos\Video Rendered\test.mkv.ffindex", fpsnum=30000, fpsden=1001, threads=1)
LoadPlugin("G:\Documents\1_Downloads\1_Video Tools\Encoders Frontends\MeGUI_2153_x86\tools\avisynth_plugin\TIVTC.dll")
TDecimate(cycleR=1)
#crop
#resize
#denoise

[Mole]

You can use SmartRipper to open the VIDEO_TS folder and in movie mode, you'll be able to select exactly the title you want, then in Stream Processing tab, select "Demux to extra file" for both video and audio.

[Atlantis]

So after much learning, I'm using this script to get best results.

LoadPlugin("xxx\MeGUI\tools\dgindex\DGDecode.dll")
LoadPlugin("xxx\MeGUI\tools\avisynth_plugin\TIVTC.dll")

myvideo = "video.d2v"

DGDecode_mpeg2source(myvideo)

deint = QTGMC( Preset="Slow" ).SelectEven()

tfm(d2v=myvideo, ovr="Video_tivtc_over.txt", clip2=deint)
tdecimate(hybrid=1)

However I have a problem with QTGMC. As you see in the picture attached, QTGMC deinterlaces a lot better than the tfm deinterlacer except in one case.

As you see when a credit changes to a new one, I still see a ghost of the old credit. I don't see that ghost with tfm deinterlacer. What options in QTGMC I can use to avoid it?

Top image is tfm default deinterlacer and bottom is QTGMC as it's in my script.

http://i61.tinypic.com/2j1jygz.jpg

[ChiDragon]

There is a "ghost" in the TFM image as well (instead of smeared letters, there's a grey tint in the same area). You should probably upload a sample of the source for that scene.

[Atlantis]

Here:
http://www.mediafire.com/download/88bb54uzxod40db/QTGMC%20Ghosting%20Letters.mkv

Just apply normal QTGMC and see the frame around 10 secs.
Right after Creative Consultant David Lloyd

[ChiDragon]

If you view with just Bob() you can see it's a problem with the DVD itself. Three of the credits jump back to the previous name for 1 field. That probably screws up QTGMC's motion compensation.

[Atlantis]

Anything I can do about it?

[poisondeathray]

Anything I can do about it?

The "T" in QTGMC or TGMC is temporal. So probably not within QTGMC unless you really dumb down the settings

So your options are use another intraframe deinterlacer for tfm clip2 , maybe nnedi3 (maybe mix and match and use only on those problem frames, QTGMC for the rest)

Or fix the fields - since even if you re-order, there is some smearing in those fields in the first place. Maybe some photoshop/AE, overlay compositing

[hello_hello]

Atlantis,
If you've still got DVD video in MKVs to convert, you can remux the MKVs as TS files with tsmuxer. DGIndex should be able to index those.

Maybe I'm missing the obvious, but is QTGMC's de-interlacing the best option for IVTC? If I'm converting "film", I use a standard IVTC, and if the video is ugly (noisy, poor quality etc) then after IVTC I'd use QTGMC in progressive mode. Usually with a little noise filtering. So the script would end up looking something like this and the output would be 23.976fps.

LoadPlugin("C:\Program Files\MeGUI\tools\avisynth_plugin\TIVTC.dll")
tfm(order=1).tdecimate(hybrid=1)
QTGMC(InputType=1, EzDenoise=2.0)

There's three progressive modes. InputType=1, InputType=2 and InputType=3. The QTGMC html help file explains the differences.

If I was encoding the video, based on the little sample you uploaded, I'd apply IVTC then use QTGMC in progressive mode if I decided the video quality could be improved.
I tried the script Overdrive80 originally posted and thought it did a pretty good job. In fact I'll be keeping it in mind if ever I need to encode video which is a big mix of NTSC and film. The difference between IVTC+QTGMC in progressive mode and QTGMC+srestore wasn't all that great. I don't know why, but I expected the output to look a lot different. ITVC+QTGMC was maybe a fraction sharper and I think motion looked a little better, but it's something you'd probably not notice when watching the video in the usual manner and only when comparing individual frames.

My aim would be to output 29.970 only as a last resort. Mainly because I live in PAL land, and instead of changing the TV's refresh rate I leave it at 50hz and use Reclock to play everything at 25fps (kind of like having a PAL film mode")... except for 29.970fps video. Plus if a TV has a "Film mode", don't they generally only work in film mode if the frame rate is 24fps.... and also I'd assume, if it's 23.976fps.

[poisondeathray]

Maybe I'm missing the obvious, but is QTGMC's de-interlacing the best option for IVTC? If I'm converting "film", I use a standard IVTC, and if the video is ugly (noisy, poor quality etc) then after IVTC I'd use QTGMC in progressive mode. Usually with a little noise filtering. So the script would end up looking something like this and the output would be 23.976fps.



TFM uses something almost equivalent to "bob" with the default PP mode when combing is detected.

The whole video isn't deinterlaced when you specify clip2 in TFM (ie. TFM(clip2=xxx) ) - only those affected frames where combing is detected after field matching. QTGMC usually gives better results in most situations compared to the default bob

[hello_hello]

So as a general rule, what sort of percentage of frames would need to be de-interlaced? I understand what you're saying, but if QTGMC is only effectively de-interlacing the occasional frame, wouldn't that be an argument for using IVTC and QTGMC in progressive mode?

The way I read the TFM help file, clip2 is for "specifying an externally deinterlaced clip from which TFM will take frames instead of doing the deinterlacing itself". I'm not 100% sure, but the info describing the "PP" function seems to imply de-interlacing is only used when combing is detected anyway.

PP -
Sets the post-processing mode. This controls how TFM should handle (or not handle) any combed frames that come out of the field matching process.

[manono]

So as a general rule, what sort of percentage of frames would need to be de-interlaced?
Often zero percent, especially if you take the time to tweak the threshold. It sometimes deinterlaces frames that are matched well, if using the default settings. Even so, though, when using QTGMC as the post-processor you usually can't tell. In any event, it shouldn't be very many needing deinterlacing, and if there are it often means it's blended or otherwise not fit for an IVTC to begin with. TFM isn't meant to be used as a general deinterlacer. Put on 'Display=True' if you want to see what gets deinterlaced:

TFM(Display=True)
...wouldn't that be an argument for using IVTC and QTGMC in progressive mode?

I don't understand the rationale behind that question. QTGMC(InputType=1/2/3) is for something different than general deinterlacing or even as a post-processor for TFM. One of its side effects is a softening of the picture.

I'm not 100% sure, but the info describing the "PP" function seems to imply de-interlacing is only used when combing is detected anyway.
That's correct. When detected after the field-matching is complete.

[hello_hello]

I don't understand the rationale behind that question. QTGMC(InputType=1/2/3) is for something different than general deinterlacing or even as a post-processor for TFM. One of its side effects is a softening of the picture.

The original poster asked about using QTGMC for "film". My suggestion.... if he wanted to use QTGMC to "clean up" the video.... was to IVTC first followed by QTGMC in progressive mode. Maybe if the video in question was a fair mix of film and NTSC, using QTGMC to de-interlace would make sense, but when the video in question is all 23.976 (after IVTC) it didn't seem logical to de-interlace (all of) it.

I wouldn't use QTGMC in progressive mode just for the sake of it. Originally I assumed the source video must be noisy or low quality, but if that's not the case I'd probably just use TIVTC. I do use QTGMC in progressive mode as a pseudo noise filter quite a bit though. Because it stabilises the picture for light noise that's often enough. For heavier noise I enable QTGMC's noise removal and specify an appropriate amount. It does a better job than any other noise filter I've tried. For heavier noise the TemporalDegrain script does a very similar job, but it doesn't fix "shimmering" caused by (original) de-interlacing as well as QTGMC does.

I still have an NTSC DVD on my hard drive which required IVTC. I might play around with it later to see which frames were de-interlaced and whether QTGMC de-interlacing those frames makes much difference. Encoding that DVD was a time I used QTGMC in progressive mode after TIVTC, as the video was fairly noisy and not particularly high quality.
Originally MeGUI wanted to use "force film" for that one, but it left some frames which appeared to need de-interlacing in places. After a lot of messing around trying to discover why IVTC wouldn't fix it, I eventually disabled force film, re-indexed and the result was fine. The combing in places disappeared.

Thinking about it.... if MeGUI is using "force film" when the index file is created, maybe that's why Atlantis is having a problem with the end credits? If DGDecode is outputting progressive video I'd assume all the IVTCing and QTGMCing in the world wouldn't be able to fix it. In fact if force film is being used, wouldn't adding IVTC to a script or QTGMC de-interlacing be at best a complete waste of time? Just a thought.

[hello_hello]

Well using TFM(Display=True) proved educational for me. There's nothing in the two samples the original poster uploaded which requires clever de-interlacing. Just the odd combing detected in a few frames during the opening graphics and the production logo at the end. That's about it. It would appear using QTGMC to de-interlace where combing was detected would be a fair waste of time.

I also tried the DVD I mentioned in my previous post. I didn't find a single frame where combing was detected. Not even in the places where I saw it when "force film" was used. I'm not sure why force film caused combing when TIVTC doesn't. I assume it must be due to the field matching TFM does.

When it came to the credits Atlantis was having a problem with.....
I said in my previous post using IVTC works perfectly, but I've deleted that part because it appears I was wrong. DGIndex and ffms result in a slightly different number of frames after indexing and I think ffms is getting it wrong. When DGIndex is indexing I can see the "ghosting" credit. Maybe when DGIndex is indexing the frame in question isn't missing...

[Atlantis]

Personally I'm never going to use ffms again with any mpeg or avi sources. Lots of problems with ffms.

I did think about muxing the MKVs into ts but unfortunately ts doesn't support chapters, is that right? If TS doesn't support chapters, it makes no sense to mux them into TS and keep a separate chapter file. It's easier for me just to extract all tracks and delete the original MKV.

I do find using QTGMC with tfm very helpful as I wrote in my script, its superior to what I get from different pp options in tfm. I tried all the pp options and QTGMC is better and not a waste of time at all. It's also not that slow because only combed frames use QTGMC at a slower framerate and they are not that much.

[Atlantis]

Funny there was an episode of Frasier that I couldn't get a good result with tfm, episode 210. tfm kind of correctly assembled the progressive frames but every few seconds it had some little combed regions around faces or hands. It was impossible for me to go and put all the frames in a tfm overfile because they were so many from start to end.

What I did was I passed the entire clip through QTGMC and got a 29.97 progressive clip. Then I passed that through tdecimate(). Surprisingly I got a very good 23.976 clip. With nice and smooth speed and no combed artifacts.

However I find it a little softer than if I had used tfm. In general does QTGMC make the source a little less sharp?

[hello_hello]

Personally I'm never going to use ffms again with any mpeg or avi sources. Lots of problems with ffms.

It does seem to be somewhat "unpredictable" when it comes to mpeg2 video. I can't say I've had much problem indexing AVIs, although it tends not to cope when the audio stream contains junk data and won't index it.
As a general rule I remux most stuff as MKV before opening it with MeGUI as that way MeGUI can extract the audio while indexing. Except for mpeg2 video, of course.
For the record, when you tell MeGUI's File Indexer to extract the audio from MKVs it uses a command line for indexing which also (unnecessarily) gets ffms to index all the audio streams. That can increase the indexing time considerably. After pointing it out to Zathor he's changing the behaviour for the next MeGUI version.

I do find using QTGMC with tfm very helpful as I wrote in my script, its superior to what I get from different pp options in tfm. I tried all the pp options and QTGMC is better and not a waste of time at all. It's also not that slow because only combed frames use QTGMC at a slower framerate and they are not that much.

That's what I meant. If QTGMC is used only for the frames where combing is detected and there's virtually none of those, QTGMC wouldn't actually be doing anything.
Take your first sample file as an example. I used it to create an OVR file and had a look at the result. The way I understand it, by default the MI value needs to exceed 80 for a frame to be considered combed and therefore de-interlaced. For your sample that's only around 150 frames near the beginning, which is the opening graphic. I think that's NTSC, not "film" but being the type of graphic it is I can't imagine QTGMC de-interlacing would look any different to TFM's de-interlacing, and if the output frame rate is 23.976 then it'll probably look a little less smooth regardless of how it's de-interlaced.
After the opening graphic, there's not a single frame which is even close to the threshold for de-interlacing. The highest MI value listed is 15. Most frames have values of 0, 1 or 2. I strongly suspect that'd apply to the entire video, with possibly the section at the end where the closing credits appear, but they're not "normal" so are probably somewhat of an exception. The video behind the credits isn't combed, it's just the credits themselves which are a little "odd".

Funny there was an episode of Frasier that I couldn't get a good result with tfm, episode 210. tfm kind of correctly assembled the progressive frames but every few seconds it had some little combed regions around faces or hands. It was impossible for me to go and put all the frames in a tfm overfile because they were so many from start to end.

Out of curiosity, is MeGUI set to use "force film" when it indexes?
Although if you managed a final output of 29.970fps, I guess that's not the reason.

There must be a way to reduce the threshold so de-interlacing is more likely to be used.

What I did was I passed the entire clip through QTGMC and got a 29.97 progressive clip. Then I passed that through tdecimate(). Surprisingly I got a very good 23.976 clip. With nice and smooth speed and no combed artifacts.

Alternatively, there's probably an easy way to produce an OVR file which results in every frame being de-interlaced after TIVTC. If so, maybe it wouldn't produce the softening effect you noticed, or maybe not to the same degree.
If manono returns he'll probably be able to contribute some cleverness. I live in PAL land myself so I'm not overly experienced when it comes to the oddness referred to as NTSC. ;)

However I find it a little softer than if I had used tfm. In general does QTGMC make the source a little less sharp?

I don't think QTGMC is supposed to be used for a pseudo IVTC, so it's possibly why it appears to soften the video a little.
When it comes to video which is actually interlaced, I find if anything QTGMC tends to have a very mild sharpening effect, although maybe that's because it's de-interlacing removes noise and stabilises the picture which makes it look a tad sharper.

If you have the motivation to try it, maybe try encoding the episode in question again using TIVTC without QTGMC de-interlacing, followed by QTGMC in progressive mode. You could try either InputType=1 or InputType=2. I'd be quite interested to learn if the combing effect is reduced or fixed that way, and whether it'd soften the video as much as simply using QTGMC to de-interlace. I suspect it won't.
Or if you wouldn't mind uploading a small sample of the original video which results in combing after TIVTC, I'd be happy to try it myself.

I find QTGMC in progressive mode doesn't soften much, if at all, at least when InputType=1 is used. I wouldn't run it on "clean" video anyway, but for video which isn't very stable (shimmering effects cause by bad de-interlacing etc) it can definitely have a sharpening effect. InputType=2 and InputType=3 have more potential to soften a bit as they discard half the fields and use the remaining ones to re-create interlaced video which is then de-interlaced in the normal way.... or something like that.
Mind you if I'm using QTGMC in progressive mode, the chances I'll be doing so with it's EzDenoise function enabled would increase by a considerable amount, and any noise filtering will probably soften a bit. One of the reasons I use QTGMC as a noise filter that way is it's noise removal to softening ratio is far greater than any other noise filtering I've tried. With maybe the exception of the TemporalDegrain script. It's default settings blur a little but they also remove a considerable amount of noise. QTGMC(InputType=1, EzDenoise=5).... or an EzDenoise value between 4 and 6.... tends to do a fairly similar job.
Check out these sample encodes. They were part of my own little Avisynth filter, picture stabilisation, noise removal torture test. :)
http://forum.videohelp.com/threads/358043-A-comparison-of-AVIsynth-denoise-filters?p=2283228&viewfull=1#post2283228
There's a larger range of comparison encodes attached to the first post. I was only just starting to play around with using QTGMC as a noise filter then. These days, I'd probably put QTGMC's EzDenoise function to a little more use.

[Stereodude]

When it comes to video which is actually interlaced, I find if anything QTGMC tends to have a very mild sharpening effect, although maybe that's because it's de-interlacing removes noise and stabilises the picture which makes it look a tad sharper.That's because the default setting is sharpening of 1.0. IMHO, it ends up sharpening the image in an undesirable fashion.

[Stereodude]

In general does QTGMC make the source a little less sharp?In my experience it does not. It has the opposite effect and excessively sharpens the image.

[hello_hello]

That's because the default setting is sharpening of 1.0. IMHO, it ends up sharpening the image in an undesirable fashion.

I'll confess I tend to use QTGMC's de-interlacing with the sharpening reduced a little, but I do find the difference to be fairly subtle. Maybe something like:

QTGMC(sharpness=0.7)

Often when de-interlacing PAL, which for me has a fair tendency to be in the form of 4:3 DVD video, I'd reduce the resolution. 640x480 wouldn't be unusual. So I guess by the time the video is resized down and then upscaled to 1080p on playback, a little sharpening when encoding probably doesn't hurt.

I tend to dislike most sharpening. I've tried all sorts of sharpening filters. SeeSaw probably produces an output which offends me the least.... in combination with appropriate de-noising.... but even then it's not something I'd use much.
For reasons I don't quite understand, I tend to find any sharpening which results from QTGMC's de-interlacing fairly unoffensive (Is it unoffensive or inoffensive? My spell checker seems to be of the opinion it's the latter). As far as sharpening goes, it seems to look fairly "natural" to me.... for want of a better description.

[poisondeathray]

It's the combination of denoising and over sharpening that gives the "plasticky doll" look that is offensive to many people

[Stereodude]

It's the combination of denoising and over sharpening that gives the "plasticky doll" look that is offensive to many peopleYou got that right with the plasticky part. I use it with a sharpness of .2 and I don't use it's denoising. MCTD is much better at noise reduction.

[hello_hello]

You got that right with the plasticky part. I use it with a sharpness of .2 and I don't use it's denoising. MCTD is much better at noise reduction.

Some question, if you don't mind......

I hadn't tried MCTD before, nor for that matter MCTDMod, so I gave them both a spin (I wasn't sure which you were referring to). For each test encode they both resulted in almost identical file sizes. Is there a significant difference between the two I'm not seeing yet?

For the noisy source I used the videos I linked to in an earlier post. One of them is the definition of horrible quality, the other 720p and not low quality as such, just noisy.
I ran MCTD using the default settings. Comparing it to QTGMC's EzDenoise function (progressive mode), "better at noise reduction" seems to be eluding me so far. I might need to start out aiming for "as good" to begin with.....

Anyway.... I'm happy to play around with MCTD's settings if need be, so if you have any suggestions.....

Cheers.

[Stereodude]

I hadn't tried MCTD before, nor for that matter MCTDMod, so I gave them both a spin (I wasn't sure which you were referring to). For each test encode they both resulted in almost identical file sizes. Is there a significant difference between the two I'm not seeing yet?I was referring to MCTemporalDenoise. When you say "two" are you referring to MCTemporalDenoise and QTGMC or MCTemporalDenoise and MCTemporalDenoiseMod?

FWIW, I wasn't referring to file size, but visual appearance.
For the noisy source I used the videos I linked to in an earlier post. One of them is the definition of horrible quality, the other 720p and not low quality as such, just noisy.
I ran MCTD using the default settings. Comparing it to QTGMC's EzDenoise function (progressive mode), "better at noise reduction" seems to be eluding me so far. I might need to start out aiming for "as good" to begin with.....If you're bored, start with the Blu-Ray of Moneyball and compare QTGMC to MCTemporalDenoise.

My typical setting is MCTemporalDenoise(settings="low", radius=3), if the video is really noisy like the aforementioned Moneyball I will use MCTemporalDenoise(settings="medium"). If I want something in between "low" and "medium" I use this:
MCTemporalDenoise(settings="low", radius=3, sigma=6, SHmode=3, useEEDI2=false, \
quant1=30, quant2=60, ECrad=4, ECmode="Removegrain(3,-1)", maxr=3, TTstr=2, \
GFthr=1.6, thSAD=400, thSAD2=400, thSCD1=400)

Don't get me wrong. I still use QTGMC. I use it on nearly all content that started out in interlaced 1080i mpeg-2 files. Even things that I IVTC or that were progressive encoded as interlaced. Interlaced MPEG-2 artifacts survive otherwise and setting QTGMC to any of the progressive settings like InputType=1 or InputType=2 doesn't get the job done in my experience. So, I generally use this combination:

QTGMC( Preset="Medium", InputType=0, Sharpness=0.2, ShowSettings=false ).SelectEven()
MCTemporalDenoise(settings="low", radius=3)

[Atlantis]

Or if you wouldn't mind uploading a small sample of the original video which results in combing after TIVTC, I'd be happy to try it myself.
Here it is. I call it the episode from hell. :devil: Try a normal tfm on it.

https://www.mediafire.com/?btumea3vep38crh

[Atlantis]

Strange.

I am using tdecimate(hybrid=1) which works great for the opening titles which are detected combed.

However I have noticed in the show where a scene change is a ghost. Half of previous scene and half of the next scene ghosted together. This behavior is normal when the 2 scenes are detected combed because of hybrid=1 option.

However these 2 shots blended together are reported Clean Frame by tfm and they are not combed. When I use tfm only, the transition is clean. When I add the tdecimate(hybrid=1), the transition is a half-half ghost frame. Why?

Shouldn't hybrid=1 affect only frames detected as combed?

[Stereodude]

Here it is. I call it the episode from hell. :devil: Try a normal tfm on it.

https://www.mediafire.com/?btumea3vep38crhI'll try it when I get home from work.

[Stereodude]

Shouldn't hybrid=1 affect only frames detected as combed?Not according to the documentation. It's blend decimation of 30p sections into 24p. If tdecimate thinks it's a video section (perhaps caused by the lack of a repeated frame in a sequence of 5 frames) it's going to do something with it.
Here it is. I call it the episode from hell. :devil: Try a normal tfm on it.This is pretty easily handled by this:
QTGMC( Preset="Medium", InputType=0, Sharpness=0.2, ProgSADMask=10, ShowSettings=false )
SRestore(frate=23.976)

[Atlantis]

This is pretty easily handled by this
Yes that is kind of what I did. tfm fails there.

What's the difference between SRestore and tdecimate? I used tdecimate.

[Atlantis]

Not according to the documentation. It's blend decimation of 30p sections into 24p. If tdecimate thinks it's a video section (perhaps caused by the lack of a repeated frame in a sequence of 5 frames) it's going to do something with it.
I always thought that tfm tells tdecimate what is combed and what is not.

When tdecimate gets the footage it's already deinterlaced and if tdecimate decides alone on its own if something is video or not, that's not good I think. I have to stop using hybrid=1 in that case despite of not using it makes the opening credits jumpy.

Any documentation on how tdecimate marks a section as video 30p?

[Stereodude]

What's the difference between SRestore and tdecimate? I used tdecimate.SRestore is a deblender. tdecimate looks for duplicated frames.

[Atlantis]

This is pretty easily handled by this:
QTGMC( Preset="Medium", InputType=0, Sharpness=0.2, ProgSADMask=10, ShowSettings=false )
SRestore(frate=23.976)
According to the manual ProgSADMask only applies to InputType=2,3.

[Stereodude]

According to the manual ProgSADMask only applies to InputType=2,3.Well you can delete it if it bothers you having an unused parameter there.

[Atlantis]

I finally did it! Found the "perfect" solution. What I was looking for all along. Something that you would set and forget. This is the script I tested and use now.

myvideo = "video.d2v"
DGDecode_mpeg2source(myvideo)

deint = QTGMC( Preset="Slower" ).SelectEven()
tfm(d2v=myvideo, clip2=deint)

QTGMC( Preset="Slower", InputType=2, ProgSADMask=12.0 )

tdecimate()

This way I don't need to set an overfile and go frame by frame finding bad frames.

By the way, I tried your script but it's too soft and you lose lots of details. The script above retains more details.

[Stereodude]

By soft I think you mean not artificially sharpened, but to each their own...

[Atlantis]

No, you are wrong. By soft I don't mean not artificially sharpened. By soft I mean you lose lots of detail with your script. Using QTGMC like that on the first step makes you lose lots of stuff. Can never come close to using tfm.

[Atlantis]

In this picture attached, on the top is your script and the bottom is mine.

[poisondeathray]

Did you give vinverse a shot ? It's more gentle for residual combing than QTGMC in progressive mode, not to mention much faster

And if you still wanted to use QTGMC in prog mode, wouldn't it make more sense to put it after TDecimate ? (Not only faster because fewer frames, but more accurate because no duplicates every 5th)

Did you want to do something about those rainbows too ?

[Atlantis]

Thanks a lot poisondeathray. No I didn't know vinverse and tried it. Not only it's faster, it retains more details. I revised my script to


myvideo = "video.d2v"
DGDecode_mpeg2source(myvideo)

deint = QTGMC( Preset="Slower" ).SelectEven()
tfm(d2v=myvideo, clip2=deint)
tdecimate()

vinverse()

[hello_hello]

I had a bit of a play with your sample but didn't come up with any particular form of cleverness. I'm definitely no NTSC expert but I'm not sure your sample is a sample of "normal".

It's the first time I've played around with TIVTC settings to any extent. I thought/hoped it'd be a simple case of lowering the detection level in order for the frames in question to be detected as combed. Which it seemed to be initially. The default MI threshold is 80. It's easy enough to use the "MI=?" setting to change it, but that's when things I don't understand began to happen.

Most of the frames where I could see combing in places had quite low MI values according to TFM. 15 or less in most cases. When using the display function so TFM would show me where in the frame it was detecting combing, it was never where I could see it. So I could see something which at least looked like combing but TFM wasn't detecting it as such. That, I don't understand.

From there I tried specifying a very low MI value, thinking that'd cause the frame to be de-interlaced even if TFM and I weren't in agreement as to where it needed it. A PP value less than 5 combined with clip2 appeared to be the requirement for de-interlacing the entire frame, and while it seemed to be "working" it didn't appear to be de-interlacing properly. The areas which looked combed tended to look worse after de-interlacing. I tried QTGMC, TDient and Yadif. It didn't matter.

I then reduced the MI threshold low enough to de-interlace all the frames which appeared to have combing, which in the end was pretty low because TFM was reporting MI values of 1 and 2 for many of them. The only way that'd seem logical at the moment is if somehow what appears to be combing, isn't. The lower I dropped the MI threshold the more frames were de-interlaced, but that seemed be causing a large amount of blurring much of the time. Maybe I was having a slow day, but it took me a while to realise frames were being blended instead of being IVTC'd as I'd expected. That I'm yet to get my head around.... the reason TFM would consider a de-interlaced frame needs to be blended rather than applying IVTC.

Finally I thought maybe I could fix the frame blending problem first and understand the "why" second....
I played with every parameter I could find which looked like it might contribute to stopping the unwanted frame blending but nothing I did made a difference. Except something like hybrid=0, which obviously wouldn't be a good solution when the video in question is hybrid. I even tried disabling hints so TFM wouldn't be telling TDecimate what to do. I can't remember if it had no effect or a negative one, but it definitely didn't fix anything. I'd remember that.

So after playing around, all I seemed to have achieved was to make many of the areas with combing look worse by de-interlacing the frames in question, which in turn caused frames to be blended rather than duplicates removed. Does any of the above sound like it might be considered normal, or is there "oddness" to the video in question I haven't found yet?

I wondered as I was typing.... I was de-interlacing using a script like this (PP and MI parameters etc not included).

deint=QTGMC().SelectEven()
tfm(clip2=deint).tdecimate(hybrid=1)

As it's been mentioned, I'm wondering if instead of the above this might produce a more satisfactory result? I guess I'll have to try it when I get a chance.

deint=vinverse()
tfm(clip2=deint).tdecimate(hybrid=1)

[hello_hello]

Stereodude,
I thought I should let you know I'm not ignoring your post #54. Other stuff got in the way. There's a good chance I won't be experimenting with noise filters again for a day or two. I'll do the replying when I come back to it.
Cheers.

[Atlantis]

I had a bit of a play with your sample but didn't come up with any particular form of cleverness. I'm definitely no NTSC expert but I'm not sure your sample is a sample of "normal".
Oh yes, it's not normal. That's why I call it the episode from hell. Of all the 24 episodes in season 2, it's only this episode that it's this bad.

Also after much testing I'm considering dropping tdecimate(). I will keep the video at 29.97. No matter how hard we try, we can't get a film based framerate. Maybe the show was edited on video, I don't know but even after all that I see some little jumps from time to time. So I will use this

myvideo = "video.d2v"
DGDecode_mpeg2source(myvideo)

deint = QTGMC( Preset="Slower" ).SelectEven()
tfm(d2v=myvideo, clip2=deint)

vinverse()

[poisondeathray]

Also after much testing I'm considering dropping tdecimate(). I will keep the video at 29.97. No matter how hard we try, we can't get a film based framerate. Maybe the show was edited on video, I don't know but even after all that I see some little jumps from time to time.




Are you referring to the main program (not the video titles) ?

Is TDecimate dropping the wrong frame in the cycle ? , or is it a TFM matching issue in the first place ?

Did you tweaking the tdecimate parameters ?

[Atlantis]

Are you referring to the main program (not the video titles) ?

Yes I'm referring to the main program that is recorded on film. I was prepared to accept jumpy video titles if all the rest was ok. But no still I get jumps, they are very close to a scene change. Near the end or beginning of a scene change (Like 2-3 frames to or after a cut). I did a closer examination as you asked and tdecimate() drops a frame that is not duplicate. That's why it looks jumpy.

So always close to an edit. I'm not an expert, I don't know if it has to drop a non-duplicate frame because of an edit cut? Maybe in case it has to drop a non-duplicate frame, it would be better if it drops the very last or very first non-duplicate frame. In that case we wouldn't see the jump.

No I didn't tweak the tdecimate parameters, I don't know what to tweak. Anyway to tell it to drop only the frames adjacent to a cut?

[poisondeathray]

I mentioned this earlier - the only way to get smooth titles and main program, is to use VFR (30p sections run at 30p, 23.976p sections run at 23.976p)

It's hard to say what's going on without examining it. You can look at both TFM and TDecimate's debug views (display=true) to see what decisions they are making

Both have different modes and settings which might be more appropriate . If you upload a section where it makes the wrong choice with your current settings, someone might be a le to suggest better settings to use

IMO, 30p for 24p is almost bad as a jumpy random drops

[Atlantis]

IMO, 30p for 24p is almost bad as a jumpy random drops
Could you please explain why? I get a perfect smooth video with no jumps at 30p. I get little jumps with 24p. Please explain why it's as bad? 30p looks correct where 24p has faults.

[poisondeathray]

Could you please explain why? I get a perfect smooth video with no jumps at 30p. I get little jumps with 24p. Please explain why it's as bad? 30p looks correct where 24p has faults.


If it's "film" - by definition it will be 24p .

30p means every 5th-6th frame will be duplicates, so you will have a cyclical stutter (That's the whole point of decimating after field matching)

If it looks correct at 30p, then perhaps it was shot on video (or at least that section you're referring to was shot on video, not film) . This is common on some DVD's where you have CGI effects (Frazier doesn't have any, but the common reference is Star Trek TNG DVD's). Still the only way to get 24p sections to play at 24, 30p sections to play at 30p is VFR

[Stereodude]

IMO, 30p for 24p is almost bad as a jumpy random dropsWell, you can Hybrid=3 to blend the 24p to 30p. IMHO that's better than judder.

[poisondeathray]

Well, you can Hybrid=3 to blend the 24p to 30p. IMHO that's better than judder.



Blends are the smoother but more blurry, but certainly another option

On a 60Hz display there will always be a 3:2 judder . But most NTSC-land born people are used to the judder. 24p native players on a 120Hz display have no judder, each frame is "evenly spaced" in time, or have the same display time on screen

My opinion is you should try to go back to what the original film content was, 24p, 1:1 frames for the encoding or backup. The telecine here was only added to make it compatible with DVD. If it was released on BD for example, it would have been native 24p. You have the option of applying blends or motion interpolate or various other methods on playback as post processing to smooth it out if you wanted to

[Stereodude]

On a 60Hz display there will always be a 3:2 judder . But most NTSC-land born people are used to the judder.This is where madVR's smooth motion is great.

[hello_hello]

I played around a bit more, and if nothing else at least I have a slightly better understanding of TIVTC.
I still think there's something not quite right though as some of the areas which appear combed still look a little odd after they're de-interlaced to me.

Because TDecimate uses info from TFM when deciding how it's going to do things. I found the only way I could play around successfully was to use TFM by itself in a script, then when everything was being IVTC'D and de-interlaced correctly, add TDecimate to the script and adjust it.

Anyway.... give something like these a go (different ways of doing much the same thing I tried):

deint=QTGMC().SelectEven()
tfm(cthresh=3, MI=15, order=1, clip2=deint)
tdecimate(vidThresh=6, hybrid=1)

deint=QTGMC().SelectEven()
tfm(cthresh=-1, order=1, clip2=deint)
tdecimate(vidThresh=6, hybrid=1)

deint1=Trim(0,189).QTGMC().SelectEven()
deint2=Trim(190,0).QTGMC().SelectEven()
Trim(0,189).tfm(order=1, clip2=deint1).tdecimate(hybrid=1)\
++Trim(190,0).tfm(cthresh=3, MI=15, order=1, clip2=deint2).tdecimate()

If you add "Display=true" to either TFM or TDecimate you can see some of the parameters which can help if you need to adjust them. For TFM it shows you which frames are being treated as "clean" and which ones are being de-interlaced. For TDecimate you can see if frames are considered video or film, and which frames are being dropped or blended.
I found QTGMC way too frustrating while fiddling, so I removed "clip2=deint" until I found which settings worked, adding "clip2=deint" again and checked nothing had changed.

Keeping in mind my understand of this is still fairly vague.....

Each frame is given a value (metric) displayed as an MIC value. You can specify "MI" in the script. The default is 80. If a frame's MIC value is equal to or higher than the MI value it's considered "clean". If you look through frames and determine the lowest MIC for a frame, then specify a lower MI value in the script, it should mean (I think) every frame gets de-interlaced. The trouble is, many frames which appeared to contain combing had MICs of one or zero. When you lower the value for "cthresh" (the default is "9") it increases the MIC value for each frame so you can then set an MI value which de-interlaces every frame.
For your "impossible to tfm" sample, cthresh=3 meant the lowest MIC frame value I could see was 17 (unless a frame was completely black), hence using cthresh=3 and MI=15 in the first script. If you wanted to be sure, you could probably output an overrides file to check more accurately.

Alternatively if you use "cthresh=-1" (second script), every pixel is detected as combed, therefore you don't need to mess around with MI values because everything gets de-interlaced anyway. I'm still not clear on the differences, but I'd assume "cthresh=-1" would mean every frame is de-interlaced completely, whereas without it, adaptive de-interlacing is used? When I encoded the first two scripts, the file size for the second one was a little smaller.

From there I added TDecimate and tried to find a way to stop it blending frames. I don't know why I couldn't do it yesterday, but it worked today. For your sample it was fairly easy to find a value for "vidThresh". I used "Display=true" for TDecimate while previewing the opening graphic. For it to be treated as video and frame blended, "cthresh" needed to be lower than around 7. For the actual video, above 4 seemed to prevent any frame blending, hence vidThresh=6 in the script. If you don't care about the opening graphic, you could just use TDecimate() and it'll drop frames for 23.976, but the graphic does look smoother when it's frame blended.

After messing around for a while it occurred to me to divide the encode into sections. Hence the third script which divides your sample into "opening graphic" and "everything else" with Trim(). Then different settings can be used for each section (it required doing the same for the de-interlacing so "clip2" would work).
Nothing special was needed for the opening graphic. The defaults plus Hybrid=1 worked fine. For the rest of it nothing but the defaults seem to be needed for TDecimate. Without Hybrid=1 it just gets decimated.

I've no idea whether the ways I worked out how to do it are necessarily the best, but they seem to work.

[Atlantis]

I have noticed an interesting side-effect with vinverse().

vinverse() does make the image a little worse when there is edge enhancement present.

It seems they introduced edge enhancements on later seasons of Frasier. When using vinverse those jaggy lines become even worse.

Anything for this? How to avoid vinverse making it worse? Or something else that doesn't affect edge enhancement?

[poisondeathray]

I have noticed an interesting side-effect with vinverse().

vinverse() does make the image a little worse when there is edge enhancement present.

It seems they introduced edge enhancements on later seasons of Frasier. When using vinverse those jaggy lines become even worse.

Anything for this? How to avoid vinverse making it worse? Or something else that doesn't affect edge enhancement?



Don't use vinverse on those episodes? :)

You can reduce the contrasharpen strength in vinverse (default sstr=2.7), or deal with the underlying problem . e.g If there are "jaggy lines" , and vinverse is enhancing those - consider using some antialiasing function first

[DeathAngelBR]

The best results I've had so far with a really shitty annoying VFR source is precisely TFM + QTGMC.

1st pass (analysis)

deint = AssumeTFF().QTGMC( Preset="slow", SourceMatch=2, Sharpness=0.4, TR2=1, noiseprocess=0 ).selecteven()
tfmtxt = "tfm_QTGMC.txt"
decitxt = "deci_QTGMC.txt"
tfm(d2v=_d2v_,order=1,slow=2,pp=4,clip2=deint,output=tfmtxt).tdecimate(mode=4,output=decitxt)

Then I open the output file written by tfm and look for all frames marked as combed, and manually check for any residual combing around those frames. This is when the override file comes in.

2nd pass (encode)

tfm(d2v=_d2v_,order=1,slow=2,pp=4,clip2=deint,ovr=ovrtxt,input=tfmtxt).tdecimate(mode=5,hybrid=2,tfmin=tfmtxt,input=decitxt,mkvout=mkvtxt)
deint = AssumeTFF().QTGMC( Preset="slow", SourceMatch=2, Sharpness=0.4, TR2=1, noiseprocess=0 ).selecteven()
tfmtxt = "tfm_QTGMC.txt"
decitxt = "deci_QTGMC.txt"
ovrtxt = "override.txt"
mkvtxt = "mkvout_QTGMC.txt"
tfm(d2v=_d2v_,order=1,slow=2,pp=4,clip2=deint,ovr=ovrtxt,input=tfmtxt).tdecimate(mode=5,hybrid=2,tfmin=tfmtxt,input=decitxt,mkvout=mkvtxt)

Instead of lowering MI and cthresh values which possibly results in deinterlacing frames that aren't really combed, you should try the override feature.

(I *had* to use pp=4 because the default pp=6 and others output really awful frames in particular scenes.)

[hello_hello]

Using the overrides function is possibly the best way, but more time consuming. I'm not sure I understand how pp=4 and clip2=deint work together in your second pass script as I'm still fairly new to playing with TFM settings.
For the clip in question I'm not sure frames with combing and frames marked as combed are necessarily grouped together as such.

I tried several methods of de-interlacing when using a script which causes every frame to be de-interlaced, and with Atlantis's sample the only way to get away with it was to use QTGMC. The side-effects were pretty minimal. If anything, it sharpened by a very small amount, although that can have a slight negative effect on straight lines. Every other de-interlacing method looked terrible.

For example:

tfm(cthresh=-1, order=1, pp=5)
tdecimate(vidThresh=6, hybrid=1)

http://i.imgur.com/rE8Evmn.jpg

tfm(cthresh=-1, order=1, pp=6) # pp=4 looks much the same
tdecimate(vidThresh=6, hybrid=1)

http://i.imgur.com/EW46lvV.jpg

deint=QTGMC().SelectEven()
tfm(cthresh=-1, order=1, clip2=deint)
tdecimate(vidThresh=6, hybrid=1)

http://i.imgur.com/LhDImO2.jpg

tfm(cthresh=-1, order=1, pp=1) # no deinterlacing
tdecimate(vidThresh=6, hybrid=1)

http://i.imgur.com/BlERJaV.jpg

Full disclosure:
I saved each image using jpg's maximum quality. When I downloaded each image from my post (to make sure I'd placed them in the correct order by comparing file sizes) I realised the hosting service had re-compressed the last image. It must have just exceeding some sort of file size limit. Instead of 100% quality, it's 90%.

[DeathAngelBR]

pp=4 and clip2=deint work precisely the same way in both passes. The only difference is that using a tfm input file speeds things up a bit in the 2nd pass.

This is the problem I had with default pp=6:

http://i.imgur.com/zQLsg1i.png

[hello_hello]

I'm probably not asking the question the right way.

The TFM help file says:
If pp => 5 then TFM will build the mask as usual and only pixels in moving areas will be taken from the frames in clip2.
If PP < 5 then frames will be taken as is from clip2.

Would I be correct in assuming the upshot of that is, QTGMC deinterlaced the whole frame in your second pic, whereas for the first one, the parts of the frame considered static would have been left untouched?

If that's correct then I've still just got to get my head around how it works in conjunction with whether a frame is detected as combed or not.

It seems obvious if no combing is detected then no de-interlacing takes place.
As an example (because this is what seemed to be happening when I was playing with Atlantis's sample)

If I used "Display=true" so TFM would show me where it was detecting combing, it might show it's detecting it in a small section at the bottom right of a frame, but I could see combing elsewhere.
If I used cthresh=-1 then everything is detected as combed.
What I'm trying to understand is whether one of the above scenarios could cause the frame to be de-interlaced differently, assuming the same pp value is used each time, or are combing detection and motion adaptive de-interlacing independent functions?

I'm assuming for your example above, the adaptive deinterlacing was effectively "getting it wrong" and it's not because TFM was telling the deinterlacer only to de-interlace the parts of the frame where it detected combing?

When playing with Atlantis's sample, it seemed "pp=4,clip2=deint" and "pp=6,clip2=deint" both fixed all the combing in a frame (assuming combing was detected) and I couldn't really see a difference between them, but encoding the sample resulted in slightly different file sizes, so I realised the video was being de-interlaced differently. I just wasn't sure when it came to fiddling with MI and cthresh values. Obviously they effect the number of frames which are de-interlaced, but I wasn't sure whether they'd also effect how those frames were deinterlaced.

[hello_hello]

Another question I also had, and I'll use the second pic from post #85 as an example.....

De-interlacing that way had a noticeable (negative) effect. The frame in question had no combing so required no de-interlacing, but what would happen if it did, while many frames preceding it and following it had no combing? If I did it "correctly" and configured TFM in such a way that it was the only deinterlaced frame, when playing the video normally that frame would probably stand out.

Obviously you wouldn't choose to deinterlace that way, but it did make me wonder if sometimes de-interlacing every frame might produce a more "consistent" result than you'd get from only de-interlacing combed frames. I guess it might come down the number of frames which need de-interlacing and the effect of doing so, but it did occur to me that maybe there's a point where deinterlacing every frame might look better than only deinterlacing the frames which "require it"?

[Atlantis]

I am at the end. Was doing season 11 and surprisingly my same script that worked for 10 seasons, gave me errors and couldn't open it.

I did a closer look and saw that my d2v files are marked as Frame_Rate=23976, 98.67% FILM.

So I went through frame by frame and saw that it is a very clean transfer and needs no processing except the opening titles.

So I did the first 10 seasons at 29.97fps with tfm/QTGMC and vinverse. I did the last season at 23.976 fps just with vinverse for the opening titles.

Previously I spent several weeks to do a season. It's impossible to go frame by frame or use overfiles. I was so happy with my script and things I learned here that I went back and deleted all the previous work I had done (maybe months of work). I started from scratch and I did all the 11 seasons in only one week.

[Atlantis]

Could you please explain to me what's this idea of DGIndex saying 98.67% FILM for example?

Does it do an internal tfm to check if the source is film? Why only my season 11 is recognized as 98.67% FILM and not the previous 10 seasons?

[hello_hello]

Keeping in mind I live in PAL-land so could be wrong.....
NTSC "film" can have either hard or soft pulldown. Soft pulldown means the video is 23.976fps, but it contains pulldown flags so the player adds the pulldown on playback and the output is 29.970fps. If that's the case, by ignoring the pulldown flags, you get the original progressive 23.976fps "film".

I'd guess your season 11 DVDs are authored differently. They use "soft pulldown", whereas the rest had it encoded. DGIndex knows 98.67% of the video uses soft pulldown. The other 1.33% is probably the opening/closing credits. It could either use hard pulldown or it's actually 29.970fps interlaced. I think for your DVDs it's probably the latter.

MeGUI has an option to use "force film". It's enabled by default and set to 95%. If 95% or more of the video is considered "film" (soft pulldown), DGIndex will treat it all as film and output 23.976fps. Parts which are actually interlaced mightn't look perfectly smooth etc. If less than 95% is "film", or with force film disabled, DGIndex will honour the puldown flags and output 29.970fps which then needs to be IVTC'd in the usual way. Maybe the way you've used the d2v option with TFM doesn't work for progressive video. Hence the errors. I'm not sure.

If you change the force film option in MeGUI's settings (I usually have it disabled myself) and it'd change the output (frame rate) as a result, you'll need to re-index the video to create a new index file.

One of the scripts I posted earlier didn't require the use of overrides files or playing with various TFM settings. Adding cthresh=-1 simply causes every frame to be de-interlaced after field matching. I think it looks a bit better than just plain de-interlacing and it de-interlaces the movement where there's combing better. There's not a huge difference but at least the output is 23.976fps.

[Atlantis]

I am using tfm with the output="output.txt" option. Something strange happens that I don't understand. If I do a 2 pass encode, (the same avs file) at the end I get an empty output file.

It's like at the second pass it creates an empty file but never executes the tfm command to fill the file.

Do you have any idea why this happens at pass 2? How the second pass works that its like it doesn't execute tfm?

[poisondeathray]

I am using tfm with the output="output.txt" option. Something strange happens that I don't understand. If I do a 2 pass encode, (the same avs file) at the end I get an empty output file.

It's like at the second pass it creates an empty file but never executes the tfm command to fill the file.

Do you have any idea why this happens at pass 2? How the second pass works that its like it doesn't execute tfm?

You have to close the avs script in whatever application you're using for pass 1 before the text file is written. If it stays open, nothing will be written

The 2nd pass needs to specify the input option, not output option. (e.g. input="output.txt" option, not output="output.txt")

[Atlantis]

I am not sure what you are saying. Yes I know about input option. I am using MeGUI 2 pass.

I don't want to use input in the second pass because then I have to have 2 avs files which makes it more complicated. I just want an output file at the end to check for combed frames.

Each time tfm runs, it replaces the old output file.

If you mean the same pass 1 output file is still open in pass 2, it should still contain all the info from pass 1 and not be empty I think.

[poisondeathray]

ok I see, just to look at the output.txt file, not to use

It's probably a megui bug , because it works OK with CLI

What is supposed to happen if you use the same avs, is output.txt will be written in the 1st pass, and overwritten in the 2nd pass (and it does contain the data when using CLI)

[StainlessS]

MeGUI two pass has nothing to do with it, thats for MeGUI to set bitrate on 2nd pass after scanning to see how complex each frame is on 1st pass.

You need to create the output.txt by eg loading script into VirtualDub and playing all the way through [an AssumeFPS(250.0)] at end of script will speed it up).

You then close VirtualDub and the output.txt file should exist.

Once the output.txt file exists, then you can use a 2nd script using input="output.txt" (and remove output="output.txt)
as and arg, and give that to MeGUI.

So you need two scripts with slightly different args [and without the AssumeFPS(250.0) in 2nd script].

Re-read what PoisonDeathRay wrote.

If you only want to see the output.txt file, then omit the MeGUI step altogether.

[poisondeathray]

I think the purpose of using megui is he wants to "kill 2 birds with 1 stone" . He's not using the TFM metrics as input, just wants to look at the matches after the fact, after encoding (I don't know why you would do that... because if something is wrong you would have to re-encode it seems like a waste of time.... but anyways....)

Another way you can just look at the output.txt quickly is file=>run video analysis pass in vdub. Or even avsmeter. I think Megui has this too with the "queue analysis pass" button

[Atlantis]

Sorry StainlessS, what you wrote didn't help at all. It seems you didn't understand. Please re-read. I already know about what you said.

I don't want to open the avs file in VirtualDub, that is one extra step.

I want to do my encoding and have the output file at the end too.

When I do my encoding in Megui, at the end of Pass 1 I do get the proper output file filled with the info. When pass 2 starts, the old output file is replaced with an empty one and never filled. It is this behavior the question and nothing else. You can try it yourself.

[Atlantis]

(I don't know why you would do that... because if something is wrong you would have to re-encode it seems like a waste of time.... but anyways....)
Yes I understand. I just want to understand why I get an empty file at pass 2. It's to better understand how avisynth/tfm/megui works.

[StainlessS]

Thanks PDR, I always forget about VDUB queue video analysis, I usually use AssumeFPS(250.0) as I want to see any
metrics on last frame (assuming script displays metrics), I guess the queue option is faster than Run Video Analysis Pass
as it does not even display video.
Thanks again.

[StainlessS]

Sorry for any misunderstanding Atlantis.

Did some exploring, Queued 2 Pass, with postponed muxing stage

Using only this script


RT_DebugF("Opening AVS File @ %s",RT_LocalTimeString(false))
VideoFileName ="D:\TFM\NTSC_Top_FILM.d2v"
MPEG2Source(VideoFileName).AssumeTFF
tfm(d2v=VideoFileName,output="output.txt")
Return Last


Results from RT_DebugF in DebugView Window

START OF PASS 1

00000001 0.00000000 [1048] AvsTimer 0.7
00000002 0.90207607 [1048] RemoveDirt 0.4
00000003 0.90755969 [1048] RemoveDirt 0.9
00000004 1.38205838 [1048] SSETools 0.1
00000005 2.14236116 [1048] RT_DebugF: Opening AVS File @ 2014-02-21 00:15:34.937
00000006 2.51615357 [1048] AvsTimer 0.7
00000007 3.41980290 [1048] RemoveDirt 0.4
00000008 3.42528105 [1048] RemoveDirt 0.9
00000009 3.89493632 [1048] SSETools 0.1
00000010 4.64975119 [1048] RT_DebugF: Opening AVS File @ 2014-02-21 00:15:37.453
00000011 5.03148890 [1048] AvsTimer 0.7
00000012 5.93346691 [1048] RemoveDirt 0.4
00000013 5.93898058 [1048] RemoveDirt 0.9
00000014 6.41274118 [1048] SSETools 0.1
00000015 7.16697073 [1048] RT_DebugF: Opening AVS File @ 2014-02-21 00:15:39.968
00000016 15.05930328 [1048] AvsTimer 0.7
00000017 15.96577930 [1048] RemoveDirt 0.4
00000018 15.97129250 [1048] RemoveDirt 0.9
00000019 16.44216728 [1048] SSETools 0.1
00000020 17.19692039 [1048] RT_DebugF: Opening AVS File @ 2014-02-21 00:15:50.000
00000021 17.76827812 [4004] AvsTimer 0.7
00000022 18.67107010 [4004] RemoveDirt 0.4
00000023 18.67652130 [4004] RemoveDirt 0.9
00000024 19.15471268 [4004] SSETools 0.1
00000025 19.92819977 [4004] RT_DebugF: Opening AVS File @ 2014-02-21 00:15:52.734

HERE TEXT FILE IS POPULATED @ AVS Closure

START OF PASS 2

00000026 107.40196228 [1048] AvsTimer 0.7
00000027 108.30832672 [1048] RemoveDirt 0.4
00000028 108.31529999 [1048] RemoveDirt 0.9
00000029 108.78475952 [1048] SSETools 0.1
00000030 109.53949738 [1048] RT_DebugF: Opening AVS File @ 2014-02-21 00:17:22.343
00000031 110.07365417 [2212] AvsTimer 0.7
00000032 110.97916412 [2212] RemoveDirt 0.4
00000033 110.98462677 [2212] RemoveDirt 0.9
00000034 111.45916748 [2212] SSETools 0.1
00000035 112.23111725 [2212] RT_DebugF: Opening AVS File @ 2014-02-21 00:17:25.031

HERE TEXT FILE IS POPULATED @ AVS Closure

MAYBE Re-SCANNING to get some info for MeGUI log file ???

00000036 195.30229187 [1048] AvsTimer 0.7
00000037 196.21223450 [1048] RemoveDirt 0.4
00000038 196.21777344 [1048] RemoveDirt 0.9
00000039 196.69239807 [1048] SSETools 0.1
00000040 197.44729614 [1048] RT_DebugF: Opening AVS File @ 2014-02-21 00:18:50.250

HERE TEXT FILE IS RE-CREATED/INITIALIZED DUE TO REOPENING OF AVS BUT NOT POPLATED

TEXT FILE contains only
#TFM v1.0.4 by tritical
field = top
crc32 = dbef609c


As you can see, AvsTimer through to SSETools is where plugins are loaded from Plugins Dir.

It opens avs file 5 times at start of 1st pass,
twice at start of 2nd pass,
and again after 2nd pass is completed (where output.txt is again initialized, ie empty, after closure it contains only the header)

Maybe Zathor can shed some light.

EDIT: Problem stems from eg tfm initializing (zero bytes) at opening, whereas many such plugins only create/re-create and populate output file at the end when script closed (and quite often only created/populated if every frame was scanned).

EDIT: I have 200+ plugins in my plugins Dir, the shown plugs are the only ones that output debug text during filter constructor .

EDIT: Loading avs into VirtualDub then closing without playing creates something like this (before closure it is zero bytes in size)

#TFM v1.0.4 by tritical
field = top
crc32 = dbef609c
0 c - [10]

where only the first frame has an entry, so looks like MeGUI only opens the AVS without requesting a single frame.

[Atlantis]

Thanks for the explanation.

After having perfect encodes at 23.976 fps for my season 11, I went back and looked closer at season 10. It seems each season has different transfers.

Only season 11 gave me 97% film and season 10 gives me 100% video when indexed but with closer inspection I have found out that season 10 also has a very clean transfer. When I use tfm with output option, I don't find a single detected combed frame in it. So I tried tdecimate and I get a very clean smooth video at 23.976 fps with no frame blending or further processing needed (no vinverse needed). The smooth video includes all, the main program, the beginning titles which are the most problematic and the end titles. It's actually better than season 11. Season 11 was detected at 97% film and MeGUI marked them at 23.976 but the opening titles looked interlaced in parts.

So I am going back one by one the seasons and redoing them! Inspect them closely. That's where tfm output comes handy. If I don't see a combed frame in the output file I think it would be a clean transfer and I can decimate and no need for post processing. If I see lots of combed frames, I have to investigate further. I'm guessing if lots of combed frames, I have to stay with my old script and output at 29.97 fps. The first seasons are not clean transfers for sure.

[Atlantis]

I was testing QTGMC in progressive mode for replacing vinverse where vinverse made the picture worse because of edge enhancements.

Surprisingly QTGMC in progressive mode is not good at all. I'm wondering if other people also feel this way. QTGMC in progressive mode produces bad motion artifacts.

Any other filter to replace vinverse?

What should I do when there is edge enhancement present?

[manono]

Surprisingly QTGMC in progressive mode is not good at all.
It's not really meant to be used for that.

Have you tried TDeint(Full=False)? Plus, you can choose one of several different deinterlacing modes. You can even use any deinterlacer you like (one such as QTGMC().SelectEven()) to catch any leftover interlacing. Check the TDeint doc, the examples near the bottom.

[Atlantis]

Tried TDeint(Full=False) but it has no effect. Picture attached. Only vinverse has an effect on it

[manono]

Have you posted a video sample that shows the problem?

[Sharc]

Did you try mode 2 with tdeint?
tdeint (mode=2)

[Mounir]

Try this maybe:
assumetff()
QTGMC( "fast", TR0=1, TR1=1, TR2=1)
SelectEven()
TDecimate()

[Atlantis]

Thanks for tdeint (mode=2). It looks better. I will do a long encoding to see what it does with edge enhancement.

Picture attached.
Top - unprocessed
Middle - vinverse
Bottom - tdeint (mode=2)

It looks blurrier than vinverse.

[Atlantis]

Try this maybe:
assumetff()
QTGMC( "fast", TR0=1, TR1=1, TR2=1)
SelectEven()
TDecimate()

Yes it looks perfect if I use yours. Even a normal QTGMC with no options works. I'm not sure what your QTGMC options do but I guess it's still a complete deinterlacing. I wanted not to deinterlace film based material. To use tfm and detelecine and later use something that would take care of some bad frames left. I am going to test more to see how good TDeint mode 2 is.

[Atlantis]

Interesting. Now I understand why tdeint() didn't work. tfm is sending out hints and tdeint is taking those hints without you knowing.

So tfm is reporting that all frames coming out are progressive, so tdeint considers them progressive and does nothing. One way is to disable hints in tdeint. tfm and tdeint are working closely hand in hand, I have to study them more.

[manono]

One way is to disable hints in tdeint
If you do that everything gets deinterlaced and then you may as well go the QTGMC route since it's a better deinterlacer, and not field match at all.

Setting Full=False (as I suggested earlier) ignores the hints. If it doesn't pick up the light interlacing in your sample picture, then begin tweaking.

[Atlantis]

No sorry manono, that's not true what you said. I just did an extensive test with debugging. Here are the correct information:

If you do that everything gets deinterlaced and then you may as well go the QTGMC route
This is not true. You can disable hints and set full=false and not every frame gets deinterlaced.

Setting Full=False (as I suggested earlier) ignores the hints.
This is also not true. I did that, setting full=false and it does not ignore hints. It still thinks everyframe is progressive as reported by tfm and does nothing. (visible in debugview: not deinterlacing Hints)

I tested all these with debugview.

This is the script that I use now:

DGDecode_mpeg2source(myvideo)

orig = last
deint = QTGMC().SelectEven()

tfm(d2v=myvideo, clip2=deint, debug=true)

tdeint(hints= false, full=false, clip2=orig, debug=true)

Too bad tdeint has no output option like tfm. If it had output, I could easily check the frames that are deinterlaced. Now I am using debugview which is a little more complicated.

[manono]

This is not true. You can disable hints and set full=false and not every frame gets deinterlaced.
You said nothing about setting full=false when speculating about disabling hints or anywhere else.
This is also not true. I did that, setting full=false and it does not ignore hints.
It does ignore hints. TDeint does its own check whether or not the frame is interlaced. It stands to reason that check might be similar to or even identical to the one TFM does. Which is why I said:
If it doesn't pick up the light interlacing in your sample picture, then begin tweaking.

From the TDeint doc:
If full=false, all frames are first checked to see if they are combed.
Which says nothing about TFM doing the check and passing hints to TDeint. In fact, there might be no TFM in the script when TDeint(Full=False) is used.

You can also use override files to deinterlace individual frames, especially when there's a tiny bit of interlacing, as in your text picture. I'm glad you solved your problem.

[Terka]

For me it looks like wrong lines order.
try assumebff() assumetff() and simple bob clp.bob(0,0.5)

[hello_hello]

Stereodude.....
Time goes so fast. I thought it'd be a couple of days before I played around with MCTD. It was more like two months. If you're still around......

I was referring to MCTemporalDenoise. When you say "two" are you referring to MCTemporalDenoise and QTGMC or MCTemporalDenoise and MCTemporalDenoiseMod?

I was referring to MCTemporalDenoise and MCTemporalDenoiseMod.
Which version do you use? Are there (theoretical) significant differences between them? I'm not sure I could actually see any.

FWIW, I wasn't referring to file size, but visual appearance.
If you're bored, start with the Blu-Ray of Moneyball and compare QTGMC to MCTemporalDenoise.

I don't have Moneyball but I found a fairly noisy 1080p video, resized it to 720p (to speed up the test encoding process) and then ran various filtering on it. It surprised me you find QTGMC too sharp because the result I saw was MCTemporalDenoise (default settings) produced a noticeably sharper picture. Sharper than the original. It looked a little too sharp to me. QTGMC definitely removed more noise when I ran it in progressive mode with my "typical" denoise setting.
QTGMC(InputType=1, Ezdenoise=2)

My typical setting is MCTemporalDenoise(settings="low", radius=3), if the video is really noisy like the aforementioned Moneyball I will use MCTemporalDenoise(settings="medium"). If I want something in between "low" and "medium" I use this:
MCTemporalDenoise(settings="low", radius=3, sigma=6, SHmode=3, useEEDI2=false, \
quant1=30, quant2=60, ECrad=4, ECmode="Removegrain(3,-1)", maxr=3, TTstr=2, \
GFthr=1.6, thSAD=400, thSAD2=400, thSCD1=400)

I gave MCTemporalDenoise(settings="low", radius=3) a spin, given that's your typical setting. It seemed to remove a bit more noise so I dropped QTGMC's denoising down to "1" and they started to look pretty similar in the noise removal department but the MCTemporalDenoise encode was still definitely sharper.

You can probably even get a reasonable idea as to the amount of noise removal/sharpness by comparing the resulting file sizes (these were just 1.5 minute encodes).

Re-encode, no filtering - 53.1MB

QTGMC(InputType=1, EzDenoise=2) - 31.9MB
QTGMC(InputType=1, EzDenoise=1) - 37.6MB

MCTemporalDenoise(default settings) - 41.0MB
MCTemporalDenoise(settings="low", radius=3) - 39.5MB

MCTMod(default settings) - 41.1MB
MCTMod(settings="low", radius=3) - 39.6MB

When I tried my old AVI, wobbly Xvid picture, lots and lots of noise, torture test encode, there was no comparison. QTGMC in progressive mode stabilised the picture far more and left MCTD for dead.

Anyway.... I'm not saying QTGMC is better (well at picture stabilisation I think it is), and I'm sure MCTD has enough settings to play with so I could fine tune it to taste, but to my eyes, MCTD definitely sharpened more. At least in progressive mode.
Each to their own, I guess..... :)

[Stereodude]

I was referring to MCTemporalDenoise and MCTemporalDenoiseMod.
Which version do you use? Are there (theoretical) significant differences between them? I'm not sure I could actually see any.I've been using MCTemporalDenoise.v1.4.20. I don't think I've tried MCTemporalDenoiseMod.
I don't have Moneyball but I found a fairly noisy 1080p video, resized it to 720p (to speed up the test encoding process) and then ran various filtering on it. It surprised me you find QTGMC too sharp because the result I saw was MCTemporalDenoise (default settings) produced a noticeably sharper picture. Sharper than the original. It looked a little too sharp to me. QTGMC definitely removed more noise when I ran it in progressive mode with my "typical" denoise setting.
QTGMC(InputType=1, Ezdenoise=2)Well, it's been a while so I want to go back and re-read my postings before commenting further. I have found that MCTD is able to remove graininess better without damaging the underlying image. For example, on very grainy sources, QTGMC puts a static noise pattern on top of the image. I've put together a few screenshots to try to illustrate this. If I can find a decent free picture host that supports .png files I'll post them.

[hello_hello]

I have found that MCTD is able to remove graininess better without damaging the underlying image. For example, on very grainy sources, QTGMC puts a static noise pattern on top of the image. I've put together a few screenshots to try to illustrate this. If I can find a decent free picture host that supports .png files I'll post them.

No need. I know exactly what you're referring to.
I think that's the downside of QTGMC's picture stabilisation. If it doesn't remove all the noise, it stabilises what's left, and you can end up with the static noise pattern you described. At least that's what I assume is happening. As a result, if I'm using QTGMC for noise removal I try to remove enough so there's no static noise pattern left behind.

I'm going to keep playing with MCTD. If I can tone down the sharpness a bit I'm sure I'll be happy with it, and there'll be plenty of times when the picture doesn't need stabilising as such, so chances are the result will be better if it doesn't leave the static noise pattern. Not too much better I hope, otherwise I'm already forming a list of video in my head which I'd have to consider re-encoding. Sigh..... :(

Have you used the TemporalDegrain script much? If you have, how do you think it compares to MCTD?

[johnmeyer]

In looking at the last few posts, I have two short comments.

First, I would do de-noising before doing any downsizing. Nothing good is going to happen when the scaling algorithms have to deal with noise when going from 1080p to 720p.

Second, the noise coherence you refer to is not the result of motion stabilization, but is a fairly standard artifact that can result from temporal denoising. You can often get much better results using scripts and plugins that directly expose more of the denoising parameters, and which were designed specifically for that purpose. Remember, QTGMC is, first and foremost, a deinterlacer, not a noise reduction script. This is not to say it cannot do denoising, but I'm quite certain you would get better results using a denoising script. I would suggest starting with one based on MDegrain2, but I'm sure other people can suggest other ideas.

[hello_hello]

There's probably no right or better in every case. I've been happy with the results so far when using QTGMC for denoising but I will play around with a couple of the denoising scripts some more. I still think though, if the picture needs both stabilising and noise removal, QTGMC tends to have the edge.

I dug out a "torture test" video a while back and re-encoded it while filtering with QTGMC, FastDegrain, TemporalDegrain and a couple of standalone filters, I hadn't discovered MCTemporalDenoise at that stage but I tried it, and it's default settings don't match QTGMC. The TemporalDegrain script did a pretty good job but QTGMC fixed a lot of the "bobbing" or "shimmering" (however you describe it) while TemporalDegrain didn't. Admittedly it's an extreme example, but I found it an interesting test.

If you look at the encodes, you'll see the one using QTGMC without it's noise removal enabled, resulted in what I assume is the "static noise pattern" Stereodude referred to. Well in this case the video was so noisy it'd be more accurate to refer to it as "semi static noise pattern". It's not pretty, but still better than the unfiltered video. With QTGMC's noise removal enabled I think it gave TemporalDegrain a run for it's money in the noise removal department and it definitely stabilised the picture more.

There's a zip file containing my torture test encodes here (http://forum.videohelp.com/threads/358043-A-comparison-of-AVIsynth-denoise-filters?p=2283228&viewfull=1#post2283228). Admittedly aside from adjusting QTGMC's denoising I used the default settings for each filter so maybe they results would be different if I tweaked filter settings. I'd be interested to know if anyone has any clever suggestions for the video in question.

[creaothceann]

I don't have Moneyball but I found a fairly noisy 1080p video, resized it to 720p (to speed up the test encoding process)

Did you mean cropped?

[hello_hello]

No, I meant resized. Yes I resized before the noise removal when running tests, but the world kept turning...... ;)

[gugglu]

Greetings boy's, maybe this could help you bit more

QTGMC( TR2=3, Preset="Slower", Sharpness=0.2, SMode=2, SLMode=2, SLRad=3, \
EdiMode="nnedi3", NNsize=3, NNeurons=4, Ediqual=1, EdiMaxD=8, Sbb=3, SrchClipP=3, \
Blocksize=16, Subpel=4, PelSearch=4, Overlap=8, ChromaMotion=True, Inputtype=2, \
ProgSadmask=10.00, Stabilizenoise=true, Edithreads=4 )