Is there a way to deinterlace only if needed with an MPEG1/2 source?

[PRAGMA]

EDIT: this thread (https://forum.doom9.org/showthread.php?p=1907453) explains my method to solve this question (they thought it could not be done! :P)

For example, Family Guy (US NTSC) Volume 1 Disc 1 - VTS_03_1.VOB
This source according to MediaInfo is 24000/1001 fps Progressive 2:3 Pulldown, but if you look at it in DGIndex, it is actually 30000/1001 Progressive and around the 2m45s mark you will see there is 30000/1001 fps interlaced content.

For days now I have been trying to create a script that automatically handles mixed scan like this, but I'm having a hard time doing it.

My idea is to create 2 d2vsource instances, 1 with rff=True and 1 with rff=False.
For the Progressive content, use the rff=False instance and for the Interlaced content use the rff=True instance.
Deinterlace the interlaced ones and then assumefps to 24000/1001 on both d2vsource instances to fix durations.
The result is a 24000/1001 fps (and duration) throughout the entire VOB, that plays in the correct speed and FPS when exported and audio is added.

However, when it gets to the interlaced section, it plays fine and deinterlaces fine, but my calculation for when to use the interlaced rff=True instance is based on rff=False's FieldBased of current frame, which for some reason has more frames than rff=True's, which makes the script think it's in the interlaced section for longer than it really is, causing a desync once rff=False's finally gets passed the interlaced section, causing it to go back to using that as the source for the frames, causing it to jump back about 100-200 frames.

Here's a gist bin of my current script:
https://gist.github.com/rlaPHOENiX/98c0582c19273b829c4e2f73d5143094

If anyone has any ideas or can point out what im doing wrong, please do :)

Note:
If I just use an honored pulldown d2vsource with rff=True and deinterlace that based on FieldBased and then IVTC it, it tends to have more remaining combing on the progressive sections than rff=False+AssumeFPS.
Honored D2V RFF=True + Deinterlace = pattern (_FieldBased Values for progressive sections per 5 cycle): 0 2 2 0 0 + Decimate every 3rd frame (seems to be the dupe in this instance) = 0 0 2 0, since these were originally progressive 24000/1001, shouldn't the pattern be all 0's, never needing to run through a deinterlacer?

[Myrsloik]

Short answer: no

