TDecimate: Alternate strategy mode=0 (possibly others?)

[Enivex]

My understanding is that (when cycleR=1) the lowest metric frame is "always" chosen when there are multiple duplicates (the choice can also be affected by tfm hints). This has the unfortunate consequence that tdecimate can jump to a different pattern even if the existing one can be kept going.

An example of this causing a juddery mess is the wormhole in the opening credits of Star Trek DS9.

My proposal is simple: Have an option where if the pattern of dropped frames can be continued, then it should be. That is, above, frame 8247 is chosen instead of 8245, because the last frame we removed was 8242 (and 8247 = 8245 + cycle)

This strategy would fix almost all the judder in several sequences I've investigated.

(If this is already possible to achieve, I'd appreciate some pointers)

[flossy83]

If you use TDecimate(mode=0, hint=false) then it should always decimate the lowest-in-cycle and remove 8247 in your second screenshot.

This is precisely why I never use hints as it always messes up the decision making.

As you're probably aware too, interlaced content is full of cadence breaks so the position of the dupe can change, so you will inevitably need to use "lowest in cycle" anyway (except for animation cadences when using mode=1).

[Enivex]

If you use TDecimate(mode=0, hint=false) then it should always decimate the lowest-in-cycle and remove 8247 in your second screenshot.

This is precisely why I never use hints as it always messes up the decision making.

As you're probably aware too, interlaced content is full of cadence breaks so the position of the dupe can change, so you will inevitably need to use "lowest in cycle" anyway (except for animation cadences when using mode=1).

I have to do some testing again when I have time, but hint=false doesn't necessarily fix the issue. It works for this particular frame, but causes other issues elsewhere.

I'm aware that the position changes, but typically not every cycle. If the position is different in one isolated cycle then it's likely a false positive, and I'd like to ignore it.

[flossy83]

I have to do some testing again when I have time, but hint=false doesn't necessarily fix the issue. It works for this particular frame, but causes other issues elsewhere.

I'm pretty sure there will always be issues even when the decimation logic is optimal, because this type of analogue-era interlaced content can have field cadence breaks, cadence changes, and mixed cadences on screen at once.

eg. credit subtitles spliced in at 1:1 field cadence on top of 3:2 cadence, or scene fade in/out at 1:1 or 2:2 cadence, or CGI sequences at 2:2 cadence (I forgot which Star Trek has this - was it DS9 or Voyager?) or scene splicing half way through a 3:2 cycle. These kind of things can make the 5-frame cycle have 30p metrics.

Intro sequences are virtually impossible to pull out a smooth 24p as they often contain a rapid alternation of scenes and visual elements at 3:2, 2:2 and 1:1 field cadences (decimation to 24p only works for 3:2 field cadences).

To find out the real source cadence on a tricky intro sequence I'll use Bob() on the original 30i clip (creates 60p clip, 1 frame per field) and framestep through and manually count the source field cadence. You can side-by-side with eg. StackHorizontal(TDecimate(TFMClip).ChangeFPS(60000,1001), Bob(originalClip)).

Another decimation issue is false negatives for duplicates due to noise in the source, in this case try chroma=false to help with analogue rainbows, denoise=true to help with dotcrawl, and nt=7 to increase the denoise threshold.

I previously added sceneDec=true (#50) but in practice that is more of an edge case that doesn't come into play very often so you probably won't notice any improvement with that.

Most stutters around scenechanges are the result of 2 duplicates in cycle, 1 is decimated by TDec, then the other remains and for dealing with that I made SkipFrames (https://github.com/flossy83/SkipFrames)

If you can send me a DVD remux mkv or vob that youre working on I could probably give an optimal solution. Currently I am IVTCing my NTSC DVDs to 120p so that all cadences go evenly, but it's not ready to release yet and probably won't be desirable anyway for media player compatibility reasons.

[flossy83]

Looking at my 24p DVD rips of DS9 season 1, the wormhole and CGI sequences appear to all be native 24p (implies 3:2 source field cadence) so that should not be an issue to decimate smoothly.

But there are a lot of analogue (yellow cable) rainbow artefacts - I would imagine that to be the most likely culprit of decimating the wrong frame as I've had that exact issue before with other shows.

So the first thing I would try is TDecimate(chroma=false, denoise=true, nt=7) and see if that does the trick.