QTGMC Deinterlacing Script (v3.32)

[Didée]

Originally Posted by sadie

It looks to be an ntsc tv capture and an attempted progressive divx encode but where someone forgot to turn off the interlace switch. The 4700 kbps is a giveaway it was handled by someone even more amateurish than myself. The trouble is that when QTGMC gets its mitts around it various sequences will show 'morphing' or stretching of facial features and such. As if the temporal smoothing is really having to work overtime (?) Very disagreeable.

The "trouble" is not related to QTGMC, you'll see exactly the same issue when using a simple Bob(). The clip simply is broken. Someone did change the vertical framesize with a "progressive" resizing method, thereby destroying the interlaced field structure. As a result, each top field contains alternating bands of top- and bottom fields, and same for the bottom field.

Here's a simple simulation of what has happened:

BlankClip(width=576,height=480)

interleave(BlankClip(width=576,height=480,color=$006000),
 \         BlankClip(width=576,height=480,color=$600000))

AssumeTFF().ShowFrameNumber()

i1 = SeparateFields().SelectEvery(4,0,3).Weave()
i2 = i1.bicubicresize(576,464,0,0.5) .addborders(0,8,0,8,color=$200000)

stackhorizontal(i1.addborders(0,0,8,0,color=$002000),i2)

bob(0,0.5)
subtitle("bobbed interlaced source",x=160,y=32)
subtitle("""interlaced source resized 'progressive', then bobbed""",x=576+88,y=32)
return(last)

[nhope]

I'm an idiot. I had H264 decoding disabled in ffshow. I've enabled it now and DirectShowSource will open both .MTS fine. Incidentally the TM700 file had been giving exactly the same error as the HG21 file before I enabled the H264 decoding.

[nhope]

deleted

[nhope]

Didée, 3 questions about the script you used for the doll, which gave excellent results...

1. Have you tweaked that script specifically to cater for the horrific, moiré-inducing nature of the background, or is it a script that you might use generically for HD to 480i conversion?

2. Since QTGMC is a development of tempgaussmc, could tempgaussmc_beta2a(1,1,1,nsize=5,sharp=1,sharpness=0.0,svthin=0.0,sbb=0)
be done in QTGMC, to minimise the number of scripts involved?

3. Where would the "missing" AR 16:9 aspect ratio flag go?

[Didée]

1. Yes / maybe
2. Sure, just need to use parameter names
3. x264: "--sar width:height"

Generally, the usage of QTGMC (or even the 'double' usage) in this case here is ever-so-slightly over the edge. - With such a big downsize as in 1080 -> 480, a quite similar result probably could be achived with a much simpler bob (even yadif), or even with a direct fieldbased downsize.
I just had to go the TGMC route, since johnmeyer concluded

I tried your torture test using the QTGMC-based re-size script and the moiré patterns were horrible. I tried some of the slow presets, but that didn't help much. So, as much as I liked the results on my ballet footage, for this clip, I think it fails, and it fails quite spectacularly.

but as can be seen from my two samples, QTGMC of course can deal with this torture clip. One just needs to be a bit careful with the sharpness settings in this case. And of course, with so much high frequencies present, you should NOT do the final re-interlacing without lowpassing. "With best regards, Nyquist."

[-Vit-]

Didée's script in QTGMC 3.31 form. Untested, just a settings conversion. I don't know what tempgaussmc_beta2a is, I only have beta2/mod (maybe a version that supports NNEDI3?).

# For more speed add Blocksize=32 and/or drop NNeurons and/or switch to "Faster"
QTGMC( "Fast", TR0=1,TR1=1,TR2=1, NNeurons=1, SubPelInterp=1, Sharpness=0 )

 -- >here< is a good point to save an intermediate Huffy or Laggy or FLV-y --   ;-)

bicubicresize(1440,960)
bicubicresize(720,960,-.8,.6)

p1 = bicubicresize(720,480,-.8,.6)

p2 = p1.QTGMC( "Slower", TR0=1,TR1=1,TR2=2, InputType=1 )

p2.blur(0,1).sharpen(0,.51).blur(0,1).sharpen(0,.85)

i1 = assumetff().separatefields().selectevery(4,0,3).weave()

# p1 # straight to 60p
# p2 # plus more calmed
  i1 # re-interlaced p2

return(last)

If you're serving the script through MeGUI then you can set the AR by adding this to your script:

global MeGUI_darx = 16
global MeGUI_dary = 9

[sadie]

@didee:

Nice analysis. I understood but half of it. The upshot I take it is that 'clip is broken' = 'clip cannot be reglued'. Again, I wonder if there is a strategy within qtgmc that might somehow minimize that goofy stretching yet still clean out the combing (SelectEven?). And of course I can always just keep it interlaced and live with the blur. It's only to be used at a low resolution anyway. Thanks for the help.

