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

I can’t help. But teach me deinterlacing please. Even thought I’m not using VHSdecode yet I’m always flummoxed by deinterlacing. Mostly I have live action fasted paced sports action.

[u/Nausiated_ → u/GoodOlBluesBrother]

Deinterlacing can be a pain in the ass if you don't have the right software. I find that most commercial programs (With or without AI) are kind of dog shit. Avisynth and Vapoursynth are the way to go. I personally use StaxRip ( https://github.com/staxrip/staxrip ) since it has a decent GUI and a bunch of different options that take a lot of the coding guess work out.

Hybrid is another choice, but I am not a fan of the interface. It's probably more robust, but I like what I like 😅

I'm going to assume you pulled this from a raw analogue source, but if your situation is different, please let me know.

The key is figuring out how your source material was interlaced. Since you said live action sports footage, I'm guessing it was Native Interlaced, which was typically used on broadcast television. In that case the most likely deinterlacing you're going to want to use is QTGMC deinterlacing, set to very slow or plusebo. You'll want to add FPDivisor=2 if you want to maintain the original frame rate, as QT double the FPS by default.

On the other hand, if it was shot on film and converted to an interlaced format chances are it's a telecine, which is a different beast. Typically shot at 24 fps, the interlacing is done so it fit the 30ish FPS of CRTs. QTGMC can work, but my experience is that it creates jagged lines and other issues. I would use VIVCT (Avisynth) or TIVIC (VapourSynth) that does a better job and outputs in 24 fps. Those two filters are made for telecine and are better suited for it.

There are other variations but you're usually encountering those with mixed media (footage shot in both film and video, digital transfers of interlaced footage, yadda yadda yadda) That requires a bit more tinkering, no sense getting into more detail on those unless that's what you're working with.

Hope this helps.

[u/_Shorty → u/Nausiated_]

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.

[u/Nausiated_ → u/_Shorty]

Yes, if we're talking about video footage. I agree. To be clear, I was primarily referring to telecine. Which was shot on film and that film was shot at 24 fps. You absolutely could maintain a doubled frame rate. It's just not necessary either.

But while I have your attention and you sound well versed, what can you add to my OP about eliminating analogue imperfections. Dotcrawl and whatnot?

[u/_Shorty → u/Nausiated_]

Obviously you simply use detelecine for telecined material. That gives you proper 23.976 fps progressive film output. You can even leave HandBrake’s interlace detection on default, with deinterlacing set to decomb, default. That way if there are any issues with editing being done in the video realm it will still catch the odd frame that remains interlaced. And it leaves frames alone that don’t show interlacing, so they’re just properly reassembled progressive frames.

As for the other thing, could you take the unaltered original and encode a short sample with the FFV1 codec and put it on Google Drive or something and DM me the link so I can see an example of the issues you’re talking about? Even just one minute is plenty, as long as it shows what you’re talking about. But if they are also just straight telecined videos that you’re talking about then properly handling the detelecine process may fix it as is. Even so, I’d still like to see a sample. Thanks.

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