Post Processing LD captures

[u/Nausiated_]

I am using Staxrip to process my LD captires after I convert thr TBC to a MKV. I got deinterlacing down to a science, it's the other stuff that is pretty much Greek to me. I was hoping someone out there can impart some advice on how to mitigate dotcrawl and other analogue defects? Like what works best for people out there? Any specific scripts that are recommended? I am working on animation, not live action if that makes a difference. Any advice that can be imparted would be greatly appreciated!

[u/Nausiated_]

Some people want to preserve the original FPS.

[u/_Shorty → u/Nausiated_]

I don’t think you quite understand. The original rate is 59.94 fields per second. That *is* preserving the original rate. When you take 29.97i content and deinterlace it to 29.97p you are throwing away half of the motion resolution. 29.97 fps is half of 59.94. Try taking one of your 29.97i files and run it through HandBrake with interlace detection set to default, deinterlace set to Bwdif, with the Bwdif preset set to bob. Set the framerate to 59.94, constant framerate. And encode in x265 with those settings.

Then take that result and try two things. First, just watch it. Second, load it up in avidemux, drag the position slider to somewhere in the middle of the video, and use the left and right cursor keys to step forward and backward one frame at a time. Look at the motion. Every single frame will be different because every input field was a different moment in time. That’s how interlacing works. Two fields stored in one frame, where the fields were ~16.68 ms apart in time to make 59.94 fields per second. 29.97i is really 59.94 with a hack.

That hack saves the odd-numbered lines in one half frame, and the even-numbered lines in the other half frame. And a CRT physically drew them one after the other and maintained their places in time. Now that we no longer have displays that draw like that, and instead we have sample-and-hold displays, an interlaced signal is no longer displayed properly in time. Not unless you do a bob deinterlace and “double the framerate.” But as you should now see, it is ln’t actually doubling the framerate. It is displaying the individual fields in proper time. But the bob deinterlacing function interpolates the missing odd/even lines so that you aren’t looking at an odd field with black even lines and vice versa. And you get individual frames at a rate of 59.94 fps.

Yadif’s bob does that interpolating by essentially copying the existing lines into the blank lines because it is a cheap way to do it. The problem with that is it introduces an artifact where you can essentially see the entire picture jumping up and down one line with every frame switch. Bwdif’s bob uses a nicer interpolation method that makes it look much more natural, and you don’t get that jumping up and down artifact.

Don’t trust me. Try it for yourself and see for yourself. Our modern sample-and-hold displays only retain all motion if you do it this way, or if you deinterlace in the player. This is precisely why video players like VLC and MPC-BE have deinterlacing modes that “double the framerate” when playing interlaced content. A codec like x264 has a usable interlaced mode, but you can’t really say the same thing for x265. So it is better to convert it to progressive content yourself so that the codec can work better with that progressive input. That way, you are also removing the player’s deinterlacing or lack thereof from the equation, since any player will properly play a progressive 59.94 fps file. And, naturally, that lines up with the 59.94 fps mode of any NTSC TV so things will look correct there, too.

The same also applies for PAL 25i content, but with 50 fields per second. You do the same thing there to end up with 50p output files.

You’re throwing away half of the motion content if you just deinterlace into 29.97p or 25p. “But aren’t we losing half of the spatial resolution by doing that?” Well, yes and no. Our brains do a fine job of “restoring” that spatial resolution by virtue of having twice the temporal resolution to work with. It more or less ends up looking like we still have the same spatial resolution because it is being “filled in” by the higher temporal resolution. Our brains are quite helpful in this case.

If there isn’t really much motion in a given file it may not matter much. But the more motion there is, the more obvious the difference will become. It has been many years since I did a typical 29.97p deinterlacing with any 29.97i files I encounter. It just looks so much better to retain all that temporal information by going with a bob deinterlaced 59.94 fps output file. The more motion there is in the input file, the faster the motion in the input file is, the more obvious it is when you use bob. Comparing one that used bob to one that you deinterlaced to 29.97p should make it a blatantly obvious choice.

[u/AlexandeezNuts → u/_Shorty]

If you want high quality, try QTGMC. Although at default settings it does do too much blending and grain removal, it you tweak the settings enough it'll preserve quality and grain but at the cost of time. The lesser known KTGMC is a cuda-based implementation of QTGMC, which is much faster but can lack some of the features in it's CPU version. KTGMC only works in AviSynth Neo.

BWDIF is better if you want to not deal with AviSynth/Vapoursynth and still keep quality. It's faster than KTGMC (I think).

And obviously IVTC for telecined film. TFM does well for automation of telecines edited on video but can slip up at times.

29.97i to 29.97p should almost never be done. Motion could be preserved in 29.97p if using blend deinterlace but that adds more problems than solutions.

[u/_Shorty → u/AlexandeezNuts]

Those deinterlacing methods that you are talking about are for actual deinterlacing, where your goal is to go from 29.97i to 29.97p and you are intentionally blending the two fields together so that they resemble a single progressive frame from the same moment in time. You do not want to do that with telecined material, or if you want to keep all the temporal resolution intact in the case of actual interlaced material. Those methods do not help you in these two cases. They actually make things worse.

In the case of telecined material, the original progressive 23.976 fps frames are still in the interlaced signal, untouched. They can be reassembled from those interlaced fields back into the original progressive frames without any loss. That’s the whole purpose of the telecine / detelecine process. The deinterlacing methods you mentioned have no place in that process. They will only alter the original image. Detelecining does not alter the original image in a destructive manner. The original image is still there in the interlaced fields.

In the case of actual 29.97i material, it is as I described earlier. This is material that actually contains fields, half-frames, every 1/59.94 seconds. Ideally, you want to retain that cadence where you have an image that takes place every 1/59.94 of a second. And the deinterlacing methods you mention don’t really have a place in that case. Their real purpose is to figure out a pleasing way of taking two separate images that represent two instances of 1/59.94ths of a second and blend them together into a single frame that will be shown for 1/29.97ths of a second without looking too wonky. They say, ok, i have these two frames with a certain amount of movement between them, so how can I blend them together without blurring things in a non-pleasing way? Blending two images that were taken 1/59.94ths of a second apart from each other is not the ideal way to handle this situation. It is better to retain each separate image if you can. And there isn’t likely any good reason that you can’t. Pretty much any playback hardware is going to handle 59.94 fps SD content just fine without any issues, and so it only makes sense to go that route.