[johnmeyer]

Originally Posted by sadie

A quick follow-up to myself. I've tried to run the clip through Assume TFF/BFF().SeparateFields() with indifferent results (normal since this is after all a 'progressive clip'.) But both do show the distinctive signs of a field order problem (forward & back then forward again). The question remains: how to clean this up if possible?

I downloaded your clip. I have seen this sort of thing before and it is a perfect demonstration of why I always recommend that people NOT deinterlace video and just leave things alone. The problem is not that deinterlacing isn't necessary in some limited circumstances, but rather that so many people screw it up and make things far, far worse.

I have been given many clips like this to clean up. First of all, the idiot(s) that screwed around with it before you got it managed to encode black bars into the video. Obviously you want to crop those out.

Second, the way I have dealt with identical videos in the past is to separatefields() to end up with half-height double-fps video.

I then carefully look at the odd and even fields. In the case of your video, it is quite clear that the odd fields were created from some sort of horrible estimation algorithm. You can see people's faces warp and distort. Yuchh!

The approach then is to decimate (delete) the odd fields, crop out the black bars, resize the remaining fields to the original frame size (minus the crop), and then use MVTools2 to estimate the the missing frames/fields. Obviously you are losing the "resolution" from the decimated fields, but they contain nothing but garbage, so it really doesn't matter.

The code below is extracted from a script I used when I restored all fifty-seven hour-long episodes of the Johnny Cash show for a collector several years ago. He got them from a collector in the UK who got them from Australia who got them from source here in the US. You get the idea. Too many hands. In my case, I was trying to get them to look like the original video broadcasts, and so I converted back to 60i. In your case, you might be happy just to convert them to 30p which is what I have done.

Here's a low bitrate encode of the resulting video:

KibSok_cut (fixed).avi

If you encode at higher bitrate, it should look pretty clean.

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

AVISource("e:\frameserver.avi").ConvertToYV12.killaudio()

crop(0,top_bottom_crop,-0,-top_bottom_crop)

#Throw away bad fields. Video is now half size vertically.
separatefields().selecteven()

source=LanczosResize(640,464-top_bottom_crop)

super2=MSuper(source,pel=2)
backward_vec = MAnalyse(super2,blksize=16, overlap=4, isb = true,  search=3 )
forward_vec =  MAnalyse(super2,blksize=16, overlap=4, isb = false, search=3 )

MFlowFps(source,super2,backward_vec, forward_vec, num=30, den=1, ml=100)

[Didée]

Sorry John, but the technical part of your analysis of the problem is completely wrong.

At 'mastering' stage, nobody did try to deinterlace this video. The odd fields are not made by some horrible estimation algorithm, and the even fields share the very same issue like the odd fields.

What happened was that interlaced 720x480 was resized to 640x464 with a resizer in progressive mode. Exactly that, nothing more, nothing less.

Edit: proof:



Your solution is good - since it's close to impossible to (sufficiently) revert the interlace-damage, keeping just one field & discarding the other is the next best thing you can only do. But the problem analysis definetly needed to be corrected.



Edit: <*deleted*> (issue purged)

[johnmeyer]

Originally Posted by Didée

... if you post things about me in public that are not true, it should be corrected in public.

I am very sorry you are offended, and I apologize.

You ask me to correct untrue things, and do so in public, so in good faith, let me attempt to do that.

First, since you did not quote the entire post from the Sony forum let me clarify something. My post in the Sony forum was VERY long, so I agree that you should not have quoted it all, but since others may not read my post in that forum, there might be a mistaken impression that I somehow went on a rant against you. So, let me state for those reading here who don't visit that forum: I did not identify you in any way in that post, and no one reading that post would know that it was you.

Second, I did not see the script you posted. I just looked at your post and see that it was edited approximately an hour and a half after the original post (the original post was at 14:55 and was last edited at 16:26). I am certain that I read your post just after it initially posted, and in fact you can see that my next post was at 15:36, which is about halfway between your initial post and your final revision.

So, I don't know if you added or edited the script after your initial post. However, I can say for certain that the script I see there now is quite complete and exactly what I was looking for. Therefore, I can understand that you would be extremely upset with me for saying that you hadn't been responsive when in fact you have now provided exactly what I was asking for.

I should mention that in one of my posts earlier in this thread I said:

Originally Posted by johnmeyer

Thank you, thank you, thank you Didée for posting. Because I respect your opinion so much, it forced me to go back and re-do the QTGMC testing from yesterday.

I think you can agree that this is not something a person would post who is trying to pick a fight with you.

