Yadif > Tdeint at standard settings. Here's proof

[Katie Boundary]

Source footage: Witchblade, episode 227101, "Diplopia"

Script:

mpeg2source("227101.d2v")

loadcplugin("c:\yadif.dll")

yadif(mode=1)

Frame 39774:

http://img.photobucket.com/albums/v415/DWJohnson/39774%20yadif_zps95n9abot.png

Behold! No interlacing!

Now, the following script:

mpeg2source("227101.d2v")

Tdeint(mode=1)

And again, frame 39774:

http://img.photobucket.com/albums/v415/DWJohnson/39774%20tdeint_zpsxjxkleuq.png

Ugh! Residual interlacing! And while it's not obvious from these stills, there's a lot of ghosting/blending from the next frame too. So, to hell with PSRN and other synthetic tests where Tdeint ekes out a 5% advantage over Yadif. For my bob-deinterlacing needs, I'll use a filter that actually deinterlaces.

[manolito]

There is no doubt that Yadif is a very capable deinterlacer, and when it appeared as an AviSynth C-plugin it got an enthusiastic reception. And it is fast...

But there are some complaints that it has a tendency to create a certain "plastic doll look".

A little later Tritical released YadifMod which is essentially Yadif without an integrated spatial predictor. You need to use a separate spatial predictor like EEDI or NNEEDI or TDeint. Also YadifMod is a regular plugin, not a C-plugin.

I use YadifMod all the time with parameters tritical himself recommended for getting the best bang for the buck (quality vs speed). For bobbing you would use this command line:
yadifmod(mode=1, edeint=tdeint(mode=1, mthreshL=0,mthreshC=0))
and I am very happy with the results.


Cheers
manolito

[kuchikirukia]

. For my bob-deinterlacing needs, I'll use a filter that actually deinterlaces.

So QTGMC?

[wonkey_monkey]

Why is "one filter better than another on a particular frame" news?

[Motenai Yoda]

Yadif < Tdeint at standard settings. Here's proof

Yadif(mode=1)
https://7-t.imgbox.com/f0vyDjaq.jpg (http://imgbox.com/f0vyDjaq)

Yadifmod2(mode=1, edeint=tdeint(mode=1, mthreshL=0,mthreshC=0))
https://9-t.imgbox.com/W0GOayCj.jpg (http://imgbox.com/W0GOayCj)

tdeint(mode=1)
https://9-t.imgbox.com/0of7uukq.jpg (http://imgbox.com/0of7uukq)

nnedi3(field=-2)
https://9-t.imgbox.com/wgN2aF4u.jpg (http://imgbox.com/wgN2aF4u)

tdeint(mode=1,edeint=nnedi3(field=-2))
https://8-t.imgbox.com/kXc9fU3Q.jpg (http://imgbox.com/kXc9fU3Q)

qtgmc(preset="faster")
https://1-t.imgbox.com/BHHiQVnw.jpg (http://imgbox.com/BHHiQVnw)

qtgmc()
https://0-t.imgbox.com/1pWOMJk8.jpg (http://imgbox.com/1pWOMJk8)

tfm(pp=0)
https://2-t.imgbox.com/c4K4VUr2.jpg (http://imgbox.com/c4K4VUr2)

[Groucho2004]

Why is "one filter better than another on a particular frame" news?I'd like to add "How does picking a single frame out of a de-interlaced video help determine the quality of the de-interlacing method?".

[Sharc]

I'd like to add "How does picking a single frame out of a de-interlaced video help determine the quality of the de-interlacing method?".
+1, unless one wants to take still pictures of the movie for the album or whatever.
But even within the same picture one will find structures and patterns which are better preserved with TDeint (less artefacts, sharper/more details) and other structures where yadif looks better (less jaggies).
Not to mention the many tweaking parameters TDeint has, but this is beyond the scope of "default" comparisons of course.

[hello_hello]

Not to mention, de-interlacing is only the first stage on the way to Katie's preferred VCD format. Given that, I'm not sure what the fuss is about as once you're there, you could accuse the tdient version of being less blurred and the downscaling seems to fix any residual combing.

[hello_hello]

qtgmc()
https://0-t.imgbox.com/1pWOMJk8.jpg (http://imgbox.com/1pWOMJk8)

