Yadif > Tdeint at standard settings. Here's proof [Archive]

Katie Boundary

11th May 2017, 18:30

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

11th May 2017, 20:14

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

11th May 2017, 20:18

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

So QTGMC?

wonkey_monkey

11th May 2017, 20:43

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

Motenai Yoda

11th May 2017, 20:46

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

11th May 2017, 21:08

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

12th May 2017, 08:35

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

12th May 2017, 17:59

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

12th May 2017, 18:14

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

12th May 2017, 19:31

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

12th May 2017, 20:29

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

13th May 2017, 01:32

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

13th May 2017, 04:13

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

Katie Boundary

14th May 2017, 00:44

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

14th May 2017, 01:54

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

14th May 2017, 03:01

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

14th May 2017, 19:47

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

14th May 2017, 20:25

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

14th May 2017, 20:53

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

14th May 2017, 22:03

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

15th May 2017, 09:54

Groucho2004

15th May 2017, 10:16

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

15th May 2017, 12:30

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

StainlessS

15th May 2017, 14:17

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

15th May 2017, 17:40

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

15th May 2017, 18:13

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

15th May 2017, 19:07

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

15th May 2017, 20:10

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

15th May 2017, 20:57

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

15th May 2017, 21:03

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

15th May 2017, 21:39

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

15th May 2017, 23:56

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

16th May 2017, 04:17

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

16th May 2017, 17:23

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

16th May 2017, 17:35

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

16th May 2017, 18:24

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

16th May 2017, 18:42

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

16th May 2017, 19:13

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

16th May 2017, 20:07

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

16th May 2017, 21:17

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

16th May 2017, 21:56

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

16th May 2017, 23:01

... 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

16th May 2017, 23:11

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

16th May 2017, 23:21

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

16th May 2017, 23:27

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

16th May 2017, 23:30

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

17th May 2017, 00:16

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

17th May 2017, 00:17

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

17th May 2017, 00:27

... 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

17th May 2017, 00:48

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.

johnmeyer

17th May 2017, 03:44

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.It doesn't matter what deinterlacer you use: the video is always degraded. It is unavoidable because you have to either throw away spatial information, or interpolate new video at an intermediate point in time, in order to end up with a progressive result. With some deinterlacing approaches, you end up with half the temporal resolution, e.g., going from 60 fields per second to 30 frames per second. Or, you end up with 60 progressive frames, but to do that you have to create fields that didn't exist before that are halfway in time between the original fields. If you follow that wonderful thread MysteryX started a few weeks ago, where he is trying to improve the results of motion estimated frames (the method used by QTGMC, in some modes, to do the deinterlacing), you'll see how often and how badly motion estimation fails.

So, I stand 100% behind my statement that you will always degrade your video when you deinterlace. There is no way around it.

This is not to say that the result looks awful, only that you will have artifacts that weren't there before.

hello_hello

17th May 2017, 06:28

So, I stand 100% behind my statement that you will always degrade your video when you deinterlace. There is no way around it.

So logically, you degrade your interlaced video every time you play it, given the world uses progressive displays these days. There's no way around it.

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....

That's why I bought a Plasma. ;)

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.

Did you watch them on a progressive display or on your CRT? It's amazing what SD CRTs will hide. I remember someone giving me some AVIs of something years and years ago that looked perfectly fine on my CRT TV but even on a CRT computer monitor they were pretty bad and on a larger progressive TV they're almost unwatchable.

Did you look at the first samples I linked to that were de-interlaced before applying SRestore? Because the difference between QTGMC and Yadif or TDient or even my video card's de-interlacing is night and day. I can step through them one at a time and always know when I hit the QTGMC sample.

I'll confess I thought about it a little last night and Yadif may be getting more blame then it deserves from me for low quality in the past. Back in the day when encoding DVDs, it was usually Yadif @ 25fps, Xvid and some amount of downscaling, so the source was treated to a triple slap in the face.

My conclusion is the same as johnmeyer's:
Don't bother with deinterlacing unless there is a real vital reason to do so.