Finally, I just now went to the Sony forum and I removed the sentence you quoted above from my post.

So, I have apologized, have described how the situation arose, and have removed the offending quote. I hope that settles this.

I had been working on a response to your tutorial on how improper resizing may have contributed to the bad things happening on the "KibSok_cut.avi" file, but given the circumstances, I think I'll lay low for awhile.

[nhope]

Didée & -Vit-, thanks for the info.

Can anyone tell me how to correctly change the following script to output BFF instead of TFF? (I know this isn't directly QTGMC-related but I want to compare the result of this script with some others including some QTGMC versions and some BFF versions done in other ways)

source=DirectShowSource("D:\My Videos\720x480-for-NTSC-DVD\challenge-Amendegw-AVCHD.MTS").assumetff()
IResize(source,720,480)
function IResize(clip Clip, int NewWidth, int NewHeight) {
  Clip
  SeparateFields() 
  Shift=(GetParity() ? -0.25 : 0.25) * (Height()/Float(NewHeight/2)-1.0)
  E  = SelectEven().Spline36resize(NewWidth, NewHeight/2, 0,    Shift)
  O  = SelectOdd( ).Spline36resize(NewWidth, NewHeight/2, 0,   -Shift)
  Ec = SelectEven().Spline36Resize(NewWidth, NewHeight/2, 0,  2*Shift)
  Oc = SelectOdd( ).Spline36Resize(NewWidth, NewHeight/2, 0, -2*shift)
  Interleave(E, O)
  IsYV12() ? MergeChroma(Interleave(Ec, Oc)) : Last
  Weave()
}

[sadie]

Thanks, John, for your effort of digging into the matter. I'm going to try and play with it next week when I'm off in the country. Still, I'm not entirely convinced. Even if your test sample is very low bit rate, I'm still not sure it only sort of resembles what I get using SelectEven settings with qtgmc. And i respectfully disagree that the odd fields are remarkably different from the even ones. The problem seems to be that they are just consecutively disordered. I should have uploaded a sample of my test using the simple avs:

DirectShowSource ("E:\KibSok.avi")
QTGMC (preset="fast")
Lanczosresize (720,576)
convertfps(50)

So here, it's true, the warping is more finely accentuated in the major moving parts of my sample than with yours, but so is the detail in the unaffected more 'static' parts. And the latter comprise roughly 2/3 of the video. So I suppose it all boils down to a global psycho-visual appreciation of the subject matter. In fact if I just closed my eyes once every three seconds I'd have no problems at all But, I'll give your script an honest whirl.

More importantly, I want to know how come you guys don't seem knocked off your feet by the gal in this video.

[Gavino]

Originally Posted by nhope

Can anyone tell me how to correctly change the following script to output BFF instead of TFF?

source=DirectShowSource("D:\My Videos\720x480-for-NTSC-DVD\challenge-Amendegw-AVCHD.MTS").assumetff()
IResize(source,720,480)

The simple answer would be to change 'assumetff' to 'assumebff'.
Since it works by resizing the individual fields directly, the IResize function preserves the field order of the input clip, so if you feed it BFF in, you will get BFF out.

However, that won't help if the input really is TFF and you want to change it to BFF. In that case you would need to reverse the field dominance before calling IResize. Various methods exist for doing this (eg stickboy's JDL_ReverseFieldDominance), but a quick and dirty way (which loses the very first field) is
SeparateFields.Trim(1,0).Weave()

[nhope]

Thanks Gavino.

Going back to Didée's script to deal with that horror clip, I can see that the idea is to get a reasonable bobbed, 60p, full res clip and then do some fancy stuff to it, including bicubically downsizing it sequentially in stages and running QTGMC over it. Here's the resizing/filtering stage again:

bicubicresize(1440,960)
bicubicresize(720,960,-.8,.6)

p1 = bicubicresize(720,480,-.8,.6)

p2 = p1.QTGMC( "Slower", TR0=1,TR1=1,TR2=2, InputType=1 )

p2.blur(0,1).sharpen(0,.51).blur(0,1).sharpen(0,.85)

i1 = assumetff().separatefields().selectevery(4,0,3).weave()

# p1 # straight to 60p
# p2 # plus more calmed
  i1 # re-interlaced p2

return(last)

I'm embarking on a round of tests for downscaling AVCHD/HDV to 720x480i for widescreen DVD. I have a minute of footage that includes that moiré-inducing horror clip but also more normal footage such as the HDV that can be seen on my YouTube channel. My list of tests at the moment:

1. Resizing in Vegas Pro
2. IResize "pure" script
3. QTGMC bob / Lanczos3 / no filtering > reinterlace
4. Simple bob > Didéeesque resize/filtering > reinterlace
5. Better bob (Yadif or TDeint) > Didéeesque resize/filtering > reinterlace
6. QTGMC bob > Didéeesque resize/filtering > reinterlace (=slow/ott)

