Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
18th May 2020, 09:24 | #241 | Link | ||
Registered User
Join Date: Mar 2011
Posts: 4,823
|
Quote:
tdeintted = tfm(pp=1).QTGMC(FPSDivisor=2) tfm(clip2=tdeintted).tdecimate() But even then, because the source clip contains lots of aliasing, depending how closely the de-interlaced clip matches the clip TFM wants to repair, replacing combed pixels with QTGMC pixels could possibly cause shimmering that wasn't there before. For DS9, if you change TFM's own de-interlacing it looks like the result will be better. I haven't played with every imaginable combination of settings, but for the VFR encodes I uploaded yesterday, switching to pp=5 and not using a QTGMC deinterlaced clip has produced the best result so far, compared to the rest of the samples I've uploaded, and I played around quite a bit with TFM's settings for those encodes. The VFR encodes are clean enough for repairing the CGI sections with QTGMC to be fairly optional (there's a tad less shimmering than when the source is being IVTC'd by my video card), and even though the CGI section is telecined, VFR rate appears to allow TFM to treat the fades from one shot to the next as purely interlaced (where hard telecine is overlaid on hard telecine with a different field order, I think), and those transitions are quite smooth. I guess my video card does the same, as the source looks smooth through those transitions too, without any combing. The "problem" telecined CGI section is roughly from frame 570 to frame 3000, after decimation. Quote:
Last edited by hello_hello; 18th May 2020 at 13:48. |
||
18th May 2020, 09:49 | #242 | Link |
Registered User
Join Date: May 2020
Location: Canada
Posts: 49
|
There's one other problem that I have only seen briefly mentioned, and that is the abysmal source footage quality in the early seasons of the show. Later season episodes, like Sacrifice of Angels, look pristine by comparison. I've tried various noise filters (as well as no noise filter) after performing the IVTC on the film sections and the result, when upscaled by Topaz, looks like garbage.
Here's a sample of IVTC'd source footage of the station. How can this possibly be upscaled to look okay? sample |
18th May 2020, 10:19 | #243 | Link | |
Registered User
Join Date: Mar 2011
Posts: 4,823
|
Quote:
|
|
18th May 2020, 17:46 | #245 | Link | ||||
Registered User
Join Date: Jan 2015
Posts: 1,048
|
Quote:
Quote:
Quote:
Quote:
Joel, meet the legendary Donald Graft, also known as Neuron2. Back in the old days, he created he original Decomb plugin, which was the preferred deinterlacing tool used in the older versions of READFAG, written by the equally legendary Justin Emerson, also known as ErMaC. He also forked DVD2AVI (another program endorsed by early versions of READFAG) to create DGindex. Decomb has since been made obsolete by Tritical's TIVTC, but DGindex is still in use.
__________________
I ask unusual questions but always give proper thanks to those who give correct and useful answers. Last edited by Katie Boundary; 18th May 2020 at 18:03. |
||||
18th May 2020, 18:29 | #246 | Link |
Useful n00b
Join Date: Jul 2014
Posts: 1,667
|
A little aside on tritical's stuff. It is heavily based on the Decomb design. He made it when I went AWOL on further development of Decomb due to my father's illness. tritical did a fantastic job on picking up the torch. I was actually the first person to develop IVTC based on field-matching plus decimation, although it wasn't my original idea. A poster at Avery Lee's VirtualDub forum first suggested field-matching plus decimation, but he was not a developer. I wish I could remember his name; sadly the forum is now off-line and I can't go look it up. If anybody remembers, please let me know.
Of course the inspiration for DGMPGDec (DGIndex plus DGDecode) was jackei's amazing DVD2AVI. Trying to remember who wrote the first Avisynth DLL working with DVD2AVI...our late and beloved trbarry? Help me out guys. The good old days! Last edited by videoh; 19th May 2020 at 04:10. |
18th May 2020, 19:24 | #247 | Link | |
Registered User
Join Date: May 2020
Posts: 77
|
Hidden dependency: Probably of little interest to anyone except myself (since it's part of one of my own workflows), but in the name of sharing information:
My repair scripts that utilize QTGMC will not run against output from DaVinci Resolve Studio. Once the output has passed through DaVinci Resolve Studio and been converted to 119.88 fps, QTGMC's progressive repair mode will fail to engage (at least, when used in Staxrip). Instead, the application will hang. It will continue to do this, even if the framerate on the DRS output is decimated back to 23.976 fps using ChangeFPS(24000,1001). I am now attempting it on footage that used TDecimate instead of ChangeFPS and will report if it works. You can still engage QTGMC in a standard preset mode, i.e., Quote:
Typically I have 1). processed the DVD footage in AviSynth, 2). changed the frame rate in DaVinci Resolve Studio, and then 3). upscaled the final product in Topaz VEAI. In this workflow I decided to test; 1). changing the frame rate, 2). upscaling the video, and 3). Attempting to process the upscaled footage the same way I typically do, just to see an apples-to-apples comparison of the final output. I did this to avoid throwing data away early in QTGMC before performing the upscale. It took eight days to upscale the video in this fashion, which is why I'm just now reporting on the results of a test that I started like four pages ago. However, my Step #3 cannot be meaningfully applied in this workflow. Not necessarily a problem or anything, just logging that it occurs. Last edited by JoelHruska; 18th May 2020 at 19:43. |
|
18th May 2020, 20:41 | #250 | Link | |
Registered User
Join Date: Mar 2011
Posts: 4,823
|
Quote:
TFM is capable of six different types of deinterlacing. Still, what do I know, so I ran another VFR encode using cthresh=2, mthresh=2 and Yadif as the de-interlaced clip. Aside from the fact you've only got to look at the timecodes to see the low cthresh and mthresh settings cause TFM to think there's much more combing, and therefore to declare multiple slices of the film sections are interlaced instead of telecined, replacing the pixels detected as combed with Yadif pixels causes the same problems as TFMs default de-interlacing. I could tell when TFM was going into interlaced mode for the Katie method, if for no other reason, because the stars would blink out. cthresh=2, mthresh=2, Yadif de-interlacing TFM pp=5 cthresh=2, mthresh=2, Yadif de-interlacing TFM pp=5 manono, I may have debunked my theory that this: DeintClip = TFM(pp=1).Yadif() Should be better than this: DeintClip = Yadif() When I compared the two using Katie's de-interlacing, it sometimes looked better, but other times it didn't, then for the last frame on a scene change where the next shot is mainly black space, I found this. I'm not sure I fully understand why, although it's an example of how much of a progressive frame can be unnecessarily de-interlaced with low cthresh and mthresh settings. Last edited by hello_hello; 18th May 2020 at 23:41. |
|
18th May 2020, 20:57 | #251 | Link |
Registered User
Join Date: Jan 2015
Posts: 1,048
|
Haha yes. When Smartripper was new, monitors were fullscreen, ATI still made "All-in-Wonder" cards, and we all got our anime music videos from Kazaa and Morpheus because Youtube didn't exist yet. I wasn't into video editing back then, but my mentor (Fuzzy Chickens) was, so I have been instructed in the Old Ways
Mpeg2dec3.dll is credited to "MarcFD, Nic, trbarry, Sh0dan and others", but was based on mpeg2dec2, which is credited to Mr. Barry alone. Mpeg2dec2 was in turn based on mpeg2dec, credited to "Dividee and others"
__________________
I ask unusual questions but always give proper thanks to those who give correct and useful answers. Last edited by Katie Boundary; 18th May 2020 at 21:17. |
18th May 2020, 21:07 | #252 | Link |
Registered User
Join Date: Jan 2015
Posts: 1,048
|
h_h, there's something very wrong with your settings or your script. That looks straight YADIFed, with no TFM at all (or like TFM is set to one of its "dumb" deinterlacing modes, which results in the same thing).
__________________
I ask unusual questions but always give proper thanks to those who give correct and useful answers. |
18th May 2020, 21:07 | #253 | Link | |
Registered User
Join Date: Mar 2011
Posts: 4,823
|
Quote:
Why on earth are you outputting 120fps if you're just going to decimate it back to 23.976? The whole idea of 120fps is it's a multiple of both 24 and 60, so even though there's lots of repeated frames the interlaced sections still play at their original speed, as do the film sections. Thinking about it, TDecmiate(mode=7, rate = 23.976) mightn't be the best tool for the job. The output will have a constant frame rate, so to achieve 23.976fps you might end up with the interlaced and film sections effectively playing at the wrong speeds. If the Avisynth output was 23.976fps though, it should be fine. Maybe I'm missing something, but I don't get it. If the output from Avisynth is 23.976 and you're decimating to 23.976, why the conversion to 120fps and back? Aren't you just creating a heap of duplicate frames that you have to process, only to throw them away later? After trying some VFR encodes myself, using TFM for a VFR encode from Avisynth seems like the best method anyway, so I don't know why you wouldn't want to try it. Last edited by hello_hello; 18th May 2020 at 21:10. |
|
18th May 2020, 21:17 | #254 | Link | |||
Registered User
Join Date: Mar 2011
Posts: 4,823
|
Quote:
Quote:
The "good" screenshots used the following script: Quote:
Last edited by hello_hello; 18th May 2020 at 21:36. |
|||
18th May 2020, 21:25 | #255 | Link |
Registered User
Join Date: Jan 2015
Posts: 1,048
|
It shouldn't be taking ANY pixels from YADIF except in the parts that are interlaced, in frames that are interlaced. I've never seen results like that from my own scripts.
__________________
I ask unusual questions but always give proper thanks to those who give correct and useful answers. |
18th May 2020, 21:39 | #256 | Link | |
Registered User
Join Date: Mar 2011
Posts: 4,823
|
Your cthresh and mthresh settings are so low it thinks large chinks are interlaced, although I assume you actually mean combed.
I don't need to get into a debate about it. It's pointless anyway. I can still remember when you argued the evils of IVTC with TFM, or deinterlacing with NNEDI3 and Yadif. I've run quite a few test encodes using the dual TFM method you love, a heavily modified version of it using two QTGMC de-interlaced clips to make it not suck, and encodes using a single instance of TFM with QTGMC de-interlacing that was virtually as good (for when a constant 23.976 frame rate was required), but after trying VFR encoding when poisondeathray linked to a sample of a purely interlaced CGI section, the above VFR output using PP=5 has easily produced the best result. I've linked to sample encodes in quite a few posts if you want to look for yourself, assuming you can play MKVs like the rest of us now, but please don't just tell me I'm wrong or I've used the wrong settings if you think you can do better, because it's easy to upload a sample of your own to prove it. There's links for the sample source files I used earlier in the thread somewhere. Edit: I think this was the first one: https://forum.doom9.org/showthread.p...94#post1906994 Second one here: https://forum.doom9.org/showthread.p...67#post1912067 I joined them like this for encoding: Quote:
https://forum.doom9.org/showthread.p...88#post1912388 CFR sample here: https://forum.doom9.org/showthread.p...41#post1911841 Last edited by hello_hello; 18th May 2020 at 23:22. |
|
18th May 2020, 22:08 | #257 | Link |
Registered User
Join Date: Jan 2015
Posts: 1,048
|
I never argued that those were "evil". Lies like that are why you're on my ignore list.
There is another argument to be made in favor of pp=5, however. My current deinterlacing algorithm heavily favors field-accuracy, the representation of the original fields and frames as accurately as possible in the newly deinterlaced frames, and the minimization of blended frames and residual interlacing. Why? because the obsessive-compulsive demons who whisper in my ear demanded it. It can't fully eliminate visible interlacing without a high false positive rate, which it conceals pretty well with temporally-aware bobbers (Yadifmod2). But there are types of content where that's not the right tradeoff to make, and blending is better than an autistically literal representation of the original content. The most obvious is the aforementioned retrograde field behavior, but fades, credit animations, and a few other effects are harmed less by blending than the rest of the frame is by bobbing. There are also times when the last field of one clip and the first field of the following clip will be interlaced together and encoded as a single frame, which causes their chroma planes to merge; in such cases, each field benefits from being matched and blended with the nearest field from its own clip rather than bobbed. This doesn't mean that cthresh and mthresh should be set higher, however. You can't do that without unacceptable amounts of visible interlacing getting through.
__________________
I ask unusual questions but always give proper thanks to those who give correct and useful answers. Last edited by Katie Boundary; 18th May 2020 at 22:28. |
18th May 2020, 22:30 | #258 | Link | |||
Registered User
Join Date: May 2020
Posts: 77
|
Quote:
Quote:
I wanted to compare the outputs against what native 23.976 fps video looked like, versus video run through progressive repair mode in QTGMC, etc, etc. Quote:
EDIT: Using TDecimate instead of ChangeFPS doesn't change whether or not my repair script will run after DaVinci RS. It still will not. 2 I will not be retaining this workflow. I'm not spending 4 days of upscaling per episode. But as for why I'd try it in the first place? Because I am new at this, and do not know what will work and what will not, and have been willing to burn CPU cycles on things I was pretty sure wouldn't work to see what they could teach me. As one simple example: I noticed using QTGMC in default mode would create an interpolated frame in-between each "regular" frame. After I noticed this, I ran multiple tests to look at the difference between SelectOdd and SelectEven. At one point, I double-ran QTGMC and then tried "SelectOdd,SelectOdd," "SelectOdd,SelectEven", "SelectEven, SelectEven", etc. Why? Because I wanted to understand what kind of output would be produced. All of them were garbage, but some of them were more garbage than others. "Test it and see what it looks like," has been my guiding philosophy on this endeavor. Last edited by JoelHruska; 19th May 2020 at 00:59. |
|||
18th May 2020, 23:07 | #260 | Link | ||
Registered User
Join Date: Mar 2011
Posts: 4,823
|
Quote:
Obviously I'm not on it now though, so you're lying about that, but given you're claiming I'm on it, you couldn't have read my posts, which means you couldn't have replied, and therefore I don't have to bother reading it. I said you "argued the evils". How many times have you accused others of not being able to understand plain English? Quote:
Last edited by hello_hello; 18th May 2020 at 23:47. |
||
Thread Tools | Search this Thread |
Display Modes | |
|
|