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

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.