Each will be encoded to MPEG-2 in CCE Basic.

It seems to me that there's a lot of filtering in Didée's script that may be excessive for most footage. Would anyone care to propose a "toned down" version that is more suitable for generic footage? Perhaps something between test 3 and tests 4/5/6? Resize in fewer stages perhaps? Use a faster preset for QTGMC perhaps? Or should I just go with it as is?

[johnmeyer]

Originally Posted by nhope

Can anyone tell me how to correctly change the following script to output BFF instead of TFF?

Just use ComplementParity() before the Weave or SwapFields() after. I think you get the same result either way. I tested, using your script, and it works.

[Gavino]

Originally Posted by johnmeyer

Just use ComplementParity() before the Weave or SwapFields() after. I think you get the same result either way. I tested, using your script, and it works.

That depends on what you're trying to achieve - cf my post above.

Yes, it will change TFF to BFF, but the resulting fields will have incorrect spatial alignment (if they were initially correct).

[johnmeyer]

Originally Posted by Gavino

Yes, it will change TFF to BFF, but the resulting fields will have incorrect spatial alignment (if they were initially correct).

Are you saying that I'll get two top fields in a row and then two bottom fields?

I added an assumebff().separatefields() temporarily to the end of the script, and the temporal order was definitely correct (the initial video was tff), and I thought I saw the usual up/down movement between fields, but I guess I wasn't looking closely. I'll go back and look again.

The only issue I was aware of when changing parity is that you can lose the first and/or last field in the video. But, I'm still learning ...

[sadie]

John, before running off tonight I did finally manage to do a couple of encodes with your script and it pretty much confirms that it's at best a toss-up compared with my qtgmc approach. I incorporated your crop formula to good effect. There is a slight problem though in that your formula gives me an aspect ratio that is noticeably squished horizontally. I adjusted your script for PAL usage (num=25). Perhaps something went askew there. Anyway, thanks for the old college try.

On a quite separate note regarding your 'apology' to Didee, inasmuch as the offended party has re-edited his post for the second time and removed the accusation, maybe you ought to remove your apology as well. As it stands, it actually makes you out to look like the good guy. To be more pointed, your altercation was another example of what unfortunately can happen when people abuse the prerogative to edit their own posts. I can't tell you how many times I've been thrown into a loop when people pulled such stunts with me. IMO an edit should be limited to the odd misspelling or rephrasal or such. But otherwise posts ought to remain in the spirit of what a forum really is supposed to be about: an honest running conversation between two or more parties. And if this means living with errors, omissions and delayed follow-ups so be it. I mean how often to do you go back and reread what what was posted an hour or day ago just to be sure there haven't been any 'updates'? And although it may have had the best intentions, Didee's edit should instead have been a separate follow-up. But as it stood, it made you appear not only to be presumptuous (which you were) but also a liar. I hope he at least sent you a humble little PM owning up to this. In fact his now excised 'accusation' (which by the way broke forum rule No. 9 big time) shouldn't even have appeared in this thread as it concerned a matter in a third-party forum. It should have been handled entirely by PM (or on the Sony site).

With that out of the way, I wish one and all a happy Easter week. Cheers.

[Gavino]

Originally Posted by johnmeyer

I added an assumebff().separatefields() temporarily to the end of the script, and the temporal order was definitely correct (the initial video was tff), and I thought I saw the usual up/down movement between fields, but I guess I wasn't looking closely.

The temporal order is correct, but top field pixels have become bottom field ones and vice versa, so will be displayed in the wrong place in the frame. Look at a still sequence and you will see immediately.

[johnmeyer]

Originally Posted by Gavino

The temporal order is correct, but top field pixels have become bottom field ones and vice versa, so will be displayed in the wrong place in the frame.

I'll have to look at that when I get back to my main computer. I haven't actually used the script fragment I wrote above: I simply read the AVISynth doc, copied the code, and did a quick test which revealed that the temporal order was correct. I didn't see the spatial reversal. If that is happening, then Complementparity is of no use in this situation. I wonder when I would use it ...

In looking at scripts I wrote in the past, when I ended up having to reverse fields one time a few years ago, I wrote the code below, so I must have tried the simpler approach and realized it didn't work. I thought I was solving a tougher problem back then, but I guess it was this same thing.

source=AssumeBFF()

even=source.trim(1,0).separatefields().selecteven
odd=source.separatefields().selectodd
interleave(odd,even)
fixed=weave()

#In the line below, use the OPPOSITE of what you chose above 
#because the fields have now been reversed.

AssumeTFF(fixed)