Unwinding erratic interlacing.

[JoelHruska]

I have a question about erratic interlacing patterns and the best way to deal with them. I have a source that has resisted all of my attempts to deinterlace it with various software applications. The end result is always shot through with interlacing errors. My usual techniques for dealing with this problem, like combining QTGMC with a Repair() call have all failed. This is a PAL source and almost all of my experience is with NTSC.

When I dumped the VOB to frames using ffmpeg, I see a very unusual interlacing pattern. Looks like this:

3p
2i
2p / 2i (repeats 3x)
3p
1i (scene change after the single frame)
2p
2i
2p
1i
3p
2i
3p
1i

I'm dumping frames to disk with the command "ffmpeg -i input.mp4 %06d.png"

Do deinterlacers struggle in scenarios where the interlacing is erratic and not consistently applied? What creates this kind of mess and can it be unwound?

[manono]

Do deinterlacers struggle in scenarios where the interlacing is erratic and not consistently applied?

No. Ordinarily they'll deinterlace everything, whether it needs it or not.

What creates this kind of mess and can it be unwound?

If you still see interlacing after the use of QTGMC, then perhaps it was resized while still interlaced. You should make available an untouched sample.

[poisondeathray]

I have a question about erratic interlacing patterns and the best way to deal with them. I have a source that has resisted all of my attempts to deinterlace it with various software applications. The end result is always shot through with interlacing errors. My usual techniques for dealing with this problem, like combining QTGMC with a Repair() call have all failed. This is a PAL source and almost all of my experience is with NTSC.

When I dumped the VOB to frames using ffmpeg, I see a very unusual interlacing pattern. Looks like this:

3p
2i
2p / 2i (repeats 3x)
3p
1i (scene change after the single frame)
2p
2i
2p
1i
3p
2i
3p
1i

I'm dumping frames to disk with the command "ffmpeg -i input.mp4 %06d.png"

Do deinterlacers struggle in scenarios where the interlacing is erratic and not consistently applied? What creates this kind of mess and can it be unwound?

post a sample of the original source

note that sometimes ffmpeg can have issues with vob timestamps .

I'm dumping frames to disk with the command "ffmpeg -i input.mp4 %06d.png"

vob or mp4 ? where did the mp4 come from ?

If you're looking at "frames", and not examining individual fields, you can get confused with the pattern. eg. An "interlaced" frame (one that superfically has combing) might actually be progressive but field shifted

Irregular patterns on a DVD can be from VFR mixed content, bad post production edits (eg. editing progressive content while in fields, before removing pulldown - thereby interrupting cadence)

[JoelHruska]

"vob or mp4 ? where did the mp4 come from ?"

It's a VOB. "input.mp4" was meant to stand in for any generic file. Sorry about the confusion.

I'll get it uploaded.

[JoelHruska]

https://1drv.ms/u/s!AphTLFRW13WMkDyFpRLlCmUPH_fF?e=tynuOs

The source identifies as a BFF interlaced file in MediaInfo but QTGMC does nothing to help. Nothing I've tried has had the slightest impact. This specific error pattern is not immediately visible but begins around 5s into the video.

[poisondeathray]

It's what manono mentioned above -

Portions have been vertically resized, while still interlaced. This co-mingles the fields. Not much you can do about it

There are some approaches and scripts that try to reduce visual impact of defects - but none of them are remotely passable as "decent"