This is the kind of thing yatta and wobbly (https://github.com/dubhater/Wobbly) were created for.

[PRAGMA]

@Myrsloik I have no idea what yatta does but upon reading Wobbly's page, it seems Yatta is similar to Wobbly and Wobbly seems to be like MeGUI's input Anaylyzer and recommends/creates code based on the source? Is there any way to run either of these on linux? Is yatta only for AviSynth?

[PRAGMA]

Thankfully Wobbly & Wibbly are runnable on Linux if you compile from the source code, or conveniently grab from a user-repo like Arch Linux's AUR.
I'm taking a look at it but im sort of confused on its usage and cannot find much documentation or wiki.

[PRAGMA]

Here's a split from the first VOB: https://drive.google.com/open?id=1Mt0Vu2ZdO-k37lptOVvTfCQKo-fAgs16

It starts off progressive 30000/1001, then interlaced 30000/1001, then back to progressive 30000/1001.
It is 2:3 pulldown, and the progressive areas are film as far as i'm aware, and if you set rff=False, you don't need to decimate them, but then its a whole thing dealing with the interlaced section and it's fps and duration and such.

Any advice on properly decimating the progressive frames and deinterlacing and decimating the interlaced frames?

[PRAGMA]

I got it very close to being perfect with Wibbly and Wobbly:
https://drive.google.com/open?id=1-dG4D49o5pJEm0vSyaoMNTbNlyVfF7yb

However I had to manually add an AssumeFPS to 24000/1001 as it was playing back at 0/0 fps (yep? makes sense?).

It has issues however:
- 10 sections reporting as 30000/1001 frame/s, doesn't *seem* to cause issues with sync but might be? All of them last exactly 5 frames. Section 8 has combing on the scene change.
- 16 sections reporting as 18000/1001 frame/s, doesn't *seem* to cause issues with sync but might be? All of them last exactly 5 frames. Section 3 has combing on a scene change.
- 114 sections fail to Pattern guess with reason: "Ambiguous pattern", I don't know what that could mean.
- Some of the 2:3 Pulldown progressive frames still have combing which most are decimated away, but there are a good amount that still reside and is quite noticable.

Any ideas?
My Wobbly settings:
- Guessing Method: From matches (min length: 10 frames)
- Use third N match: Never
- Decimate: Duplicate with higher mic per cycle ("Second duplicate" was from what I could tell the exact same, so I set this one just to be safe), I used this because "First duplicate" resulted in a lot of leftover combing not being decimated away.

[Myrsloik]

The 0/0 is the same as unknown or mixed fps which is effectively what you get after combining things. It's a bit of a quirk.

The short sections with 10 and 16 frames happen because the material was edited after telecining so there are cuts in the pattern.

Ambiguous pattern guidance simply means that there's very little motion in a section and as a result more than one pattern offset matched. Generally it's correct and only needs a quick manual check.

The remaining frames with combing can be the result of pure interlaced sections, interlaced overlays, two telecined source sections blended and so on. Some frames are simply lost and need deinterlacing.

[Mystery Keeper]

Short answer: yes. I managed to do that with just VS. But result is horrible. Instead of seldom interlaced frames you get seldom noticeably blurred frames.

[Emulgator]

Depending on what you want to achieve. DG Index sees 87,12% video with the given sample.
Usual with Cartoons: To get the motion animated correctly variable pulldown is used.
To keep such timing: Bob up ! Otherwise you may introduce too stepping motion.

AviSynth:
MPEG2Source("E:\_VID\d2v example\VTS_03_1_split.demuxed.d2v")
TempGaussMC_beta2(EdiMode="NNEDI3", tr2=3, sharpness=1.8)
does it for me. Should be possible in Vapoursynth as well ?

Double NTSC 720x480@59,94fps.
After maybe postprocessing/resizing playable as 1280x720x59,94p on blu-ray and other containers
without need for hoping on deinterlacing while playback.

No blends, tiny ghosting, maybe content was sharpened after reinterlacing.
Maybe a linedarkener like Toon() is your friend here...

[jackoneill]

I think it's possible to write a script which examines the d2v file and identifies the frames that are marked progressive in the MPEG stream and writes a bunch of std.Trim() commands for you. Those are the parts that are definitely 24 fps. If you use rff=True, d2vsource will generate extra fields for these parts to bring their frame rate up to 30 fps. You'll notice, with rff=True, the pattern of three progressive frames followed by two frames that look interlaced, whereas with rff=False the same scenes are returned unchanged, i.e. progressive only.

[PRAGMA]

Im still finding it difficult to accurately revert the mix of interlaced and progressive NTSC video file back to 24000/1001
No matter what I try to do it never seems to work out

[PRAGMA]

Problems im coming across right now seem to be related to Variable frame rate with the Family Guy S01E01. For example, about 4:30 in, it goes to 30000/1001 even though it's frame are apparently progressive according to ffprobe

[PRAGMA]

It's being strangely annoying to deal with DVD MPEG's.
Variable frame rate and Interlacing every now and then makes it very difficult to accurately return a 30/24 frame rate video file with deinterlacing ran only if necessary.

At the moment I have a script going that deinterlaces only when necessary correctly, but I cannot get it to handle variable frame rates correctly, for example as I said earlier a short scene around 4:30 goes to 30000/1001 which causes my script to handle it *correctly* but because its still 30000/1001 just being played back at 24000/1001, it results in the video out lasting the audio, causing the audio to be delayed

My current code for getting the deinterlacing alone handled is here:
https://gist.github.com/rlaPHOENiX/b6002362a92a28a1e7c89deb8ff0be73

[foxyshadis]

FWIW, the entire Capturing and Editing Video subforum could have been subtitled "Because DVDs are terrible." Welcome to the club.

That said, either Decomb isn't setting _DurationNum, _DurationDen, which I'm pretty sure it does, especially if VS sets its impossible framerate, or whatever you're using to play back or encode the output is ignoring it. That's the real problem. VS keeps all the timestamps (up until you AssumeFPS), so there's a mismatch between them and the output tool, or a total lack of arbitrary timestamp support. Maybe there's a simple fix there, maybe not.

[PRAGMA]

Whats odd is when I make an encode (very basic veryfast x264 via ffmpeg), it actually returns seemingly correct, if I go to the scene in question, and simply go frame by frame via MPV and comparing what the frame looks like by going frame by frame on the original mpeg2 by also playing that via MPEG2 which handles the IVTC e.t.c by default, the frame count and frames align up perfectly, but, if I actually let it play that scene (not frame by frame), it doesnt match up, the scene ends faster than it should. This does sound like a timecode or frame duration issue but im really not sure how to debug that.

[PRAGMA]

None of the actual metadata returned by core.d2v.Source tells the frame rate accurately, it reports 30000/1001 for every frame (im using rff=False btw, so most should be 24000/1001 apart from the interlaced sections and the random 30000/1001 sections).
This is why I have used AssumeFPS to set it to 24000/1001, perhaps theres an issue here?

How I checked:

c = core.d2v.Source(input="/path/to/file.d2v", rff=False)
for n,_ in enumerate(c):
if "FPS: 30000/1001" not in str(c[n]):
raise Exception(str(c[n]))
# No exceptions were thrown


If I use core.ffms2.Source against the .mpg stream, I end up with all frames being 500000/20337

[PRAGMA]

The only way I got this all to be done correctly, is by leaving rff=True (which I really dont want to do) which leaves it at a constant 30000/1001 and then deinterlace (still ending up as 30000/1001) and then decimate to 24000/1001 by removing every 3rd frame. This ends up with a 24000/1001 albeit nice looking condition, but I would still love to do without rff=True, if only the frame rates were reported correctly when rff=False, then I could just search for all progressive (via ffprobe) non FILM frame rate frames, clip them, and decimate them, returning as close to lossless as possible.

For example if rff=False reported frame rates correctly, e.g. interlaced sections as 30000/1001, progressive as 24000/1001 and those progressive 30000/1001 scenes as is, then I could:
- Use the code I previously shared to separate progressive from interlaced (thanks to ffprobe)
- Deinterlace and Decimate all separated interlaced clips
- Search through all the progressive clips for non-FILM frame rates, seperate them into clips like I did to seperate progressive and interlaced frames, and decimate them to 24000/1001
I would now have 24000/1001 everywhere (for sure) and the result would be CFR 24000/1001 with as little deinterlacing done as possible, and if I utilize core.vivtc.VFM with a safe mode I can lower the amount of interlacing further.

Point is, it would be much better than using Wibbly&Wobbly, and much more efficient than using Yadif or just QTGMC'ing a rff=True stream.

Sad times.

[PRAGMA]

Ok cool stuff:
This VapourSynth script I made (https://gist.github.com/rlaPHOENiX/b15dd46dca71820ebcf4cff5222c7926) is perfectly setup as of Commit #2 for Family Guy S01E01 to return a clip that is Progressive @ 24000/1001 CFR with audio being perfectly synced no issues.

It's using rff=True, but thanks to _FieldBased and VFM, it barely uses QTGMC at all, like, at all. It took 10m12s to encode a non decimated 30000/1001 video yet QTGMC is configured to be full performance slowest speed. That's pretty darn good.