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.