MCTemporalDenoise [v1.4.20 - Update 2010/07/02]

[Stereodude]

Stereodude

since you start work on this, will you keep going? I think you can even add basic HBD if you tried (of course not for all setings since not all dlls work with HBD yet)

if you already stopped maybe I will do it myself
At this point in time I wasn't planning on tackling that.

[tormento]

The way I read it, QTGMC needs to identify the noise and then restore it after de-interlacing.
I call it a loss of time, with all the due respect for the author. That's why I never used that filter and I content myself with DGSource native deinterlace.

[hello_hello]

I call it a loss of time, with all the due respect for the author. That's why I never used that filter and I content myself with DGSource native deinterlace.

You could apply the same logic to any denoiser slower than Undot and simply use Undot for all denoising.

[tormento]

You could apply the same logic to any denoiser slower than Undot and simply use Undot for all denoising.



Nope, I apply the logic to what it should be a deinterlacer and instead manage noise too.

[hello_hello]

Nope, I apply the logic to what it should be a deinterlacer and instead manage noise too.

That'd be fine if noise can't interfere with de-interlacing.

Thinking about it, I don't know how to de-interlace with DGSource. Are you referring to FieldDeinterlace? Can you bob-de-interlace to 50/59.94fps that way?

In my opinion, it's really source dependant like every other type of filtering. The harder something is to de-interlace well, and the noisier it is, the better QTGMC compares to other de-interlacers if you let it denoise too. Better to fix the problems while de-interlacing than fix newly created ones after de-interlacing.
If the source is nice and clean you can often get away with simpler de-interlacing methods, although in my opinion QTGMC pretty much always does a better job. And for many de-interlacing methods, you can specify a de-interlaced clip from which to take de-interlaced frames or pixels rather than the de-interlacer doing the de-interlacing itself. Using a clip de-interlaced by QTGMC can sometimes be the best of both worlds, especially if the de-interlacer only takes pixels from the second clip where it detects combing, leaving the rest of the picture untouched.

Here's an example where the SourceMatch and Lossless options for QTGMC aren't a good thing. There's a link to the source. I'd be interested to learn how to de-interlace and denoise it in two steps and arrive at a similar result to QTGMC.

De-interlacing methods compared:

FieldDeinterlace()
QTGMC(EZDenoise=2.5)
QTGMC(FPSDivisor=2, SourceMatch=2, Lossless=2, EZKeepGrain=0.4, Sharpness=0.1, tr2=0)
Yadif(Mode=1)
Yadif()

DGDecode_mpeg2source("D:\DVD1_VTS_01_1.d2v")
Trim(5500,5951)
#Deinterlacing Here
CropResize(0,0, 20,2,-20,-2, InDAR=20.0/11.0, ResizeWO=true)
GradFun3()