Another approach is to replace specific "bad" frames, either with duplicates or motion interpolated (synthesized) frames . (The latter approach can have many issues, other types of artifacts, but might work well on some sections; it's really content dependent)

[johnmeyer]

A sample is essential.

TFM is a field matcher and can sometimes be helpful.

Also, it is possible you have some sort of pulldown, even though it is PAL. Deinterlacing and inverse telecine are not the same thing, and if you use QTGMC (or any other deinterlacer) on a source that has duplicate fields (pulldown), then you will not get pleasant results.

A sample is essential.

[JoelHruska]

The sample link is above, but based on what some others have said, this may not be repairable.

[davexnet]

The sample link is above, but based on what some others have said, this may not be repairable.

yes, we see a lot of these problems in the forum, the source is progressive not interlaced,
those corruptions can not be separated, but sometimes some creative solutions have been found to mitigate
it slightly.

[JoelHruska]

"yes, we see a lot of these problems in the forum, the source is progressive not interlaced, those corruptions can not be separated, but sometimes some creative solutions have been found to mitigate it slightly."

When you say the source is progressive, how do you make that determination? Both Hybrid and MediaInfo report that the VOB is a BFF interlaced file.

[davexnet]

"yes, we see a lot of these problems in the forum, the source is progressive not interlaced, those corruptions can not be separated, but sometimes some creative solutions have been found to mitigate it slightly."

When you say the source is progressive, how do you make that determination? Both Hybrid and MediaInfo report that the VOB is a BFF interlaced file.

That may be so, but this is what is recorded in the files header, not an examination of the actual frames.
You can use a simple bob() in the Avisynth script and instead of seeing 50 unique frames,
it's the original 25 frames just repeated up to 50

[poisondeathray]

The sample link is above, but based on what some others have said, this may not be repairable.

Some sections are "decently repairable" by interpolation - because you have interspersed "good" frames to use as reference points to interpolate from.

There are more advanced algorithms now than mvtools2 - machine learning ones such as DAIN, RIFE (RIFE is available in vapoursynth) that are slightly better in some areas that can significantly reduce artifacts in some scenarios (but with other limitations compared to mvtools2). There is some discussion on doom9 and other forums about pros/cons if you 're interested

This method involves a bit of work, because you have to specify frame ranges to replace. And if there are bad enough artifacts from 1 algorithm, you might want to resort to method b, or c or d on some frames. It depends on how much time/effort you want to put into it. It's not as simple as somefilter() - boom! you're done

You also have frame drops/ jumps in motion. Likely it was 29.97 originally and drop frame converted to 25 fps since there are about 5 obvious jumps in 157 frames. There are ways to return it back to smoother 29.97, using basically the same method. Insert a "placeholder" frame at the jump site, then interpolate over that.


Here is an demo/example using motion interpolation to "fix" bad frames on a test section

Test1.mp4 attached below is using only mvtools2 interpolation using the RX function I wrote a long time ago . You just specify the starting "bad" frame to replace, and how many consecutive. For example RX(6,2) would replace 6,7 using frames 5 and 8 as reference points. The demo vid is slowed down to ~1/2 speed (12fps)

This gif illustrates typical optical flow edge morphing artifacts contrasted to rife's cleaner output (mvtools2 prototypical edge artifacts can occurs with other algorithms too, and commercial ones like twixtor, kronos, resolve's of, etc... not just mvtools2)

[Attachment 60111 - Click to enlarge]

Test2.mp4 attached below is some bad interpolated frames replaced with RIFE versions, and inserted frames . I might have missed some frames (bad or dropped), and there are minor artifacts but it's a definite improvement. The demo vid is slowed down to ~1/2 speed (15fps)


I don't have a simple wrapper function like RX in vapoursynth-RIFE yet, but it's something I plan on doing eventually. My python knowledge is relatively weak

[johnmeyer]

All the above comments are correct: the video was originally interlaced, but was then re-sized without first being deinterlaced. It was then deinterlaced (they should have done this first!!) and is now progressive (regardless of what any flag or header says).

Poisondeathray's idea for fixing it is a good one but unfortunately you have many instances where there are two bad frames in a row, so for those you cannot interpolate from an adjacent frame.

I did create a function which was able to massively reduce the problem. I created it for one particular video and never generalized it into a function, but if you look at the still shots in the following thread, you'll see that it did work. Having said that, as others have pointed out above, given how I did what I did, it is far from a perfect fix (although it made that particular video look a LOT better).

repair bad deinterlacing