If your screenshot's any indication (green lines down the side) you need an MVTools2 update. Although your screenshot is mod16 so I'm not 100% sure that's the problem.

https://github.com/pinterf/mvtools/releases

[dlnm]

Testing with Avs+ with lastest version of QTGMC (v3.357s) and Mvtools2 (2.7.16.22),
setting lsb=true in QTGMC or using the chain of ConvertBits(16).QTGMC().ConvertBits(8)
should fix the green bar on right hand side.


edit: I mess up with the version number, it should be 2.7.16.22 instead of 2.7.17.22

[hello_hello]

That's odd because I can't induce green bars even with only QTGMC() in a script (Mvtools2 2.7.17.22). I had problems with version 2.7.17.21 but none since upgrading to 2.7.17.22 (Avisynth 2.6.0.6)

QTGMC 3.357s & everything else in this plugin pack (https://forum.doom9.org/showthread.php?p=1806162#post1806162). There's a screenshot showing version numbers (I haven't updated the plugin pack for the new version of nnedi3 (https://github.com/jpsdr/NNEDI3/releases) yet).

[johnmeyer]

The original example in #1 are perhaps some of the least-useful examples of interlacing artifacts that one could provide. Given that the artifacts are buried in the shadows, I doubt very much that any mortal would notice them. The very low light and low contrast may also explain why the algorithm does not yield "perfection," whatever that may be in this case.

[dlnm]

My copy of Mvtools2 should be an old one, updated to 2.7.18.22 fix everything. Thanks.

[Katie Boundary]

So QTGMC?

Requires five other plugins to run. Screw that.

Yadif < Tdeint at standard settings. Here's proof

Sorry but those all look the same, except the one with the green bar.

I'd like to add "How does picking a single frame out of a de-interlaced video help determine the quality of the de-interlacing method?".

It proves that tdeint doesn't reliably deinterlace, which is the whole point of a deinterlacer.

But even within the same picture one will find structures and patterns which are better preserved with TDeint (less artefacts, sharper/more details) and other structures where yadif looks better (less jaggies).

This is true, and I've noticed slightly less jagginess with tdeint sometimes. However, the first priority of any deinterlacer should be that it actually deinterlaces, and tdeint at standard settings doesn't do that very reliably.

The original example in #1 are perhaps some of the least-useful examples of interlacing artifacts that one could provide. Given that the artifacts are buried in the shadows, I doubt very much that any mortal would notice them. The very low light and low contrast may also explain why the algorithm does not yield "perfection," whatever that may be in this case.

The source footage doesn't have that many orphaned fields to begin with, so I went with the first example that I noticed. I can post additional examples if you want, though they'd be from a different show now that I've deleted the Witchblade VOBs.

[kuchikirukia]

Requires five other plugins to run.

So? You put in a lot of effort being terrible at encoding. Perhaps you should change that to things that would make you good.

[hello_hello]

Not that I'd know, and anything's possible, but it seems more likely the Witchblade DVDs would be telecined rather than interlaced.

[wonkey_monkey]

Requires five other plugins to run. Screw that.

Ermaghad, five? Five? That's... like... hundreds!

This one quote sums up rather nicely why KB is unhelpable.

[johnmeyer]

Ermaghad, five? Five? That's... like... hundreds!

This one quote sums up rather nicely why KB is unhelpable.And, don't anyone dare to mention to her that every Windows program makes calls to hundreds of "plugins" (API calls) embedded in Windows; or that most AVISynth scripts call dozens of DLLs (plugins), etc. The designation "plugin" is arbitrary.

The point I am making is that every program has prerequisites for its proper operation. It is complete idiocy to make a decision not to use a particular program because it exceeds some artificial "boundary" especially since that boundary is the direct result of how Windows (and any other environment) is segmented into discrete modules.

The problem with this thread, and most of the others started by this OP, is that she is clearly not doing any of this under any deadline; for any real purpose; and, most importantly, for money. If any of those applied, then the goal would be clear, the deadline important, and any tip or advice that will help produce a better end results, and get to that finish line more quickly, would be very, very welcome, instead of greeted with disdain, scorn, and hostility.

[wonkey_monkey]

The problem with this thread, and most of the others started by this OP, is that she is clearly not doing any of this under any deadline; for any real purpose; and, most importantly, for money.

I don't think that's the problem...

disdain, scorn, and hostility.

That's the problem.

[Groucho2004]

Requires five other plugins to run. Screw that.In most cases it requires just four (masktools2, mvtools2, nnedi3, RgTools) which seems very moderate considering that Avisynth's versatility is based on its plugin sub-system, not to mention that these four are used for many other useful things, not just QTGMC.

I have a conservative and minimalistic approach to video processing but for bobbing/de-interlacing there is simply nothing that beats QTGMC.

However, the recent revisions have added a whole bunch of dependencies (SMDegrain for example which in itself is quite complex). I don't need high bit depth support for my interlaced content so I stick with an older revision (3.31) which only requires the above mentioned plugins.

[Sharc]

Some years ago (when QTGMC was introduced) a forum member presented this clip which I found on my HD. I don't remember the original poster. It's a very nice way how to do the comparison.

http://www.mediafire.com/file/yb57rgd41b4clxu/Bobbing_Nvidia_TGMC_Yadif_tdeint.mkv

[Groucho2004]

Some years ago (when QTGMC was introduced) a forum member presented this clip which I found on my HD. I don't remember the original poster. It's a very nice way how to do the comparison.

http://www.mediafire.com/file/yb57rgd41b4clxu/Bobbing_Nvidia_TGMC_Yadif_tdeint.mkvI remember that clip, I think it was Didée who made/posted it. It also demonstrates quite nicely how meaningless it is to judge the result by looking at single frames. QED.

[videoh]

Does anyone have the source clip used to make that comparison?

[StainlessS]

Does anyone have the source clip used to make that comparison?

I think that this is the Didee post where it was upped to MediaFire (no longer available), but it names the source DVD

https://forum.doom9.org/showthread.php?p=1433847#post1433847

Quite possible. As long as the curtain isn't pulled, the illusion can persist there would be something special underneath.:D - Still, asking wouldn't hurt ... perhaps someone has a weak moment and actually leaks some insight.
Also, what I gathered from the internet: the video engine automatically uses the "highest" method, according to the capabilities of the card, as well as the actual content. Particular example: the GT220/240 is said to use "vector adaptive" deinterlacing only up to SD resolution, but for HD resolution it uses only "temporal" deinterlacing. Such behaviour is understandable, given that the usual application is realtime-playback. Though, for offline processing it could be interesting if it were possible to choose the deinterlacing method to liking. If you contact Nvidia again, maybe you could ask about that, too.

Okay, the comparison ...

Here's a quickly produced sample, from a realworld source: "Lord of the dance", native PAL DVD. To demonstrate clearly, the content was first bobbed, then upscaled 200% with pointresize, and slowed down from 50fps to 12.5 fps. Just to make it easy to see what's really going on.

<sample> (http://www.mediafire.com/?i7znn4nfpvr8nwe) (MediaFire, ~9 MB)

Three of them are more or less about the same. Hard to tell why one of the three should be preferable to the other two. They are exchangeable.

Hence ... if you're in a hurry, then it doesn't matter too much which one you pick. When calling for quality even if it takes longer, then there's not much of a choice.

EDIT: (9MB, same size as Sharc sample, also looks like it could well be Lord of the Dance).

EDIT: Looks like there could well be more than one version of "Lord Of The Dance" PAL DVD.
https://www.amazon.co.uk/Lord-Dance-DVD-Michael-Flatley/dp/B00004R72J

[hello_hello]

That's the problem.

I counted them for fun, given another Katie thread was recently closed. At the moment she's sitting on roughly a 20% average. 20% of the threads she's started have been closed.

[hello_hello]

Some years ago (when QTGMC was introduced) a forum member presented this clip which I found on my HD. I don't remember the original poster. It's a very nice way how to do the comparison.

This is not quite as nice a way to compare (it's not a single file), but I came across a fairly horrid source yesterday. I don't quite understand how it gets to bad... so "shimmery".... for want of a better description, but if you compare identical frames, Yadif is doing better than TDeint at times, yet when you move on a few frames it's the other way around and there's lots of aliasing either way. Yadif blurs more.

I don't know what was inflicted on this video, aside from it being a BBC DVD, almost certainly PAL to begin with and field blended to NTSC (maybe originally 25fps progressive and that's the problem), so it's maybe not the perfect de-interlacing comparison as each method was immediately followed by SRestore(), but QTGMC easily converted the source to the most watchable state, in my opinion, even if for this example it did blur fine background detail a little to get there.

The contestants:

bob() - for Katie for old times sake as I didn't have the heart to separate fields and resize
MCBobu()
qtgmc()
tdeint()
TempGaussMC_beta2u()
yadif()
yadifmod(mode=1, edeint=tdeint(mode=1, mthreshL=0,mthreshC=0)) - a previously suggested yadif/tdeint combination (I think I can see why that'd be better for less challenging sources than Yadif or TDeint alone).

Source included - deinterlacing examples followed by SRestore() each time.

Deinterlacing comparison (with SRestore).zip (https://files.videohelp.com/u/210984/Deinterlacing%20comparison%20(with%20SRestore).zip) (23.5MB)

[Katie Boundary]

You put in a lot of effort being terrible at encoding.

No, I put a lot of effort into being good at encoding things with a different set of priorities than yours. Learn the difference.

The problem with this thread, and most of the others started by this OP, is that she is clearly not doing any of this under any deadline; for any real purpose; and, most importantly, for money. If any of those applied, then the goal would be clear, the deadline important, and any tip or advice that will help produce a better end results, and get to that finish line more quickly, would be very, very welcome, instead of greeted with disdain, scorn, and hostility.

Actually, the problem with this thread, and most others that I start, is that half of the posters - including you - show up for no purpose except to crap all over everything and insult me instead of discussing the actual topic. Have you tried reading the OP? If you had, you'd notice that I'm sharing a discovery with the rest of you, NOT asking for help with anything. On the other hand, if you insist on being illiterate, then I recommend taking your illiteracy elsewhere. As you've already noticed, I don't react well to it.

In most cases it requires just four (masktools2, mvtools2, nnedi3, RgTools) which seems very moderate considering that Avisynth's versatility is based on its plugin sub-system, not to mention that these four are used for many other useful things

...none of which I plan on doing.

I guess I'm just more conservative and minimalist than you :)

Some years ago (when QTGMC was introduced) a forum member presented this clip which I found on my HD. I don't remember the original poster. It's a very nice way how to do the comparison.

http://www.mediafire.com/file/yb57rgd41b4clxu/Bobbing_Nvidia_TGMC_Yadif_tdeint.mkv

Hmmm. Matroska. One of those formats that I can't go through frame-by-frame in Virtualdub.

How very useful.

EDIT: NVM, watched it and saw how the composition made frame-by-framing unnecessary. That's quite impressive. regardless, this thread exists to compare "quick and dirty" bobbers, the kind that someone might want to use for the clip2 parameter in TFM... it's not a "best bobber ever" thread.

[StainlessS]

EDIT: (9MB, same size as Sharc sample, also looks like it could well be Lord of the Dance).

EDIT: Looks like there could well be more than one version of "Lord Of The Dance" PAL DVD.
https://www.amazon.co.uk/Lord-Dance-DVD-Michael-Flatley/dp/B00004R72J

Well it aint Lord of The Dance 2011, this one:-
https://s20.postimg.org/hqagzpgu5/lotd2011_zpsbnivzhza.jpg (https://postimg.org/image/p69qli4jd/)

They had a copy of 2011 in CEX (WeBuy.com), not too far away, and for only £0.50, used, so I got it. But alas not correct version (should have looked at date of Didee post, Sept 2010).

Here is the scene nearest to the one in Didee sample, although they seemed to miss out that scene in particular.
http://www.mediafire.com/file/54n539jz6judi3q/lotd_2011.7z
about 22MB, 45 secs (m2v).

EDIT: CEX:- https://uk.webuy.com/search/index.php?stext=lord+of+the+dance&section=

[Groucho2004]

Requires five other plugins to run. Screw that.

This one quote sums up rather nicely why KB is unhelpable.
After Katie's last post I'm inclined to agree with your "unhelpable" comment.

[hello_hello]

regardless, this thread exists to compare "quick and dirty" bobbers, the kind that someone might want to use fro the clip2 parameter in TFM... it's not a "best bobber ever" thread.

You can't use either Yadif(mode=1) or Tdeint(mode=1) with the clip2 parameter so can you be "bobbing" as such?

You constantly tell other people to read what you've written while claiming they don't understand English, yet the thread title clearing says the thread's purpose is to offer proof Yadif is better than TDeint, supported by your boast you'll "use a filter that actually deinterlaces". If I was to use an alternative de-interlacer via the clip2 option though, it'd probably be QTGMC.

That's a whole other thing anyway. It doesn't matter if it's the dirtiest or bestest de-interlacing if TFM isn't detecting combing and using clip2 to repair it.

[Sharc]

Here another example which I made with a synthetic clip. It's NOT conclusive for natural content, but it shows the differences between the bobbers.
Watch it at its original resolution, otherwise the resizing will introduce new artefacts.
http://www.mediafire.com/file/jd87j494gon4vas/Bobbing2.mkv

[Sharc]

Hmmm. Matroska. One of those formats that I can't go through frame-by-frame in Virtualdub....

Download VirtualDub FilterMod from here:
https://sourceforge.net/projects/vdfiltermod/

[Katie Boundary]

This coming from someone who doesn't know how to synchronize threads.

There are no threads to synchronise. It's hard to believe that you didn't understand my response (https://forum.doom9.org/showthread.php?p=1806931#post1806931) to your bitching about my code. I can only assume that you're having one of your psychotic episodes.

Girls, girls... you're both pretty... if you're going to fight, take it to a different thread, okay?

[manolito]

Looks like I need a better understanding about this whole deinterlacing business... :rolleyes:

First of all why do you even want to deinterlace your source today (when virtually all TVs have a decent built-in hardware deinterlacer)? And most software players also do a good job deinterlacing in real time.

For creating DVDs the conventional wisdom has always been to keep interlaced sources interlaced. For more modern formats like AVC it seems to be common to make it progressive before distributing it, but AFAIK H.264 supports interlaced encoding just fine (not sure about H.265).

But let's just say that you need to deinterlace during conversion, I have a hard time to see the advantage of a super quality deinterlacer like QTGMC. I downloaded a couple of interlaced sample files (real world content shot with a Mini-DV camera), then made tests using the following deinterlacers:
1. Yadif
2. YadifMod with TDeint
3. QTGMC Preset = "Ultra Fast"
4. QTGMC Preset = "Super Fast"
5. QTGMC Preset = "Slower" (the default)

ViT himself once told me that QTGMC only becomes useful for the presets "Super Fast" and better, but I was curious how "Ultra Fast" would fare against "Super Fast".

When watching the converted clips in real time I doubt that anyone would be able to see a quality difference. I watched the clips on a very good Eizo monitor, and the only way to detect reproduceable differences was to step through the frames. And this is not how I watch my movies...

QTGMC Preset = "Slower" did look a little better than the others, but at a speed that was just ridiculous. All the other conversions looked virtually the same even when looking at stills. Even with Yadif alone (by far the fastest) I could not see any residual combing or horizontal shimmering or any other obvious artifacts.


So please can someone give me a link to a (real world) interlaced sample file where the different deinterlacers do make a substantial difference in quality?


Cheers
manolito

[manolito]

Girls, girls... you're both pretty... if you're going to fight, take it to a different thread, okay?
This is by far the best post from Katie which I have ever seen... :D Keep it up!

[hello_hello]

For creating DVDs the conventional wisdom has always been to keep interlaced sources interlaced. For more modern formats like AVC it seems to be common to make it progressive before distributing it, but AFAIK H.264 supports interlaced encoding just fine (not sure about H.265).

I'd imagine a traditional reason for de-interlacing is that it leaves you free to resize however you like, and it's probably still a valid one.


So please can someone give me a link to a (real world) interlaced sample file where the different deinterlacers do make a substantial difference in quality?

https://forum.doom9.org/showthread.php?p=1807026#post1807026

https://forum.videohelp.com/threads/354092-Converting-video-frame-rates#post2225116

Yadif seems to be a lot more "shimmery" when de-interlacing to the original frame rate rather than when it's doubling the frame rate, so it's definitely behind QTGMC deinterlacing to the original frame rate.

This one's not totally fair as it's comparing Yadif at 25fps to QTGMC at 50fps. Quality-wise, Yadif at 50fps would be somewhere in the middle (mainly focusing on how the the text is de-interlaced there). I've probably got some more of those sample encodes somewhere....

https://forum.videohelp.com/threads/354092-Converting-video-frame-rates#post2225237

And of course. You can't us Yadif or Tdeint as a noise filter. ;)
A denoising/stabilising torture test:
https://forum.videohelp.com/threads/358043-A-comparison-of-AVIsynth-denoise-filters#post2283228
I use QTGMC more for noise filtering/stabalising in progressive mode than I do for de-interlacing these days. Even telecined DVD sources would generally be inflicted with something like:

TFM().TDecimate()
QTGMC(InputType=1, Preset="medium", Ezdenoise=1)
LSFMod(strength=50) # maybe
Gradfun3()

[manolito]

Thanks for the links, will have a look later tonight.

The first link is not something I would use for a "real world" test, a file which has been blend-converted to NTSC and then converted back using SRestore is not "real world" in my dictionary...


I do have another question about QTGMC, though:
Contrary to your advice I prefer same rate deinterlacing, and with QTGMC you do this by adding "SelectEven()" after the deinterlacing. How much would it compromise quality if you did the "SelectEven()" BEFORE QTGMC? It would certainly speed up the conversion quite a bit...


Cheers
manolito

[Sharc]

First of all why do you even want to deinterlace your source today (when virtually all TVs have a decent built-in hardware deinterlacer)? And most software players also do a good job deinterlacing in real time.
True, deinterlacers/bobbers/interpolators in TVs and players have greatly improved, but nevertheless there are some typical scenarios which request deinterlacing / bobbing
- One may want to resize vertically for whatever reason
- One may want to apply filters which request progressive video (i.e. fail on interlaced footage)
- One may want to IVTC telecined film, ending up with orphaned fields
- One may want to fix badly authored DVDs
- One may want to try out and compare various deinterlacing principles (adaptive, motion compensated, interpolation) just for fun :)

When watching the converted clips in real time I doubt that anyone would be able to see a quality difference......QTGMC Preset = "Slower" did look a little better than the others, but at a speed that was just ridiculous.
Sure, speed vs quality tradeoff. Speed depends on HW as well and in my opinion speed is not overly critical in "home" scenarios.

So please can someone give me a link to a (real world) interlaced sample file where the different deinterlacers do make a substantial difference in quality?
More like in this example (https://forum.doom9.org/showpost.php?p=1807000&postcount=21)? Take any and watch for example jaggies on nearly horizontal structures. But yes, differences often vanish when watching the movie at normal viewing distance.
(Some people don't even care about the difference between SD and HD on a 50" TV screen: "It's about the same", they say ....)

[hello_hello]

Contrary to your advice I prefer same rate deinterlacing, and with QTGMC you do this by adding "SelectEven()" after the deinterlacing.

But your interlaced DVDs would generally be deinterlaced to double frame rate on playback.

How much would it compromise quality if you did the "SelectEven()" BEFORE QTGMC? It would certainly speed up the conversion quite a bit...

I can't say I've ever thought about it. QTGMC does have it's own option for single frame rate output. I rarely use it so I don't know if the result is much different to QTGMC().SelectEven(), or if it's substantially faster, but for the same frame rate output I'd probably use it in conjunction with the shutter options. They increase motion blur a tad to give the output more of a "film" look, although the effect is subtle. That's what I like the least about Yadif (or even QTGMC) at 25fps. Shimmering aside, single frame rate gives motion a slightly "jittery" feel, at least to me, probably in part due to video sources having less motion blur than film, although it's more noticeable with Yadif.

This'll de-interlace to the original frame rate while increasing motion blur a little:

QTGMC(FPSDivisor=2, ShutterBlur=1, ShutterAngleSrc=30, ShutterAngleOut=180 )[/QUOTE]

The main reason I used a field blended source earlier is I'd been working with it and it was handy, and I almost didn't mention the filed blending because there's very little movement. Someone would've noticed the source is 29.970fps though so I went for full disclosure. I've seen my fair share of "normal" interlaced sources that were just as bad, or almost as bad, so I don't think the field blending removal effects the comprison.
In fact it's a more extreme example of why I think QTGMC generally looks better than hardware de-interlacing on playback.

[johnmeyer]

Looks like I need a better understanding about this whole deinterlacing business... :rolleyes:

First of all why do you even want to deinterlace your source today (when virtually all TVs have a decent built-in hardware deinterlacer)? And most software players also do a good job deinterlacing in real time.Yup. For 90% of the posts in this forum that are about how and/or whether to do deinterlacing, the exercise is a royal waste of time and not needed.

Sharc did a good job listing some of the reasons why, for the other 10%, you do need to deinterlace. Of those he listed, in my experience, they come down to situations where you need to process the video (denoising, resizing, etc.) and the filter you are using does not deal with interlaced video or, even if it does, you can create a better result by using QTGMC (what most people consider "the gold standard") rather than the deinterlacer built into the filter.

The one other reason that I don't think was mentioned is uploading to YouTube (or other streaming service). You will get better results if you do the deinterlacing yourself rather than relying on YouTube.

However, if all you want to do is watch the video on your TV, don't waste your time doing your own deinterlacing. I suppose that a few people might be able to tell the difference between the excellent hardware deinterlacers built into a modern TV set and QTGMC, but most people won't. If you are one of those few, and you have actually confirmed that you can tell the difference by doing a blind A/B comparison, then go for it.

Another thought: how often do you watch the same video? If you're only going to watch it a few times, why waste your time doing something that will make very little difference? The one exception is if you are delivering it to dozens of people (i.e., a client).

Finally, as I've stated many times before, once you deinterlace, you have permanently degraded your video, and you will never get back the original quality. I still believe that future displays may be able to display interlaced video natively (I still don't understand why most of them don't do that today). If such displays are ever made available ("never say never"), then you will feel foolish to have degraded your video. And, despite claims from some people, interlaced video displayed on an interlaced display looks fine because the eye doesn't perceive the temporal differences between alternate scan lines when everything is in motion. You only see those interlaced "teeth" when you do a screen grab, and that freeze frame is totally misleading because it shows the odd and even fields at the same moment in time, something that doesn't happen when the video is playing.

[wonkey_monkey]

I still believe that future displays may be able to display interlaced video natively (I still don't understand why most of them don't do that today).

Because it would have to flicker. I don't want to go back to that!

If something wasn't originally interlaced, and you're going to re-encode it anyway, I say deinterlace back to as close to the original as can, which hopefully means all original pixels. That just makes it so much more compatible - no messing about with deinterlacing settings on a PC, no watching a TV jump around and making a mess of it, as they sometimes do.

[Sharc]

... How much would it compromise quality if you did the "SelectEven()" BEFORE QTGMC? ....
You would throw away both fields of every second interlaced source frame. The bobbed output would probably be jerky, i.e. a frame sequence like A a C c E e .... with information from the odd frames B b D d missing.

[manolito]

Thanks guys for your input, a lot of things to consider...

I probably should mention that I am very "retro". My TV is still an old fashioned CRT (4:3), and I intend to keep it as long as it lives. I really appreciate natural colors and skin tones, and so far no LCD I have seen can match this old CRT (it is one of the later CRT models which does not flicker - it uses the Philips 100 Hz technology).

But your interlaced DVDs would generally be deinterlaced to double frame rate on playback.
Of course not. No deinterlacing at all, the CRT only has analog input so it expects the video field by field.


I did watch the provided samples, and with 1 exception I do not see an edge for QTGMC. I watch the clips in real time (no stepping through single frames), and I do keep a sane distance from the TV or the monitor.

The exception is this clip:
http://www.mediafire.com/file/yb57rgd41b4clxu/Bobbing_Nvidia_TGMC_Yadif_tdeint.mkv
and there is something about it which I cannot explain. The singer in the foreground is not affected by the artifacts at all, it's only those red lights in the background. I would really like to see the source clip.

My conclusion is the same as johnmeyer's:
Don't bother with deinterlacing unless there is a real vital reason to do so. Even resizing and filtering is not such a vital reason to me. Interlaced resizing is not rocket science, and for filtering interlaced content I use StickBoy's JDL_UnFoldFieldsVertical script with great results.


Cheers
manolito

[Motenai Yoda]

And, despite claims from some people, interlaced video displayed on an interlaced display looks fine because the eye doesn't perceive the temporal differences between alternate scan lines when everything is in motion.
nope, you'll never see interlacing on an old crt tv coz when phosphors are exited their light glow into the other fields (like a bobber) and show enough persistence to make fade-in/-out effect (like a blend).
Those fields also have different timing and a slight vertical offset, that can't be showed on a monitor or a nowadays panel without deinterlacing them first, and make impractical all sort of vertical re-sampling to adapt it to different resolutions too.

[lansing]

Here's the comparison sample between TGMC, yadif and TDeint when TGMC was in beta mode back in 2009. Basically, the advantage of TGMC can be seen on any small non-horizontal lines in a panning/zooming shot, where 99% of the other deinterlacers would fail.

Stockholm (http://www.mediafire.com/file/zo05a1aq795tq7r/StockholmA_0-520_Q3_Yadif_MVBobMod_TGMCa4_TDTMM.avi)

[Sharc]

The exception is this clip:
http://www.mediafire.com/file/yb57rgd41b4clxu/Bobbing_Nvidia_TGMC_Yadif_tdeint.mkv
and there is something about it which I cannot explain. The singer in the foreground is not affected by the artifacts at all, it's only those red lights in the background. I would really like to see the source clip.

Watching on CRT TV or PC monitor? Don't you see the artifacts on the singer's cloak and and the 'flicker' on his face, except for the top right TGMC picture which is pretty clean?

[wonkey_monkey]

nope, you'll never see interlacing on an old crt tv coz when phosphors are exited their light glow into the other fields (like a bobber) and show enough persistence to make fade-in/-out effect (like a blend).


There's a compromise to be made, though, between visible flicker and blurring from phosphor persistence.

(it is one of the later CRT models which does not flicker - it uses the Philips 100 Hz technology).

Then it's presumably deinterlacing (and possibly motion compensating) as well, and won't be doing so as well as modern TVs.

To avoid flicker on CRT screens, by the way, it used to be recommended to vertically blur graphics (it may still be the case). VHS releases use to suffer a lot from flicker - Octopussy being one such that I recall. The DVD didn't have this problem, presumably because it was (very slightly) vertically blurred.

[manolito]

Sorry, for the "Stockholm" clip as well as for the Opera House I only see those differences after you guys pointed me to them. (Watching on my Eizo monitor). Maybe my brain works differently from yours... :eek:

When watching a video I concentrate on the content, not on small artifacts which do not destroy the viewing experience at all. Things which do destroy my viewing experience are blocking in dark static areas, station logos and subtitles.


Cheers
manolito

[johnmeyer]

... you'll never see interlacing on an old crt tv coz when phosphors are exited their light glow into the other fields (like a bobber) and show enough persistence to make fade-in/-out effect (like a blend).
Those fields also have different timing and a slight vertical offset, that can't be showed on a monitor or a nowadays panel without deinterlacing them first, and make impractical all sort of vertical re-sampling to adapt it to different resolutions too.Good points. Since I have not actually seen an LCD, or other fast-response display, that can actually display interlaced, I don't know if it would look good, or not. I can see where you might get some line twitter (not flicker) on a slow vertical pan, like the clip provided earlier in this thread.

So, maybe you are correct. I just wished that I had the option, rather than being forced to watch interlaced via a deinterlacer. I'm sure that if a display offered the native interlaced option, it could also still deinterlace, at the user's option.

[Katie Boundary]

First of all why do you even want to deinterlace your source today

People want to deinterlace because interlacing is ugly and it leads to chroma ghosting and properly resizing it is a pain in the ass (and involves deinterlacing anyway) and it drives MPEG-based codecs crazy.

when virtually all TVs have a decent built-in hardware deinterlacer?

My usual workflow looks vaguely like this:

DVD -> Smartripper -> DGIndex -> AVIsynth -> (Choose one: Premiere, Virtualdub, Tsunami MPEG Encoder, Windows Media Encoder)

At no point does a TV ever get involved. Even when I was capturing Dreamcast footage over ten years ago, I ran the Dreamcast through an ATI All-in-Wonder card so I was basically playing Dreamcast games on my PC.

And most software players also do a good job deinterlacing in real time.

That's not very useful when someone wants to edit with the footage, like when they're making a music video.

For creating DVDs the conventional wisdom has always been to keep interlaced sources interlaced.

Approximately 0.0001% of all time that I have ever spent on video editing had anything to do with creating DVDs.

Finally, as I've stated many times before, once you deinterlace, you have permanently degraded your video, and you will never get back the original quality.

Only if your deinterlacer screws with the original scanlines. Yadif, Bob(0,1), and iBob don't, and at standard settings, neither does Tdeint.

On the other hand, compressing interlaced video will often degrade the hell out of it unless you throw insane bitrate at it.