Need Help Figuring Out This Strange Pulldown Pattern

[DeadSkullzJr]

As the title implies, I have a cartoon source that has a particularly strange pulldown pattern. When you look at it you can clearly tell that most of it is standard 2:3 pulldown, but then there are frames where it seems to be 2:2 pulldown, one that's 1:3 pulldown, etc.. I would imagine that this means it's a bad source. Unfortunately there aren't any better sources to use, coming straight from the DVD this way. There weren't better printed versions over time, so this is the best I have to work with. TFM (through AviSynth+) takes care of the 2:3 pulldown segments from the looks of things, leaving the stranger pulldown patterns left. I didn't enable post processing since that seems to be dodgy at times. Some advice on proper ways to handle this would be appreciated.

Move frame by frame forward starting from the following frames:
7, 51, 90, 129

Plenty of other frames in the clip are like this, but the frame ranges mentioned should give a general idea.

[davexnet]

That is not straight from the DVD. It's been re-encoded to H.264/AVC

DVD is mpeg-2

[DeadSkullzJr]

That is not straight from the DVD. It's been re-encoded to H.264/AVC

DVD is mpeg-2

Yea I'm aware of that. I had to encode it to make it smaller, but the pull-down and frames are still the same as the VOB. It doesn't matter of the fact that it's encoded to fit, I gave a clip that can still be examined. I'm not asking about the format, I'm asking about the pull-down pattern.

[Sharc]

The original DVD has probably been soft telecined. In that case the pulldown is controlled by the flags during playback and need not follow a regular standard pattern. Also, pattern breaks may be introduced when telecined video is edited after the telcine has been applied.

[DeadSkullzJr]

The original DVD has probably been soft telecined. In that case the pulldown is controlled by the flags during playback and need not follow a regular standard pattern. Also, pattern breaks may be introduced when telecined video is edited after the telcine has been applied.

What would have to be done then to sort this out, if it is soft telecined that is? Is this something TFM can tackle, or would I need extra resources to tackle this? I probably missed some information when reading up on TIVTC, I don't recall it mentioning anything about sorting the unusual flags out, at least outside of the standard 2:3 pattern. Managed to restore a couple handfuls of films without things like this occurring so far, so I'm assuming this isn't the most common situation, unless this is an animation specific thing normally, and I'm just not aware.

[Sharc]

Your rip and reencode has the flags removed. You can try with AnimeIVTC.
http://avisynth.nl/index.php/AnimeIVTC

If no avail the last resort is to deinterlace (QTGMC).

[DeadSkullzJr]

Your rip and reencode has the flags removed. You can try with AnimeIVTC.
http://avisynth.nl/index.php/AnimeIVTC

If no avail the last resort is to deinterlace (QTGMC).

What if I try with the original MPEG-2 stream then? Should I stick to the VOBs directly? The clip I provided was formulated when I fed DGMPGDec the original VOBs, but since I needed a clip that was small enough, I didn't see any reason to encode it into MPEG-2 again, considering the frames and pulldown patterns were present between the original MPEG-2 source and my small clip.

[oliverturner]

Hey, sounds frustrating! Pulldown issues in cartoons can often come from mismatched frame rates, like 24fps film converted to 30fps video. Have you tried using a free tool like HandBrake or AviDemux to analyze the frames? Might give you some clues. Let us know more details if you can!

[Sharc]

Your rip and reencode has the flags removed. You can try with AnimeIVTC.
http://avisynth.nl/index.php/AnimeIVTC

If no avail the last resort is to deinterlace (QTGMC).

What if I try with the original MPEG-2 stream then? Should I stick to the VOBs directly? The clip I provided was formulated when I fed DGMPGDec the original VOBs, but since I needed a clip that was small enough, I didn't see any reason to encode it into MPEG-2 again, considering the frames and pulldown patterns were present between the original MPEG-2 source and my small clip.

Some source filters respect the mpeg-2 pulldown flags. DGIndex for example has the setting Video->Field Operation -> Honor Pulldown Flags.

[DeadSkullzJr]

Your rip and reencode has the flags removed. You can try with AnimeIVTC.
http://avisynth.nl/index.php/AnimeIVTC

If no avail the last resort is to deinterlace (QTGMC).

What if I try with the original MPEG-2 stream then? Should I stick to the VOBs directly? The clip I provided was formulated when I fed DGMPGDec the original VOBs, but since I needed a clip that was small enough, I didn't see any reason to encode it into MPEG-2 again, considering the frames and pulldown patterns were present between the original MPEG-2 source and my small clip.

Some source filters respect the mpeg-2 pulldown flags. DGIndex for example has the setting Video->Field Operation -> Honor Pulldown Flags.

