Issue with QTGMC - Video is *not* interlaced if input type is *not* 0

Issue with QTGMC - Video is *not* interlaced if input type is *not* 0 - Printable Version

+- Selur's Little Message Board (https://forum.selur.net)
+-- Forum: Hybrid - Support (https://forum.selur.net/forum-1.html)
+--- Forum: Problems & Questions (https://forum.selur.net/forum-3.html)
+--- Thread: Issue with QTGMC - Video is *not* interlaced if input type is *not* 0 (/thread-1543.html)

Pages: 1 2

Issue with QTGMC - Video is *not* interlaced if input type is *not* 0 - The_Tinkerer - 23.09.2020

Hybrid used to have a "Force" option that dealt with this. That's been removed.

QTGMC has input types of 0, 1, 2, and 3. ONLY 0 is intended for actual interlaced content (although it can be used on content flagged as progressive using the "overwrite input" option).

So for example, if I have a regular progressive Blu-Ray rip of a movie that is extremely grainy or noisy, I can use QTGMC's temporal smoothing by setting the input flag to 1. It's intended by QTGMC that input type 1 means progressive input.

HOWEVER, in order to get Hybrid to generate a script that includes QTGMC, I have to now use the "overwrite input" option to "top field first". Now, Hybrid considers the video to be interlaced, not progressive. This really isn't a problem if the deinterlace function is moved to the top in custom filter order so that it runs first, OR if it runs with other filters that can work with both progressive and interlaced content.

HOWEVER, IF a filter can't work with interlaced content, AND the user wants that filter to run BEFORE QTGMC denoising for progressive videos, Hybrid now assumes the input video is interlaced, and inserts deinterlacing scripting using TDeint *before* the filter. That's not good.

ALSO, IF a filter has settings that are particular to interlaced content, those settings will be enabled by Hybrid, because it is erroneously assuming that the input is interlaced.

Bottom line, QTGMC with an input type other than 0 means progressive input, not interlaced, and Hybrid should not be setting deinterlacing scripting functions if QTGMC does not have input type set to 0.

I'm not sure of the best way to make it do that. Re-implement Force? Or something else? You could for example make it so deinterlacing functions don't get inserted if QTGMC is being used with an input type other than 0, but it doesn't seem right to set an option to overwrite the video input type to interlaced for a progressive video that you only want to denoise using QTGMC.

RE: Issue with QTGMC - Video is *not* interlaced if input type is *not* 0 - Selur - 24.09.2020

Before I try to look into it.
Are you using Avisynth 32/64 or Vapoursynth? (Different QTGMC scripts/filters with different code in Hybrid)

Here's how I understood it so far:
Setting QTGMC-Inputtype to zero means that QTGMC will only take interlaced content.
Setting QTGMC-Inputtype to anything but zero means that QTGMC will only take progressive content.
The output of QTGMC is always progressive content, either because the content already was progressive (or split into fields) or because QTGMC deinterlaced the content.
Setting QTGMC-Inputtype does not change the assumed input type of the source.

Assuming Avisynth is used,...
If:
- your source is detected as interlaced
- your set QTGMC-Inputtype as progressive
- move some filter that does not support interlaced content before QTGMC
Hybrid should depending on "Filtering->Avisynth->Misc->Interlaced handling", either deinterlaced before the filter, filter and reinterlaced or split the content into fields, filter and weave the fields again. Looking at the code there is a bug here in Hybrid, since Hybrid does not switch QTGMC to 'progressive only' once Inputtype not zero is set. I'll fix that.

I'm still not sure what you want or what is going wrong and if fixing the above will fix the problem. Smile

Cu Selur

RE: Issue with QTGMC - Video is *not* interlaced if input type is *not* 0 - The_Tinkerer - 24.09.2020

I'm using AviSynth 32 bit.

You can actually feed QTGMC whatever content you want... you can feed progressive content and set input type to 0, which in some cases can actually work better than using input types 2 or 3, which is what you're "supposed" to use to correct interlacing artifacts on progressive video. You could also feed interlaced content with input types 1 - 3, for creative or experimental reasons.

But as a standard, if QTGMC is used with input types 1 - 3 on progressive video, Hybrid should not be "thinking" that it is interlaced content.

One idea:

- If input type is interlaced (top/bottom field first, either directly from input video, or via "overwrite" option), if QTGMC is selected, set input type to 0 and grey the input type control...

- If input type is progressive, if QTGMC is selected, set input type to 1, and only allow options 1-3 to be set for input type. Hybrid will then insert QTGMC into the AviSynth script and not set any deinterlacing options for filters before it.

If someone wants to run input type 0 on progressive content, they could use the "overwrite input type" control. They will not however be able to run filters that require deinterlacing before it without Hybrid inserting TDeint scripting. Which makes me think the old "Force" option may be the best choice, since it's more versatile.

RE: Issue with QTGMC - Video is *not* interlaced if input type is *not* 0 - Selur - 24.09.2020

Hybrid, during in the scrip creation, doesn't distinguish whether the content was progressive or interlaced from the beginning or whether that was archived by 'overwrite scantype'.

When a filter supports no interlaced content then Hybrid either deinterlaces the content before applying the filter or it splits the content into fields to apply the filter.

Do I get you right, that you want to apply filters that only support progressive content on interlaced content (even if that wracks the frame content) ?

Quote:- If input type is interlaced (top/bottom field first, either directly from input video, or via "overwrite" option), if QTGMC is selected, set input type to 0 and grey the input type control...

- If input type is progressive, if QTGMC is selected, set input type to 1, and only allow options 1-3 to be set for input type. Hybrid will then insert QTGMC into the AviSynth script and not set any deinterlacing options for filters before it.

That does only make sense if you can't change the order of filters.
Because if you can change the filter order the scan type of the content can change before the filter (QTGMC) is applied.

From what I see Hybrid does work correctly and applies the filters with the settings and order it is given by the user.

Cu Selur

RE: Issue with QTGMC - Video is *not* interlaced if input type is *not* 0 - The_Tinkerer - 24.09.2020

(24.09.2020, 15:26)Selur Wrote: Do I get you right, that you want to apply filters that only support progressive content on interlaced content (even if that wracks the frame content) ?

No.

QTGMC input types 1, 2, or 3 mean progressive video. Input type 1 means only denoise (no deinterlace at all), input types 2 and 3 mean try to fix interlacing artifacts on progressive video. If I have progressive video, and want to run QTGMC for denoising only (Input Type = 1), I have to overwrite the input type to top field first (interlaced) just to get QTGMC into the script. With the video now set as interlaced, Hybrid treats it as interlaced, even though it's not, and any filters I want to run before the QTGMC denoising will get (incorrectly) deinterlaced with TDeint or (incorrectly) have interlacing options set. Hybrid does not "know" that QTGMC with Input Type = 1 is denoise only, and "thinks" that the QTGMC line is actually deinterlacing interlaced video, which it is not.

Here is an example:

I have a progressive scan pillar box video that is noisy. I want to use QTGMC with Input Type set to 1 to denoise. I want to crop the black borders first.

The video is 1920x1080, but without the black bars is 1440x1080.

So I crop 240 pixels off of the sides, and move the crop filter above deinterlacing in custom filter order.

This is the result:

[Image: 35iYWYm.png]

With the old "force" option for QTGMC, Hybrid "sees" the content as progressive (which it is), and does NOT insert the bottom four highlighted lines into the script.

That seems to me the easiest and most versatile solution here, as it allows the user to get the script they want.

Otherwise, you could make it so Hybrid inserts QTGMC into the script for progressive video, and does NOT insert any deinterlacing lines or options into the script, if the QTGMC input type is set to 1, 2, or 3.

RE: Issue with QTGMC - Video is *not* interlaced if input type is *not* 0 - Selur - 24.09.2020

Ahh okay, now I get it.
QTGMC is not used since Hybrid assumes no deinterlaced is needed.
-> should be easy to change.

RE: Issue with QTGMC - Video is *not* interlaced if input type is *not* 0 - The_Tinkerer - 24.09.2020

The thing I may have been confusing you with, is for Input Types 2 and 3, "Try to fix interlacing artifacts on progressive video," I have found that in some cases, Input Type 0 actually works better, even though the input video is NOT interlaced. So you may want to just allow QTGMC for progressive video with all input types.

Wink

RE: Issue with QTGMC - Video is *not* interlaced if input type is *not* 0 - shijan - 24.09.2020

Vapoursynth QTGMC acts the same on macOS. Can't see QTGMC in script if progressive input is selected.

RE: Issue with QTGMC - Video is *not* interlaced if input type is *not* 0 - Selur - 24.09.2020

No surprise,.. same code.

RE: Issue with QTGMC - Video is *not* interlaced if input type is *not* 0 - shijan - 24.09.2020

(24.09.2020, 19:15)The_Tinkerer Wrote: The thing I may have been confusing you with, is for Input Types 2 and 3, "Try to fix interlacing artifacts on progressive video," I have found that in some cases, Input Type 0 actually works better, even though the input video is NOT interlaced. So you may want to just allow QTGMC for progressive video with all input types.

Beware to use mode 0 on progressive source. It may work well as noise reduction but same time it will produce jagged artifacts on straight thin lines or on some fine details that looks like lines. Example:
[Image: 4gnSzJ5.jpg]