Deinterlacing.zip (Deinterlacing_2.zip) (76MB)
Source VTS_01_1.ts (https://files.videohelp.com/u/210984/VTS_01_1.ts) (12MB)

[videoh]

Thinking about it, I don't know how to de-interlace with DGSource. Are you referring to FieldDeinterlace? Can you bob-de-interlace to 50/59.94fps that way? tormento is talking about the bundled CUDA deinterlacers. Yes, there are bobbers and double-rate modes. Read the documentation!

[tormento]

That'd be fine if noise can't interfere with de-interlacing.
If the source is interlaced and comes from a pure digital chain, there is no sense in denoise to deinterlace. You will deal with it later.
Thinking about it, I don't know how to de-interlace with DGSource.
Videoh replied for me.:D

[hello_hello]

If the source is interlaced and comes from a pure digital chain, there is no sense in denoise to deinterlace. You will deal with it later.

There's a qualification you're only just adding. I'm still not sure why a purely digital chain makes a difference though. Is digital noise less likely to interfere with de-interlacing? Is encoder blocking less of a problem when the source is digital?
Chances are a digital source will be cleaner and easier to de-interlace, and as I said previously that means you can sometimes get away with faster de-interlacing, but how does that show it's better to de-interlace and denoise in two steps?

I assume you didn't look at my examples. It's an extreme case, but I'm not sure how it doesn't illustrate my point. I've added the source file to my previous post.

tormento is talking about the bundled CUDA deinterlacers. Yes, there are bobbers and double-rate modes. Read the documentation!

I don't use them, but does that mean the de-interlacing is done by the video card? If so, what sort of quality are we looking at? Yadif type de-interlacing?

[tormento]

Is digital noise less likely to interfere with de-interlacing?
Explain me how a completely digital chain can introduce noise in an interlaced signal that cannot be removed later. Not artifacts, noise.

[Boulder]

Explain me how a completely digital chain can introduce noise. Not artifacts, noise.

If you think that digital means no noise at all, I'm afraid you are quite wrong. I've done and seen enough DV material to know that pure digital sources can be quite noisy indeed. Or consider the camera on your phone. It's digital noise you see there in the final result.

[tormento]

If you think that digital means no noise at all, I'm afraid you are quite wrong.
The only possible noise comes from the video sensor. After signal conversion, no noise is possible anymore. And if the sensor captures interlaced or is treated as interlaced, the noise is digitalized in separate scans, so there is no meaning in denoise it before making the video progressive.

[Boulder]

The noise is still confusing the motion detection, sometimes quite a lot. The whole idea of QTGMC is that it is a motion compensated deinterlacing method. That is why the denoising part is there.

[tormento]

The noise is still confusing the motion detection, sometimes quite a lot. The whole idea of QTGMC is that it is a motion compensated deinterlacing method. That is why the denoising part is there.



How a denoise can be effective in motion compensation when you have to predict vectors having only half of the image at a time, with interlaced lines moreover?

[hello_hello]

Explain me how a completely digital chain can introduce noise in an interlaced signal that cannot be removed later. Not artifacts, noise.

When did we only start talking about purely digital chains?
What difference does it matter if it's interlaced?
If there's noise introduced that can be dealt with after de-interlacing, how is there not noise?
When did artefacts become irrelevant simply because a source is digital?

All your saying is that a digital source will likely be "cleaner" than film or video etc, and therefore it will de-interlace okay using a faster method, which I've acknowledged a few times, but it doesn't explain why de-interlacing and then denoising is necessarily better.

[tormento]

When did we only start talking about why de-interlacing and then denoising is necessarily better.
Simply because denoising works best on full progressive frames: doing it on separated fields is mathematically inconsistent.

It's like wanting to dig a hole with a rake instead of a shovel.

How can you accurately predict a particle movement having only HALF of the path?

[hello_hello]

The only possible noise comes from the video sensor. After signal conversion, no noise is possible anymore. And if the sensor captures interlaced or is treated as interlaced, the noise is digitalized in separate scans, so there is no meaning in denoise it before making the video progressive.

That doesn't make sense to me. Deinterlacing is the process of taking fields, captured at different moments in time, and
making them progressive. Even if it's done by interpolating the missing scanlines to produce full frames, how is that not likely to produce a better result for a clean clip than for one with lots of noise? Is the noise not likely to produce shimmering or aliasing etc, or does the noise in film or video have different properties to digital noise?

"Digital" probably means "less noise" but it just means less noisy clips are easier to deinterlace without visible artefacts, not that dealing with the noise at the same time won't still produce a better result.

[tormento]

That doesn't make sense to me.
How on hell can you effectively denoise a grate of pixels?

Do you have idea of how an intelaced field is made?

You can cleanup the fake frame created by the semifield from whatever noise you have but you are denoising a fake frame, not the picture made by the two semifields together.

Anyway, we are deeply out of topic. I did my tests, you did yours. You have your results, I have mine. Useless to go on.

[hello_hello]

Simply because denoising works best on full progressive frames: doing it on separated fields is mathematically inconsistent.

It's like wanting to dig a hole with a rake instead of a shovel.

How can you accurately predict a particle movement having only HALF of the path?

Why not denoise the interlaced fields first, then de-interlace? Aren't you dealing with the noise from the top fields independently from the bottom fields before turning them into whole frames? That's the real path.

If I'm digging a hole with a rake instead of a shovel, you're digging a hole with de-interlacing artefacts due to aliasing and shimmering caused by noise, and then hoping removing the noise will fix that too.

Obviously you still haven't looked at my samples, so you're discussing the subject with your fingers in your ears, but how about you upload a sample of noisy interlaced digital video and a sample of how it looks after you've deinterlaced and denoised so we can see the magic properties of digital noise and compare de-interlacing with QTGMC?

[tormento]

Why not denoise the interlaced fields first, then de-interlace?
Here (http://forum.doom9.net/showthread.php?p=1691569#post1691569)the short answer. Denoising SMEAR and BLUR information between semiframes.

Here (http://vclab.kaist.ac.kr/tip2017/IEEETIP2017_Choi-07990042.pdf) a nice reading about problems with deinterlacing and denoising.

[hello_hello]

No sample then?

[tormento]

No sample then?
Here (https://www.mediafire.com/file/ri8pusp1rujqdub/VTS_01_1.mkv/file) a very fast encode. Sorry I am really busy today.

[videoh]

I don't use them, but does that mean the de-interlacing is done by the video card? Do you even know what CUDA is? One filter invokes the nVidia algorithm; others use my own algorithms implemented in CUDA.

If so, what sort of quality are we looking at? Yadif type de-interlacing? Excellent quality! As good as QTGMC? Of course not, but the focus is on excellent quality at blazing speed. Yes, there is a yadif-like filter. Read the documentation!

Here, I will help you:

DGTelecide() with modes 2 and 3: Adaptive deinterlacing without field matching. FieldDeinterlace-like but not identical. People often overlook these modes thinking it must be just a field matcher with postprocessing.

DGBob(): Yadif-like.

PVBob(): nVidia algorithm.

[hello_hello]

Here (https://www.mediafire.com/file/ri8pusp1rujqdub/VTS_01_1.mkv/file) a very fast encode. Sorry I am really busy today.

You might need to upload a slower encode later to be in QTGMC's ballpark.
Both encodes upscaled to 1080p by MPC-HC for an easier comparison.

tormento(some settings)

https://i.postimg.cc/kBGG77ZM/tormento.png (https://postimg.cc/kBGG77ZM)

QTGMC(EZDenoise=2.5)

https://i.postimg.cc/w1Wk7xxW/QTGMC.png (https://postimg.cc/w1Wk7xxW)

[tormento]

Both encodes upscaled to 1080p by MPC-HC

.........

Serious?

[hello_hello]

.........

Serious?

No, I really upscaled your screenshot with some crappy blurring upscaler while upscaling my screenshot with something sharp.
I'm fairly sure most people would watch the encodes fullscreen. You may do it differently.

Your encode was anamorphic, so it had to be resized anyway. Mine was cropped and resized to 988x572 before encoding (Spline36Resize, which will probably sharpen it a tad). I wasn't going to bother trying to work out how you cropped your encode and run another one to match, so upscaling them both seemed like the fair compromise.

You're welcome to run another encode using your de-interlacing and denoising, while resizing it to match mine if you really think it's going to make it look like it was de-interlaced with QTGMC, restore detail and fix the aliasing. I posted the script I used with the samples I uploaded. The difference in the screenshots is way more than anything upscaling with the same player and resizing method could cause.

Edit: I just noticed QTGMC anti-aliased the black keys on the keyboard at the far side of the stage. Bummer. Nothing's perfect. :)

[tormento]

No, I really upscaled your screenshot with some crappy blurring upscaler while upscaling my screenshot with something sharp.
MPC is anything but a reliable decoder and there are so many filters you could use to decode the image, not to talk about renderers.
You're welcome to run another encode using your de-interlacing and denoising, while resizing it to match mine
My encode is anamorphic with a SAR of 64:45 because it's the way it's meant to be watched.

[hello_hello]

MPC is anything but a reliable decoder and there are so many filters you could use to decode the image, not to talk about renderers.

So how does one take a screenshot of video without opening it in a player? If any of those points were relevant, wouldn't they still be relevant if I didn't upscale?
The same renderer was used each time. LAV decoded each time. ffdshow converted the video to RGB each time. MPC-HC used the same upscaling method each time. There was no other filtering.

My encode is anamorphic with a SAR of 64:45 because it's the way it's meant to be watched.

My encode was resized to square pixel dimensions based on a source SAR of 16:11 due to the amount of black down each side (an input DAR of 20:11 rather than 16:9, or 704x576 = 16:9). As a result, I had to tell MPC-HC to stretch your encode to the correct DAR for the screenshot. :)

CropResize tells me the cropping and InDAR specified:

CropResize(0,0, 20,2,-20,-2, InDAR=20.0/11.0, ResizeWO=true)

Resulted in:

Crop(20,2,-20,2)
Spline36Resize(988,572, 0.38,0,-0.38,0)

Using a 16:9 InDAR for CropResize it would have been:

Crop(20,2,-20,2)
Spline36Resize(964,572, 1.09,0,-1.09,0)

None of that has any real relevance to the difference in detail or amount of aliasing between encodes though, but if you think it does, feel free to download my sample and create a more accurate screenshot.

[StainlessS]

(Spline36Resize, which will probably sharpen it a tad).

You sure bout that HH, twas my understanding that Spline36Resize was neutral, and that Spline64Resize sharpens.

[hello_hello]

You sure bout that HH, twas my understanding that Spline36Resize was neutral, and that Spline64Resize sharpens.

Everyone wants to argue today. :)

Yes, it does seem to sharpen a little. It's probably close to neutral, but not quite.

All I can tell you is I've compared anamorphic encodes with encodes resized to square pixel dimensions (Spine36Resize), both upscaled to 1080p the same way, and the "square pixel" encodes invariably look a bit sharper.

Here's some screenshots from a long time ago (click on the thumbnails for the full size version). The first two screenshots are encodes upscaled to 1080p using MPC-HC's Bilinear resizing. One was encoded as anamorphic and the other resized to 1024x576 for encoding. The latter definitely looks sharper after upscaling.

The second two screenshots are upscaled with MPC-HC's Bicubic resizing, and once again the square pixel encode looks sharper.

https://forum.videohelp.com/threads/378501-Resolution-Bitrate-and-Quality#post2444902

Maybe it's the two-stage resizing that causes the sharpening. I don't know, but resizing an anamorphic source to square pixels with Spline36Resize will definitely make an encode look sharper when it's running fullscreen. There's been a few times when the source has been over-sharpened out of the box, and I've had to resize to square pixel dimensions with a softer resizer to compensate, especially when my TV is upscaling, as it's upscaling it fairly sharp.

The effect is probably more noticeable when resizing PAL to square pixel dimensions than for NTSC, as there's more resizing involved for PAL.

It probably easy to test by simply opening an anamorphic source in a script and upscaling it this way:

Spline36Resize(1024,576) # Assuming PAL
SomeResizing(1920,1080)

Compared to this way:

SomeResizing(1920,1080)

[StainlessS]

Everyone wants to argue today

Not arguing, just requesting verification of your statement.
I usually use Spline36 as neutral resize, is there one you recommend as better alternative.

[Boulder]

Not arguing, just requesting verification of your statement.
I usually use Spline36 as neutral resize, is there one you recommend as better alternative.

Do you need something for cases where you downsize, encode and playback at the original size?

We are so off-topic here :D

[StainlessS]

Just a general up/down size.

But, what do you think bout MCTemporalDenoise v1,.4.20 Update ? :)

[tormento]

So how does one take a screenshot of video without opening it in a player?
Personally I use DGIndexNV. You can try AviDemux or VirtualDub2 too.
The same renderer was used each time.
You meant decoder, right? Renderer is the part of the software that create the image on the screen. Which renderer did you use? DX9? DX11? EVR? System default?
My encode was resized to square pixel
The encode should always maximize quality and respect SAR.
on a source SAR of 12:11
You are doing bit of confusion. 16/9 DVDs almost always have SAR of 64:45. The VOB you linked me has a specific SAR of 64:45. You can look at it with FFMpeg.
CropResize tells me the cropping and InDAR specified:
You rely too much on software and too little on knowledge, no offense. Play a bit with FFMpeg, ARS calculator and raw material.

[tormento]

Everyone wants to argue today.
Nobody wants to argue, just being technically correct.

Did you have the time to read the thread and paper I linked you?

[Boulder]

But, what do you think bout MCTemporalDenoise v1,.4.20 Update ? :)
It used to be my go-to denoiser at light settings.
Nowadays I have a horrible custom script using stolen ideas off other more capable users.
Just a general up/down size.
Downsizing with Bicubic with an unorthodox combination of b and c is in my toolbox since a long time. I downsize with Bicubic to 720p, 1080p or 1440p and playback at 2160p, so I always do a run with Zopti to try to keep the resizing parameters optimal. They vary quite a lot depending on the source.

[hello_hello]

Not arguing, just requesting verification of your statement.
I usually use Spline36 as neutral resize, is there one you recommend as better alternative.

I've been playing around, and I'll confess I haven't been able to produce the same sharpening effect today as I have in the past. Take everything I said with a grain of salt and assume the screenshots I linked to were a figment of my imagination. Maybe it depends how sharp the video is to begin with, but at the moment Spline36resize is looking pretty neutral. The source I've been playing with isn't particularly sharp, but I can't produce the same result again. Sigh.....

[hello_hello]

Personally I use DGIndexNV. You can try AviDemux or VirtualDub2 too.

You meant decoder, right? Renderer is the part of the software that create the image on the screen. Which renderer did you use? DX9? DX11? EVR? System default?

I meant the renderer. WMR9. As I said, LAV was decoding.

MPC-HC is perfectly reliable for comparing video. Here it is displaying the same video 5 times simultaneously. Do they look different?

https://i.postimg.cc/r03SKfxZ/MPC-HC.jpg (https://postimg.cc/r03SKfxZ)

The encode should always maximize quality and respect SAR.

I did respect the original SAR and I cropped and resized accordingly. We just don't agree as to what that SAR should be.
I resize to square pixel dimensions because the USB player built into the TV here assumes all MP4/MKV video is non anamorphic and won't resize anamorphic video correctly.

You are doing bit of confusion. 16/9 DVDs almost always have SAR of 64:45. The VOB you linked me has a specific SAR of 64:45. You can look at it with FFMpeg.

ffmpeg probably defaults to 64:45 just like most other software. It doesn't mean it's correct. It just means the correct SAR isn't ever stored in the DVD video stream.
Most modern DVDs are in fact 64:45, but due to the amount of crud down the sides and the age of the source, I doubt that's one of them. I chose to use the mpeg4 DAR, which is easy to remember and almost identical to the ITU DAR/SAR used for digitising analogue video, which is probably what the source was.
https://forum.doom9.org/showthread.php?p=1058927#post1058927

You rely too much on software and too little on knowledge, no offense. Play a bit with FFMpeg, ARS calculator and raw material.

I was using a function I created for cropping and resizing, while specifying the DAR I wanted to use for the source. The function adjusts the cropping to prevent aspect error based on the input DAR/SAR and resizing, because I was sick to death of having to use a resize calculator to prevent aspect error when resizing.
https://forum.doom9.org/showthread.php?t=176667
You decided the source was 16:9 because you relied on ffmpeg to know the unknowable, while I decided it was 20:11, and I still think that's more likely to be correct.

DAR 16:9 or SAR 64:45, cropped and resized to square pixel dimensions.

https://i.postimg.cc/ykv33sgG/16-9.jpg (https://postimg.cc/ykv33sgG)

DAR 20:11 or SAR 16:11, cropped and resized to square pixel dimensions.

https://i.postimg.cc/G4t8kVvm/20-11.jpg (https://postimg.cc/G4t8kVvm)

[hello_hello]

Did you have the time to read the thread and paper I linked you?

I've glanced at it but not read it thoroughly yet. I'm not sure it even applies to this discussion.
Plus I'm waiting for a "better than QTGMC" de-interlacing before denoising sample so I know I need to. :)

[hello_hello]

We are so off-topic here

If a mod comes along, could they please split the non-MCTD discussion off to a new thread?

Probably from somewhere around here.
https://forum.doom9.org/showthread.php?p=1908323#post1908323

[poisondeathray]

DAR 16:9 or SAR 64:45, cropped and resized to square pixel dimensions.

https://i.postimg.cc/ykv33sgG/16-9.jpg (https://postimg.cc/ykv33sgG)

DAR 20:11 or SAR 16:11, cropped and resized to square pixel dimensions.

https://i.postimg.cc/G4t8kVvm/20-11.jpg (https://postimg.cc/G4t8kVvm)



I'm not a musician, but the drum on the ground (bass drum?) - I think it's usually "circular" .

If you use that as a "circular reference" :D , then that lower image is too wide

[tormento]

MPC-HC is perfectly reliable for comparing video.
Not true. It can produce multiple times the same image but the image itself is not the correct one for multiple reasons, such as: which hardware you are using to decode, which renderer you are using to show, etc. The only, theoretically correct image, is a software produced one, unless you accept some compromises in chroma, fast decoding routines and so on. The purpose of a player is to keep a constant flow of motion, not to produce the perfect image. The fact itself you consider a player a "perfectly reliable" source speaks for itself.
I did respect the original SAR
Not true. Your screenshots speak for themselves.
ffmpeg probably defaults to 64:45 just like most other software
Errr.... which ones? Moreover FFMpeg has the capability to report the correct SAR for video streams, it doesn't "default" anything. Recently I had to convert some hundreds of DVDs to mkv and every single one had its own SAR, such as 64:45 (the majority), 10:11 and even odder ones. FFmpeg reported each one of them correctly.
It just means the correct SAR isn't ever stored in the DVD video stream.
WTF are you saying? :eek:

Feed ffmpeg.exe -filter:v idet -frames:v 5000 -an -f rawvideo -y null -i with every VOB you have and tell me.
You decided the source was 16:9 because you relied on ffmpeg to know the unknowable, while I decided it was 20:11, and I still think that's more likely to be correct.
Yeah, the oval drum. :rolleyes:

Please don't reply anymore with what you believe, please reply with tecnically consistent proven facts.

P.S: You uploaded jpg images. You know that jpeg is a lossy format, don't you?

[Sharc]

Errr.... which ones? Moreover FFMpeg has the capability to report the correct SAR for video streams, it doesn't "default" anything. Recently I had to convert some hundreds of DVDs to mkv and every single one had its own SAR, such as 64:45 (the majority), 10:11 and even odder ones. FFmpeg reported each one of them correctly.

WTF are you saying? :eek:

Feed ffmpeg.exe -filter:v idet -frames:v 5000 -an -f rawvideo -y null -i with every VOB you have and tell me.


If I am not mistaken the SAR which ffmpeg reports for DVD VOBs is a calculated value from DAR and frame resolution. DVDs do not specify the PAR (or SAR) in the video stream, only the DAR (4:3, 16:9) and the resolution is given. If the PAR or SAR would be included in the DVD video stream all the past debates about correct resizing (ITU or generic) would become obsolete.

[tormento]

If I am not mistaken the SAR which ffmpeg reports for DVD VOBs is a calculated value from DAR and frame resolution.
One point more to tell it's NOT a "default" value.

[Boulder]

tormento, this whole thing of denoising is clearly a matter of opinion, as always, but I still need to ask one question.
Why are you so concerned what comes to denoising as part of the internal operating process of QTGMC? It was already like that in the original script (TempGaussMC_beta2), as a method to calm the bobbed result.
As far as I know, you do like denoised results instead of keeping the grain.

[tormento]

Why are you so concerned what comes to denoising as part of the internal operating process of QTGMC?
I already answered to this some posts ago. In my opinion it's a loss of time and could ruin the result of deinterlacing smudging spurious values to semiframes.

The fact the output "looks nice" doesn't mean it's the correct one.

[Sharc]

One point more to tell it's NOT a "default" value.
Agree, but it can be wrong or at least misleading (cropping black borders discussions, 704 vs 720 width, 2.4% aspect ratio error etc.)

[tormento]

Agree, but it can be wrong or at least misleading (cropping black borders discussions, 704 vs 720 width, 2.4% aspect ratio error etc.)
SAR must been calculated BEFORE any crop. It measures the "squareness" of a pixel, thus it's independent from the final chosen cropped size.

SAR, DAR, PAR are different nonetheless related things.

GSpot gives an idea of those, even requiring some understanding: i.e. on a 64:45 SAR DVD, it reports a SAR of 5:4, PAR of 1.422 (64:45) and DAR of 16;9.

To render the correct SAR, you need to set SAR as 64:45 during encoding.

[Boulder]

The fact the output "looks nice" doesn't mean it's the correct one.

What? I thought video enthusiasts are looking to create results that please their brains. At least I don't know what is the correct result of denoising, I only know what I like and what I don't and work with that. At this age, I already know my limitations quite well.

[tormento]

I thought video enthusiasts are looking to create results that please their brains.
I call them biased results. Personally I try to keep, even while denoising, the final result as close as possible to original one. I degrain simply because it's a side effect of poor technology, not an artistic choice. There are exceptions, where grain is put in postproduction to deliberately give that effect. Anyway, when I look with my eyes at the world, I see no grain, that's why I remove it.

[Sharc]

I already answered to this some posts ago. In my opinion it's a loss of time and could ruin the result of deinterlacing smudging spurious values to semiframes.

The fact the output "looks nice" doesn't mean it's the correct one.
I just recall this discussion from 2004:
https://forum.doom9.org/showthread.php?t=86394
Summarized here:
https://forum.doom9.org/showpost.php?p=595148&postcount=48