Pre QTGMC I'd probably agree with some of what he said. Post QTGMC I disagree. I doubt we'll ever be using interlaced displays again and as my video card's hardware de-interlacing seems to be on a par with Yadif(mode=1) on a good day, I don't view QTGMC as permanently damaging the source, but rather fixing it. ;)
Plus more people want portable files these days, and de-interlacing when encoding makes it device independent.

Edit: Link to samples deleted until I fix a problem.

Sharc

17th May 2017, 07:17

.... 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......
Absolutely, unfortunately.
If deinterlacing would not distort the picture in some way, all deinterlacers would produce the same perfect output, means the perfect deinterlacer would exist (which it does not).
Take a look at the example here (https://forum.doom9.org/showpost.php?p=1807044&postcount=32): You see 4 different looking results, and unless you know a priori how the original picture looked like you can - after deinterlacing or bobbing - only guess how the original probably looked like.
Unfortunaltely though one has to deinterlace the interlaced motion pictures at some stage for watching it on progressive displays, and it's always a compromise.

hello_hello

17th May 2017, 07:21

So this is new. I created a few QTGMC vs Yadif samples, uploaded them in my previous post, then discovered something odd. I've not seen this caused by deinterlacing before. Both Yadif and QTGMC are doing the same thing, so maybe it's a problem with the source, but after de-interlacing to 50fps the luma appears to be one frame behind the chroma from start to finish. I'll have to play around some more.....

Edit: Idiot of the week award goes to me again. For some reason I cropped before de-interlacing and it wasn't mod4. Doh!

Now to redo the de-interlacing samples.

https://s11.postimg.org/9bpbd0zyn/deinterlacing_problem.jpg (https://postimg.org/image/9bpbd0zyn/)

Sharc

17th May 2017, 07:24

...On the other hand, compressing interlaced video will often degrade the hell out of it unless you throw insane bitrate at it.
Hmmm, not really. But definitly true when you encode interlaced video in progressive scan mode - which is a crime anyway.
x264 has a very efficient interlaced mode btw. (MBAFF). I have never been disappointed.

Sharc

17th May 2017, 07:49

Ugh! Residual interlacing! .....
Just to mention it: If residual interlacing is your main concern there is a simple trick how to get rid of it, namley vertically downscale and re-upscale the deinterlaced (or bobbed) pictures. It is often better than just blur(). How much you can downscale without loosing details depends on the true resolution of the picture.

wonkey_monkey

17th May 2017, 09:11

Just to mention it: If residual interlacing is your main concern there is a simple trick how to get rid of it, namley vertically downscale and re-upscale the deinterlaced (or bobbed) pictures.

I think you'd be better off applying a [1,1] vertical kernel, or [-1,2,2,-1] to keep it a bit sharper.

kuchikirukia

17th May 2017, 17:54

It doesn't matter what deinterlacer you use: the video is always degraded.

It's degraded to start. We don't watch raw interlaced video because it's terrible. It's always deinterlaced. In the olden days it was done with a fading blur due to phosphor persistence on playback. That's far from the best method, since the sharpest part is at half resolution and the fill to break up the combing is the previous field. Interpolation is the way to go. Why use the previous field when you can make one that better fits the current one?

Since video is always deinterlaced to be viewed, the only time the call of "degradation" could be made is if you bake in a worse method than could otherwise be achieved. This isn't an issue with QTGMC since you're not going to find a better deinterlacer. As long as you don't do something stupid afterwards to ruin it like call selecteven(), the result is going to be better than you'll find anywhere else.

I encode videos to watch them so I don't care if a better deinterlacer might come along in 200 years. I'm not going to keep it interlaced and watch it YADIF'd on playback when a better option exists.

johnmeyer

17th May 2017, 18:14

Several people have said that, since the video must be deinterlaced in order to be shown on a modern TV or computer display, that it will always be deinterlaced before it is viewed and therefore no one should worry about the degradation that happens. I understand that argument, but when I archive my video, I don't want to "bake in" the degradation. As I already mentioned, MysteryX's current thread on using motion estimation shows that there can be massive mistakes made by even the best algorithms when trying to guess where the pixels should be located when constructing the new fields needed to turn interlaced into progressive.

As to "raw interlaced video" being terrible, that simply isn't true. The "trick" of refreshing alternate fields at different moments in time in order to cut bandwidth/bitrate requirements is a scheme that has worked just fine for decades. Don't get me wrong, I'm not arguing that interlaced is "better" in any way whatsoever, only that it exists (still -- 1080i) for a fundamental engineering and economic reason, and it would not be part of the standard, and would not still be used, even today, for broadcasting if it truly looked "terrible."

So, my only point is that if all your are doing is cuts-only on raw interlaced footage, and you then plan to archive it, I would strongly recommend leaving it as is.

hello_hello

17th May 2017, 19:15

As I already mentioned, MysteryX's current thread on using motion estimation shows that there can be massive mistakes made by even the best algorithms when trying to guess where the pixels should be located when constructing the new fields needed to turn interlaced into progressive.

Isn't he interpolating whole frames? I'm not saying they have nothing in common, but it sounds a lot harder than interpolating every second scan line to produce a complete frame.

It's kind of like saying "I won't noise filter now because tomorrow there'll be better noise filtering", or "I won't watch the video now because in a couple of years time I'll have a better TV". You have to draw the line somewhere. ;)
Of course keeping the source in it's original form for future encoding can be a good idea even if it's not interlaced. I've de-interlaced with QTGMC while re-encoding a fair bit of the video I originally de-interlaced with Yadif. I've re-encoded a fair bit of progressive video with x264 and better noise filtering (mainly QTGMC in progressive mode), or I've replaced SD versions with HD versions etc.

Take two on creating samples. The source is included. If anyone has a playback de-interlacing option that's better than QTGMC I'd like to know what it is. Until then I'll keep "baking in" the QTGMC repairs rather than watch it being degraded on playback. For my video card, hardware de-interlacing is on a par with Yadif (mode=1). If it wasn't for QTGMC I'd give interlaced encoding more consideration, but whether or not it adds the occasional artefact, the only method I have for viewing the video in a way that it "looks progressive" is to de-interlace it with QTGMC.

The Yadif samples make me feel like I'm watching a video or film. Mode=1 is better, but doesn't give me as much of a "being there" feeling as QTGMC does on a large TV.

QTGMC at 50fps compresses better than Yadif at 25fps, and compression would decrease further if you encoded as interlaced, so at a given bitrate the encoding quality would be higher.
There's some minor compression artefacts/blocking I normally wouldn't live with in the samples, with but I was trying to keep the file sizes down.

deinterlacing.zip (http://www.filedropper.com/deinterlacing) (99MB)

Original (46.9MB)
CRF20:
Yadif (18.1MB)
Yadif Mode 1 (19.8MB)
QTGMC (15.7MB)
Encoded as interlaced - sample not included (21.4MB)

If the same CRF value produced the same quality, encoding after deinterlacing with QTGMC improves compression considerably over encoding as interlaced. Roughly a 25% bitrate reduction for these samples at CFR20. That's not something to dismiss too quickly. And of course, without QTGMC it's still being de-interlaced on playback anyway.

For the de-interlaced samples I used:

Trim(10604,12009)
Deinterlacing()
crop(12, 6, -12, -10)

For the interlaced encoding:

Trim(10604,12009)
crop(12, 8, -12, -8)

I didn't for the samples, but normally I'd resize to square pixels too because anamorphic should die with interlacing. :)

johnmeyer

18th May 2017, 02:17

There is zero difference between interpolating new frames and interpolating new fields. In fact, if you look at the scripts, they basically make new, temporary, half-height "frames" from each field; interpolate between those "frames" in order to double the number of frames; and then interleave and weave to get the final, progressive result. Every single problem that MysteryX is encountering (and which is encountered no matter who does it, and no matter what the technology) has the same problems. You will get massive artifacts on strong vertical objects moving horizontally; on objects which emerge from behind a foreground object; on people's legs as the walk in front of the camera, and lots more.

I've spent a LOT of time with this technology, and when it works it is magic, but when it fails, it looks horrible.

hello_hello

18th May 2017, 03:08

Zero difference still doesn't sound quite right to me. For progressive frame interpolation you're inventing a completely new frame, while for de-interlacing you're inventing a new field and combining it with an existing one.

I've used frame interpolation scripts such as Interframe only a handful of times, and that was enough for me to clearly see every artefact you're referring to and decide not to bother. I've used QTGMC for de interlacing a fair bit and not seen even remotely the same level of artefacts. I've used it in progressive mode for noise removal even more, and still not seen close to the same level of artefacts. That's not to say it's perfect. As a noise filter it can also have side-effects I don't like, but if there was such a thing as a perfect filter I'd use it.

Rather than just discuss the theory though, I'd be interested to know where you think the QTGMC de-interlacing of my sample looks horrible and why you think it looks better to de-interlace on playback, because I can see jagged edges, aliasing in other places, and shimmering etc, but if I de-interlace with QTGMC first, much of that is fixed or greatly reduced. How long will I have to keep watching it being degraded on playback before hardware de-interlacing can do a better job? And QTGMC reduces the amount of noise which for old interlaced video is usually a good thing, in my opinion.

Not to mention the 25% saving in bitrate I can spend on encoding quality that's lost to inefficiency when interlaced video is encoded that way.

johnmeyer

18th May 2017, 20:50

Re-read what I wrote in the last post: once the interlaced video has been separated into fields by either using "separatefields()" or "bob()", the resulting video is completely and totally indistinguishable from a progressive video. No difference whatsoever. The only difference is that, for separatefields, the video being motion-estimated is half height or, for bob, has redundant fields, half of which will be discarded before the motion estimation is finished.

Here is a typical script showing how MVTools motion estimation is used on interlaced video to create progressive output. This is similar to what QTGMC does, but lacks all the amazing little things in that script which dramatically reduce (but not eliminate) artifacts.

#Simple motion-estimated deinterlacer for 29.97 interlaced (NTSC) video

loadplugin("C:\Program Files\AviSynth 2.5\plugins\MVTools\mvtools2.dll")

source = AVISource("E:\fs.avi")

#Separate interlaced video into fields. Even and Odd are from different moments in time.
even = separatefields(source).selecteven
odd = separatefields(source).selectodd

#Create double frame rate for each field
super_even = MSuper(even,pel=2)
super_odd = MSuper(odd, pel=2)

backward_vec_even = MAnalyse(super_even,blksize=16, overlap=4, isb = true, search=3)
forward_vec_even = MAnalyse(super_even,blksize=16, overlap=4, isb = false, search=3)

backward_vec_odd = MAnalyse(super_odd, blksize=16, overlap=4, isb = true, search=3)
forward_vec_odd = MAnalyse(super_odd, blksize=16, overlap=4, isb = false, search=3)

new_even = MFlowFps(even,super_even,backward_vec_even, forward_vec_even, num=60000, den=1001, ml=500)
new_odd = MFlowFps(odd, super_odd, backward_vec_odd, forward_vec_odd, num=60000, den=1001, ml=500)

#Combine fields into progressive 59.94 video
interleave(new_odd,trim(new_even,1,0))
weave()

Katie Boundary

18th May 2017, 21:11

It doesn't matter what deinterlacer you use: the video is always degraded....

(some stuff)

So, I stand 100% behind my statement that you will always degrade your video when you deinterlace.

Negative. As long as you have all of the original information and you know how to separate it from the interpolated information, no degradation has taken place, unless we're using different definitions of the word.

Hmmm, not really. But definitly true when you encode interlaced video in progressive scan mode - which is a crime anyway.
x264 has a very efficient interlaced mode btw. (MBAFF). I have never been disappointed.

I did say "often", not "always", because many codecs do not support interlaced encoding.

vertically downscale and re-upscale the deinterlaced (or bobbed) pictures.

You want me to vertically resize an interlaced (incorrectly deinterlaced) image... twice?

How about no?

johnmeyer

18th May 2017, 21:39

Negative. As long as you have all of the original information and you know how to separate it from the interpolated information, no degradation has taken place, unless we're using different definitions of the word.Good point. If you create 59.97 progressive from 29.97 interlaced, and if the 59.97 progressive contains all the original fields from the 29.97 interlaced, you are correct.

Sharc

18th May 2017, 22:39

You want me to vertically resize an interlaced (incorrectly deinterlaced) image... twice?

How about no?
Some residual combing does not mean incorrectly deinterlaced. Adaptive deinterlacers do not necessarily deinterlace the full picture but only those parts which are found to be combed (depending on threshold settings) as I understand. Means more details from both fields are preserved. Question is whther the residual combing is visible when watching the movie.

johnmeyer

19th May 2017, 00:57

Some residual combing does not mean incorrectly deinterlaced. Adaptive deinterlacers do not necessarily deinterlace the full picture but only those parts which are found to be combed (depending on threshold settings) as I understand. Means more details from both fields are preserved. Question is whther the residual combing is visible when watching the movie.And, if it bothers you, just change the threshold on where the adaptive algorithms switch over.

hello_hello

19th May 2017, 01:26

hello_hello

19th May 2017, 01:30

You want me to vertically resize an interlaced (incorrectly deinterlaced) image... twice?

How about no?

In your case it's not necessary, because as I already pointed out three pages ago (https://forum.doom9.org/showthread.php?p=1806820#post1806820), you invariably reduce it to VCD resolution and that removes the residual combing anyway. Resizing down once is enough.

That's why I don't understand all the fuss you make over IVTC and de-interlacing etc, when your end result is resized to VCD resolution.

johnmeyer

19th May 2017, 05:26

Yeah sure, I'll re-read what you wrote as soon as you've looked at my samples and answered my questions. A request you've now ignored twice. I don't watch video after it's been theoretically de-interlaced. I've mostly watched it after it's been deinterlaced with Yadif or QTGMC for encoding, or deinterlaced on playback (which is often done using Yadif or an inferior method by software players), and I know which I prefer, so until you're willing to discuss some real world examples, there's probably no way for the discussion to go anywhere.

deinterlacing.zip (http://www.filedropper.com/deinterlacing) (99MB)Gee, that's pretty snarky. I was just trying to help. Not sure what's eating you.

I actually spent about half an hour writing and debugging that little script in order to help clarify my point. What a royal waste of time that was. I will not make the same mistake again.

Sorry my answers were not helpful.

hello_hello

19th May 2017, 05:38

Gee, that's pretty snarky. I was just trying to help. Not sure what's eating you.

I actually spent about half an hour writing and debugging that little script in order to help clarify my point. What a royal waste of time that was. I will not make the same mistake again.

Sorry my answers were not helpful.

Having a request to look at samples ignored for the second time isn't conducive to writing a scented post wrapped in a ribbon, although sorry if it came across as snarky. That wasn't my intention.

Likewise though, the samples I uploaded didn't appear out of thin air. They're the ones you've now completely ignored for a third time. We're all trying to be helpful, but wasting time goes both ways....

Edit: I tried your script and while it doubles the frame rate it appears not to be doing any de-interlacing. It's probably something simple but as it is, it appears not to work.

Edit: I just noticed it says for de-interlacing 29.97fps at the top. I don't know if that's the problem, but my source is PAL.

https://s1.postimg.org/gcjpjh5cb/VTS_01_1-002.jpg (https://postimg.org/image/gcjpjh5cb/)

Sharc

19th May 2017, 09:07

Edit: I just noticed it says for de-interlacing 29.97fps at the top. I don't know if that's the problem, but my source is PAL.

I think for PAL you would have at least to adjust the num= and den= values in the script, like num=50000, den=1000 in the new_even and new_odd lines of the script.

nussman

19th May 2017, 09:59

Good point. If you create 59.97 progressive from 29.97 interlaced, and if the 59.97 progressive contains all the original fields from the 29.97 interlaced, you are correct.
Good point? Why?
I agree that the video is always degraded if you deinterlace. That's no problem for video playback and for your archive just keep the original video!

hello_hello

19th May 2017, 10:42

Good point? Why?

The way I understand it, Yadif(mode=1) doesn't alter the existing fields.

I agree that the video is always degraded if you deinterlace. That's no problem for video playback and for your archive just keep the original video!

How is it no problem for video playback? Doesn't it get de-interlaced then too?

I don't think I'd argue that you should re-encode video solely for the purpose of de-interlacing (although thanks to QTGMC I probably would myself), but if you're re-encoding anyway.... and you can still keep the original interlaced video if you want to. There's no rules.

I guess nobody arguing against deinterlacing is going to look at my samples and offer opinion on how QTGMC has degraded the video compared to deinterlacing the source on playback.

hello_hello

19th May 2017, 10:49

I think for PAL you would have at least to adjust the num= and den= values in the script, like num=50000, den=1000 in the new_even and new_odd lines of the script.

Cheers.
I didn't bother looking at the script closely at the time, due to looking at offerings appearing as though it'd be a fairly one-sided exercise. I tried changing them now, however it still seems to leave lots of combing behind.

nussman

19th May 2017, 16:53

How is it no problem for video playback? Doesn't it get de-interlaced then too?

In the context of: "playback deinterlacer" vs "encoder deinterlacer"
It only matters if your "playback deinterlacer" or your "encoder deinterlacer" is superior to the other.

I dont think it makes sense to create 59.97 progressive (including all original fiedls) from 29.97 interlaced.

johnmeyer

19th May 2017, 17:46

Good point? Why?
I agree that the video is always degraded if you deinterlace. That's no problem for video playback and for your archive just keep the original video!I was only agreeing that the original fields could be recovered. However ...

... what I also should have pointed out is that you will NOT actually be able to recover the original fields because ... to get to the deinterlaced result, you will have had to re-encode and that will degrade the fields that were not interpolated.

So, my original statement, with which you agree, is still true: deinterlacing ALWAYS degrades the result.

hello_hello

19th May 2017, 20:02

In the context of: "playback deinterlacer" vs "encoder deinterlacer"
It only matters if your "playback deinterlacer" or your "encoder deinterlacer" is superior to the other.

Which I believe is the case with QTGMC (there's exceptions, but 99% of the time), only nobody will look at the samples to tell my why it's not.

I dont think it makes sense to create 59.97 progressive (including all original fiedls) from 29.97 interlaced.

If you don't, you lose half the temporal resolution.
When you watch an NTSC DVD being de-interlaced by a hardware player on playback, you'd be watching it de-interlaced to 59.94 fps progressive.
If you've compared the two, you can usually see an obvious difference. Especially when the de-interlacing is on a par with Yadif (which most hardware de-interlacing probably is). Nothing against Yadif, but I think it looks much better de-interlacing to 59.94 fps than to 29.970 because it seems to reduce the "shimmering" and other effects of de-interlacing. Plus motion looks much smoother.

In order to de-interlace to 29.970, Yadif must throw one of the existing fields away. To de-interlace to 59.940fps, it keeps them both and creates two new ones.

So, my original statement, with which you agree, is still true: deinterlacing ALWAYS degrades the result.

Maybe you're confusing "changes" with "degrades", because it applies equally to de-interlacing on playback.

I just want someone to look at my QTGMC encoded sample (which obviously you'll continue to ignore), and explain why QTGMC has degraded it more than deinterlacing on playback does, and if it hasn't, why using QTGMC isn't preferable.
Sure QTGMC changes the video. It de-interlaces, but most of the time that change is more like a "repair" than a degradation, given interlaced video is effectively broken in our progressive world. If it wasn't, there'd be no need to de-interlace it to make it watchable.

Not to mention the 25% bitrate saving when de-interlacing with QTGMC compared to encoding interlaced (in my previous test). Another factor that continues to be ignored.

johnmeyer

19th May 2017, 20:09

Edit: I just noticed it says for de-interlacing 29.97fps at the top. I don't know if that's the problem, but my source is PAL.Yes, it's hard-wired for NTSC, as you can see from these hard-wired parameters in the MFlowFPS call:

num=60000, den=1001

Those give you 59.94 fps, double the NTSC frame rate.

raffriff42

19th May 2017, 20:16

It doesn't matter what deinterlacer you use: the video is always degraded.At first I agreed, but then recalled that QTGMC has a Lossless mode (http://avisynth.nl/index.php/QTGMC#Source_Match_.2F_Lossless) that "Puts exact source fields into result" so, in theory (have not tried it) you could recover the original data. So the video is only temporarily degraded...

hello_hello

19th May 2017, 20:34

Why do we keep using the word "degraded"?
It's a bit like saying noise filtering always degrades the video. Sure technically it does as it removes noise, but if the combined effect is an improvement, you'd noise filter. The main difference between noise filtering and de-interlacing is the first is a personal choice, whereas de-interlacing is something you have to do, even if you ignore it until playback time.
Film restoration would count as "degrading" if we just label any output that's not identical to the source as "degraded". Or maybe film restoration is different to de-interlacing because hardware players don't have a "film restoration" mode to enable at playback time.

"Degraded" - "changes look worse"
"Repaired" - "changes look better"
"Different" - "not the same, not better, not worse"

The fact that my samples continue to be ignored (four or five times now) is a fair indication QTGMC is closer to belonging in the "repaired" category, and whichever category you'd put Yadif in, I imagine hardware de-interlacing probably belongs there too.

Katie Boundary

19th May 2017, 22:50

Good point. If you create 59.97 progressive from 29.97 interlaced, and if the 59.97 progressive contains all the original fields from the 29.97 interlaced, you are correct.

:D

Some residual combing does not mean incorrectly deinterlaced.

That's exactly what it means.

I dont think it makes sense to create 59.97 progressive (including all original fiedls) from 29.97 interlaced.

That depends entirely on individual needs, preferences, and circumstances.

you will NOT actually be able to recover the original fields because ... to get to the deinterlaced result, you will have had to re-encode

No you won't.

and that will degrade the fields that were not interpolated.

Not if you use lossless compression. But then again, re-encoding interlaced footage will also degrade it unless you use lossless compression. So interlacing really has nothing to do with the degradation.

So, my original statement, with which you agree, is still true: deinterlacing ALWAYS degrades the result.

No, re-encoding does that.

nussman

20th May 2017, 09:02

If you are deinterlacing the original fields are gone foreever. That's what johnmeyer calls "degradation"?

i.e.: source with 50 fields/s => decoder => deinterlacer => 50 frames/s => encoder
Of course you can do some kind of reverse processing for every step, but the new encoded file with 50 frames/s doesnt contain the information how to do that ("original fields are gone forever").

hello_hello

20th May 2017, 09:50

That happens every time you re-encode interlaced video. It happens every time you encode progressive video. Unless you keep the source, there's no way to recover the original fields/frames. The same could be said to applying any sort of filtering when encoding. What's different about de-interlacing that's it's classed as "degraded" if you apply it when encoding?

Sharc

20th May 2017, 13:05

:
That's exactly what it means.

I have to disagree. Deinterlacing and decombing have different meanings and should not be used exchangably, IMO.
Residual combing is the result of a correctly working (=as intended) deinterlacing algorithm for adaptive deinterlacing which keeps details and spatial resolution from both fields for (quasi) static areas of the picture with no or low motion (sensitivity is defined by threshold parameters) instead of dumping one field and interpolating the kept field. I wouldn't call this "incorrect".

Katie Boundary

21st May 2017, 00:26

Sharc

25th May 2017, 09:38

Four Bobbers for comparison:
http://www.mediafire.com/file/100415dtcxldzp8/PinkFloyd_KB.mkv

The bobbers are interleaved. So when you STEP through the clip you will immediately see the differences in the sequence yadif - TDeint - nnedi3 - QTGMC (all with default parameters)
See for example the artifacts of the (motion blurred) sticks of the drummer around frames 850...900 or 1600...1700, or the aliasing (jaggies, sharpness) of the strings near Gilmours right hand towards the end of the clip (frames 3000+). The question of what you would see during real-time playback is a different story though.

Edit:
Or watch the strings here:
http://www.mediafire.com/file/1d47ipy60klonbu/DNCE_.mkv

or take this example. Do you see any significant difference between the bobbers?
http://www.mediafire.com/file/f23ux2gjf521207/Potter_.mkv

But again, this is frame peeping only. Watching a bobbed film in motion reveals other effects, like bob shimmer for example. If one is undecided which bobber to select one can always encode them interleaved and playback real-time (at n-times framrate) in order to get something of each :D

Katie Boundary

25th May 2017, 15:02

But again, this is frame peeping only. Watching a bobbed film in motion reveals other effects, like bob shimmer for example.

If you're talking about the flickering that occurs along horizontal and near-horizontal lines when converting to 50 or 60 fps with a dumb bobber, then that's also revealed via crawling through the footage frame-by-frame. This effect can really only be hidden by disrupting the frame order.

Speaking of dumb bobbers, my curiosity finally got the better of me and I tried experimenting with QTGMC, only to be reminded that NNEDI3 doesn't work on this computer. Like I said before, dependencies are bad mmmkay?

Groucho2004

25th May 2017, 15:16

Like I said before, dependencies are bad mmmkay?Dependencies are bad? There are countless dependencies between modules of your OS and software you use. Besides, you have most likely installed VC runtimes without knowing it. Many software packages update/install runtimes without asking.

Anyway, you can easily find out what dependencies are missing with AVSMeter. If you have 'Katie' reasons for not installing runtime libraries then you can't be helped in this case unless you use tritical's "original" nnedi3.

hello_hello

25th May 2017, 18:28

If you're talking about the flickering that occurs along horizontal and near-horizontal lines when converting to 50 or 60 fps with a dumb bobber, then that's also revealed via crawling through the footage frame-by-frame. This effect can really only be hidden by disrupting the frame order.

Wrong. The effect is often repaired by QTGMC. Why do you think it's regularly been suggested you try it?
I still don't understand the numerous threads of fuss though, when ultimately you're resizing to VCD resolution anyway. The rest of the fussing hardly matters by comparison.

Speaking of dumb bobbers, my curiosity finally got the better of me and I tried experimenting with QTGMC, only to be reminded that NNEDI3 doesn't work on this computer. Like I said before, dependencies are bad mmmkay?

Dependencies are a fact of life. Still, you complained and argued and ignored your way through the slow progression of separating fields, then to bobbing, then to deinterlacing, so dependencies are no doubt next in the natural order of things..

Sharc

25th May 2017, 18:32

Speaking of dumb bobbers, my curiosity finally got the better of me and I tried experimenting with QTGMC, only to be reminded that NNEDI3 doesn't work on this computer. Like I said before, dependencies are bad mmmkay?
Unless you already did so, it may help to install Vit's original QTGMC package (https://forum.doom9.org/showpost.php?p=1423459&postcount=1) which is downloadable from the first post of his thread, and follow exactly his instructions.

Katie Boundary

26th May 2017, 16:32

Dependencies are bad?

Yes.

There are countless dependencies between modules of your OS and software you use. Besides, you have most likely installed VC runtimes without knowing it. Many software packages update/install runtimes without asking.

That doesn't negate my statement.

Anyway, you can easily find out what dependencies are missing with AVSMeter.

It's not a matter of anything being "missing". It's a matter of nnedi3 being there but the other bits of software refusing to acknowledge it.

If you have 'Katie' reasons for not installing runtime libraries then you can't be helped in this case unless you use tritical's "original" nnedi3.

...? What other nnedi3 would I use? What other nnedi3 even exists?

Unless you already did so, it may help to install Vit's original QTGMC package (https://forum.doom9.org/showpost.php?p=1423459&postcount=1) which is downloadable from the first post of his thread, and follow exactly his instructions.

What are the expected benefits of downgrading from version 3.357 to 3.32? It won't help AVIsynth see nnedi3.