View Single Post
Old 22nd May 2020, 23:04   #394  |  Link
hello_hello
Registered User
 
Join Date: Mar 2011
Posts: 4,823
Quote:
Originally Posted by Katie Boundary View Post
Digging though the old posts in this thread, I stumbled upon the "QIVTC" script by h_h. It had three obvious problems, all of which I've managed to fix: first, it assumed a field parity that would be wrong 99.999% of the time, so I added a modification that Stainless and I have been working on for my own scripts, which automatically detects and uses the correct field parity. Second, after going through all the trouble of using QTGMC's weird shitty pseudo-motion-interpolation to create something that might look like natively 60 fps content if you were stoned, it decimated down to 23.976 fps for no damn reason. I cut that line out. Third, it used QTGMC's "very slow" preset, which has an extra dependency that the other speed settings don't have and which QTGMC's own documentation admits is a waste of CPU cycles for almost no quality improvement. So I restored it to its default "slower" setting. The final QIVTC looks like this:
The field parity was correct for the source, unlike the scripts for this sample you've uploaded. Is this a sad attempt to distract everyone from that because you didn't notice?

Where did your "Converting boolean values to integers and other AVSI problems" thread go? Did you delete it?

You can do what you like with the function, but don't give me any credit.

The slower the QTGMC preset in progressive mode, the less likely it'll cause "wobbles" in straight lines and sharp edges. Whether "very slow" makes much difference I don't know. I used it because that's what JoelHruska had been using previously, and the idea was to stabilise the picture as much as possible. Obviously you're the QTGMC expert now, so you'd know though....

It decimated to 23.976 because the output desired at the time was 23.976, and it looked quite smooth at the frame rate.

Quote:
Originally Posted by Katie Boundary View Post
That might not seem like a big deal at standard definition, but it'll play hell with AI upscalers. It also shares the same flaws as QTGMC: (a) it's slow, (b) it has lots of dependencies, (c) it bobs everything indiscriminately rather than preserving the original progressive frames whenever possible, and (d) it generates worse interpolation than other temporally-aware bobbers, then tries to hide the bad data by replacing all the good data around it (original scanlines) with more bad data. Basically it's just QTGMC with less aliasing but worse detection and removal of interlacing.
Complete nonsense. TFM field matches the film sections as it always would and only replaces the combed pixels by taking them from the de-interlaced clip in exactly the same way every other example of your method does.

Funnily enough, if lower TFM threshold settings caused it to take more pixels from the QTGMC de-interlaced clip you regularly claim not to like, despite all the evidence posted previously showing it can be better (which you've continually ignored) you're saying that would be better?

The final instance of QTGMC isn't de-interlacing, just smoothing the output.

Quote:
Originally Posted by Katie Boundary View Post
Also, since I'm not a QTGMC guru, I don't know exactly how the script is supposed to work, so all support, maintenance, and further improvement concerns should be directed to h_h and Stainless.
After the long critique on what it's doing, you're now claiming not to know how it's supposed to work?

The idea was to use TFM to field match, but not de-interlace itself, then QTGMC de-interlaces those frames, the logic behind that being the frames being de-interlaced by QTGMC would always be the same frames TFM wants to use to replace the combed pixels later on. Whether it works better or not, I don't know. Other than that it's just another variation of your method, and so far still looks better than any script you've posted.

How about you upload a sample yourself instead of pontificating, so we can compare it to the sample encode I no doubt linked to when I posted the script?

Quote:
Originally Posted by Katie Boundary View Post
This is why I set cthresh and mthresh so low. At this script's settings, lots of interlacing still slips through:
Nonsense. If anything, in hindsight, the combing detection was too sensitive. That was probably the cause of any picture wobbling, but it was an attempt to get through the fades between shots smoothly at 23.976fps, and I think it did that. I've gone off the idea now though, and I'd do a VFR encode instead.

Here's a script showing the pixels TFM is taking to repair combing.

Video = last
A = Video.Tweak(bright=200)
B = Video.Tweak(bright=200)
C = Video.Tfm(field=0,mode=0, MI=20, Slow=2, CThresh=4, Clip2=A, Micmatching=0)
D = Video.Tfm(field=1,mode=0, MI=20, Slow=2, CThresh=4, Clip2=B, Micmatching=0)
Interleave(C,D)


Here's what the frame you posted looks like using the settings from my script (or roughly, I don't know the frame number).


Here's what it looks like using cthresh=2 and mthresh=2.

Video = last
A = Video.Tweak(bright=200)
B = Video.Tweak(bright=200)
C = Video.Tfm(field=0,mode=0, mthresh=2, Slow=2, CThresh=2, Clip2=A, Micmatching=0)
D = Video.Tfm(field=1,mode=0, mthresh=2, Slow=2, CThresh=2, Clip2=B, Micmatching=0)
Interleave(C,D)


The TFM settings from my script.


cthresh=2 and mthresh=2.


The TFM settings from my script.


cthresh=2 and mthresh=2.


Your most recent TFM settings aren't much different. They don't detect any combing in frame 4500 (the first screenshot I used as an example). Try it for yourself.

A = Tweak(bright=200)
B = Tweak(bright=200)
C=Tfm(field=0,mode=0,slow=2,mchroma=false,cthresh=1,MI=30,blockx=4,mthresh=2,clip2=A,micmatching=0)
D=Tfm(field=1,mode=0,slow=2,mchroma=false,cthresh=1,MI=30,blockx=4,mthresh=2,clip2=B,micmatching=0)
interleave(C,D)


How about a sample encode instead of posting nonsense?

Last edited by hello_hello; 23rd May 2020 at 00:15.
hello_hello is offline   Reply With Quote