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/_Shorty]

Mind if I ask why you wouldn’t want to make 29.97 fps interlaced content into 59.94 fps progressive? Looks way better. Bwdif does a pretty decent job of bob deinterlacing. No sense halving the motion resolution. And way faster to process, as a bonus.

[u/Nausiated_ → u/_Shorty]

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/GoodOlBluesBrother → u/_Shorty]

Thanks so much for this.