Interlaced MP4s flagged as progressive

[Mr Chris]

I'm trying to rescue some badly-processed MP4s the best I can - please see the attached sample clip.

These videos are flagged as progressive, but they're clearly interlaced. Under normal circumstances, playing them back and forcing deinterlacing on the fly wouldn't be a problem, but here we have the double-whammy of VLC (and everything else) getting the field order wrong. I've tried to find some sort of flag that I can switch, and to repackage them into an MKV file that's correctly marked as TFF interlaced, but nothing's worked so far.

What are my options, if any, other than re-encoding the lot?

[davexnet]

Sorry to bring bad news, but:
There are a few older threads where it was not deemed possible
https://forum.videohelp.com/threads/377932-Is-it-possible-to-change-Scan-Type-flag-on-MP4-file

Secondly, the progressive encoding with chroma sub-sampling of 4:2:0 has harmed the chroma, the two fields get blurred together.
https://forum.videohelp.com/threads/398436-In-VirtualDub-where-is-the-capture-BITRATE-...ng#post2592253

[ProWo]

See this:

ffmpegsource2("D:\Downloads\sample.mp4",vtrack=0)
AssumeFPS(25)
AssumeTFF
QTGMC()
Crop(16, 2, -24, -10)
BicubicResize(720, 576)

[Mr Chris]

Sorry to bring bad news, but:
There are a few older threads where it was not deemed possible
https://forum.videohelp.com/threads/377932-Is-it-possible-to-change-Scan-Type-flag-on-MP4-file

Thanks - I was afraid of that. I've come across this issue in formats other than MP4/h264, and I suppose I just find it difficult to believe that something that can at least theoretically be forced during playback can't be flagged without re-encoding. Still, it looks like re-encoding is my only option, so...

See this:

ffmpegsource2("D:\Downloads\sample.mp4",vtrack=0)
AssumeFPS(25)
AssumeTFF
QTGMC()
Crop(16, 2, -24, -10)
BicubicResize(720, 576)

...thank you very much for that, too.

Secondly, the progressive encoding with chroma sub-sampling of 4:2:0 has harmed the chroma, the two fields get blurred together.
https://forum.videohelp.com/threads/398436-In-VirtualDub-where-is-the-capture-BITRATE-...ng#post2592253

Yeah, I noticed that myself. I presume that's irretrievable in this case, too, is it? Again, not expecting miracles; just trying to make the best of a bad job.

While we're on the subject of the chroma problems, this is one of those things that's been bothering me for years, and I've never truly got to the bottom of it, so if any of you kind folks will indulge me...

- Does this chroma blurring issue have a name so that I can at least Google it?
- Once present, is there ever a way to either undo it or perhaps mitigate the problem? i.e. Can you 'deinterlace' just the chroma of a video, or is it baked in for good?
- What causes it? (I used to just think 4:2:2 = good, 4:2:0 = bad, but I believe DVD-compliant MPEGs and PAL DV are the latter yet I'm pretty sure chroma blurring can be avoided. Or have I got that all wrong?)
- What needs to be avoided? (It's an issue that seems to come up for me randomly in VirtualDub, and I think colour spaces come into it, but I've never been able to spot a definitive pattern.)

I'm determined to get my head around this one day.

[davexnet]

As mentioned in the thread I posted above, it's caused by re-encoding interlaced 4:2:2 chroma to 4:2:0 progressive without properly deinterlacing first.

[Mr Chris]

But what would constitute improper deinterlacing in this instance? Not including "ConvertToYV12(interlaced=true)"? And is this really the only way to cause this chroma blurring effect, because I'm sure I've stumbled across it elsewhere.

Either way, going back to the video in my original post, are those chroma issues now baked in, or is there anything at all I can do to help?

[davexnet]

See Prowo's script and sample above.
If you can recreate these files (assuming you still have the source) that may be best,
otherwise re-encoding these will have to do.

The chroma issues are baked in, but it may not be too noticeable from a normal viewing distnace

[Sharc]

But what would constitute improper deinterlacing in this instance? Not including "ConvertToYV12(interlaced=true)"?

It is more than this. You can see the chroma flaw in the attached file. When stepping through it you will see that on the left picture you have motion with every step (50fps, field rate). On the right you see that the U and V planes advance with every 2nd step only (25fps). A correctly encoded interlaced 4:2:0 file would have U,V advancements synchronous (50fps) to the bobbed source on the left.

[ProWo]

On the right you see that the U and V planes advance with every 2nd step only (25fps). A correctly encoded interlaced 4:2:0 file would have U,V advancements synchronous (50fps) to the bobbed source on the left.

Interesting, what filter did you use to show the U,V planes in virtualdub?

[Sharc]

On the right you see that the U and V planes advance with every 2nd step only (25fps). A correctly encoded interlaced 4:2:0 file would have U,V advancements synchronous (50fps) to the bobbed source on the left.

Interesting, what filter did you use to show the U,V planes in virtualdub?

I don't know how to do it in VirtualDub.
I used the Avisynth functions UtoY() and VtoY() and enhanced the contrast to make it better visible.

[ProWo]

I don't know how to do it in VirtualDub.
I used the Avisynth functions UtoY() and VtoY() and enhanced the contrast to make it better visible.

Thank you.