Correct, that option is already enabled, I've never personally touched that option in any capacity either, the only options I have touched were the iDCT algorithm options, and the force open GOPs in D2V option. I parsed the D2V that DGIndex created from the VOBs, it didn't provide any fruitful information, part of me feels like this makes sense though because the pulldown frames and such are already visible when viewing the VOBs directly, which isn't usually the case for film and such normally. So going through DGIndex in this case may actually be a redundant step I am taking since the representation and results show no differences. I will provide the parsed D2V.

[poisondeathray]

Because there are some orphaned fields with unique content (a frame missing it's "partner field") , you need to deinterlace those fields otherwise you get jumps/drops in motion, or you're left with a combed frame. Ideally you would only deinterlace those and field match everything else, otherwise you degrade the progressive frames and create aliasing

The unique frame rate for that scene is 277 frames @ ~ 24.27397

You can use TFMbob (https://forum.videohelp.com/threads/401305-TIVTC-settings#post2615424) to interleave 2 field matched versions (bottom and top field versions). That would be preferable to "bobbing" or double rate deinterlacing everything (thus degrading every frame) . Then dedup using show=true to step through and debug the threshold value. Because this clip is supposed to have constant motion, there is a large difference between unique frame vs. duplicate, thus it's "easy" to distinguish (I used threshold of 2).

In this clip the interlevaved TFM "bobbed" version has 684 frames, 277 unique frames after dedup. If you assume a CFR that would be 277/685 * 60000/1001 =~ 24.27397 . Of course you'd have test and verify on longer sections (you have to run the dedup analysis pass, go through adjusting the threshold to get unique frames, but no dropped frames), and beware of low motion scenes with dedup's threshold value

You can specify QTGMC for clip2 in TFM for better deinterlacing of detection of combed frames

This is modified from jagabo's original to use QTGMC for clip2

function TFMqBob(clip v, int "pp")
{
    pp = default(pp, 6)
    v.GetParity() ? Interleave(TFM(v, field=1, pp=pp, clip2=v.QTGMC.selecteven()), TFM(v, field=0, pp=pp, clip2=v.QTGMC.selectodd())) : Interleave(TFM(v, field=0, pp=pp), TFM(v, field=1, pp=pp))
}

LWLibavVideoSource("clip.mkv")
AssumeTFF()
TFMqBob
#DupMC(log="log.txt")
DeDup(threshold=2, maxcopies=10, maxdrops=10, log="log.txt", times="times.txt")#, show=true)#, dec=false)
AssumeFPS(24.27397) #277/685 * 60000/1001 =~ 24.27397

If the pattern varies significantly from this sample in other sections, you still might be able to get an approximation using the dedup analysis, and the approx frame rate, and enter those into Tdecimate in cycle, cycleR (or mode 7 using a set frame rate) for adaptive decimation

[bettergenes]

delete, wrong thread

[jagabo]

For what it's worth, I agree with poisondeathray. I independently came up with the same method and result.

[DeadSkullzJr]

Because there are some orphaned fields with unique content (a frame missing it's "partner field") , you need to deinterlace those fields otherwise you get jumps/drops in motion, or you're left with a combed frame. Ideally you would only deinterlace those and field match everything else, otherwise you degrade the progressive frames and create aliasing

The unique frame rate for that scene is 277 frames @ ~ 24.27397

You can use TFMbob (https://forum.videohelp.com/threads/401305-TIVTC-settings#post2615424) to interleave 2 field matched versions (bottom and top field versions). That would be preferable to "bobbing" or double rate deinterlacing everything (thus degrading every frame) . Then dedup using show=true to step through and debug the threshold value. Because this clip is supposed to have constant motion, there is a large difference between unique frame vs. duplicate, thus it's "easy" to distinguish (I used threshold of 2).

In this clip the interlevaved TFM "bobbed" version has 684 frames, 277 unique frames after dedup. If you assume a CFR that would be 277/685 * 60000/1001 =~ 24.27397 . Of course you'd have test and verify on longer sections (you have to run the dedup analysis pass, go through adjusting the threshold to get unique frames, but no dropped frames), and beware of low motion scenes with dedup's threshold value

You can specify QTGMC for clip2 in TFM for better deinterlacing of detection of combed frames

This is modified from jagabo's original to use QTGMC for clip2

function TFMqBob(clip v, int "pp")
{
    pp = default(pp, 6)
    v.GetParity() ? Interleave(TFM(v, field=1, pp=pp, clip2=v.QTGMC.selecteven()), TFM(v, field=0, pp=pp, clip2=v.QTGMC.selectodd())) : Interleave(TFM(v, field=0, pp=pp), TFM(v, field=1, pp=pp))
}

LWLibavVideoSource("clip.mkv")
AssumeTFF()
TFMqBob
#DupMC(log="log.txt")
DeDup(threshold=2, maxcopies=10, maxdrops=10, log="log.txt", times="times.txt")#, show=true)#, dec=false)
AssumeFPS(24.27397) #277/685 * 60000/1001 =~ 24.27397

If the pattern varies significantly from this sample in other sections, you still might be able to get an approximation using the dedup analysis, and the approx frame rate, and enter those into Tdecimate in cycle, cycleR (or mode 7 using a set frame rate) for adaptive decimation

Thanks, tried this out and even created a few different versions of my own to see what happens. So far this script as well as all of mine seem to TFM the oddball interlaced frames, causing sudden jumps from one frame to another where there should have been fluid motion. I tried different modes and parameters to try and isolate only the 2:3 pattern and leaving the odd frames behind to deal with. Looks like the only way to get more precise results is if I manually fix the individual frames that stick out differently. I will say that with each script, there was a pretty common pattern with the progressive frames at least, a sort of 1:4 pattern (one duplicate frame four unique frames). Of course due to the oddball frames, this pattern wasn't 100% consistent, but it certainly was majority out of all the frames.

[poisondeathray]

So far this script as well as all of mine seem to TFM the oddball interlaced frames, causing sudden jumps from one frame to another where there should have been fluid motion.

Do you have a sample where that script fails ?


One possibility is that on other scenes the TFM combing threshold wasn't met - but you'd be left with combed frames and it should be obvious if you debug the script and just look at the direct output of TFMbob

"Jumps" (as in dropped frames) shouldn't be TFMbob's fault, because the TFMbob'ed version interleaves 2 versions (both top and bottom field order). Even on pure interlaced content material you 'd get 59.94 unique frames/s - so all the content should be represented, and with many repeats. At that point in the script before dedup, the repeats would be better described as slight stuttering

A more likely explanation for "jumps" for that script is the dedup threshold was not set correctly and you are dropping good frames.

If that sample is representative of other scenes, any script that essentially does standard IVTC will give jumps and dropped frames because 24.27397 > 23.976 . You would be dropping good frames with unique motion

[DeadSkullzJr]

So far this script as well as all of mine seem to TFM the oddball interlaced frames, causing sudden jumps from one frame to another where there should have been fluid motion.

Do you have a sample where that script fails ?


One possibility is that on other scenes the TFM combing threshold wasn't met - but you'd be left with combed frames and it should be obvious if you debug the script and just look at the direct output of TFMbob

"Jumps" (as in dropped frames) shouldn't be TFMbob's fault, because the TFMbob'ed version interleaves 2 versions (both top and bottom field order). Even on pure interlaced content material you 'd get 59.94 unique frames/s - so all the content should be represented, and with many repeats. At that point in the script before dedup, the repeats would be better described as slight stuttering

A more likely explanation for "jumps" for that script is the dedup threshold was not set correctly and you are dropping good frames.

If that sample is representative of other scenes, any script that essentially does standard IVTC will give jumps and dropped frames because 24.27397 > 23.976 . You would be dropping good frames with unique motion

I'll recheck my workflow, I may have messed something up along the way and didn't even realize. I'll report back after double checking and retesting. Sorry for the inconvenience on the lack of good results yet.

[Sharc]

For analyzing and debugging purpose you can enable the 'show' option in DeDup, like DeDup(show=true, ......). Step through the script and observe the % and ifrm for example.
Jumps should become less when lowering the threshold value. Also, you may want to reduce maxdrops to 3 or similar.
Stutters at the other hand are caused by residual duplicates and would require to raise the threshold.
Difficult cases may require manual interaction by specifying the 'ovr' file where you can set different threshold values for certain frames or scenes. Can be quite laborious for pathalogic cases though, and keeping the audio in sync is the next challenge.
http://avisynth.nl/index.php/DeDup

[DeadSkullzJr]

So far this script as well as all of mine seem to TFM the oddball interlaced frames, causing sudden jumps from one frame to another where there should have been fluid motion.

Do you have a sample where that script fails ?


One possibility is that on other scenes the TFM combing threshold wasn't met - but you'd be left with combed frames and it should be obvious if you debug the script and just look at the direct output of TFMbob

"Jumps" (as in dropped frames) shouldn't be TFMbob's fault, because the TFMbob'ed version interleaves 2 versions (both top and bottom field order). Even on pure interlaced content material you 'd get 59.94 unique frames/s - so all the content should be represented, and with many repeats. At that point in the script before dedup, the repeats would be better described as slight stuttering

A more likely explanation for "jumps" for that script is the dedup threshold was not set correctly and you are dropping good frames.

If that sample is representative of other scenes, any script that essentially does standard IVTC will give jumps and dropped frames because 24.27397 > 23.976 . You would be dropping good frames with unique motion

Found my error, I had an extra SelectEven in the scripts, which caused the frame rate to stay at 29.970 FPS, but caused some good frames to drop. Things now seem to run the way you explained they should, I also corrected the error with my own scripts and now they all correlate correctly. Here is a longer clip after running one of the scripts. Haven't sorted out the exact frame rate this is supposed to be yet for TDecimate. If you need a much longer clip to work with, let me know, 500 MB is pretty flexible, so I can fit something way longer if necessary.