TDecimating a video with two duplicate patterns?

[Mephesto]

Let's say it fluctuates between a duplicate every 5th and 6th frame. How would I properly decimate this?

The pattern is:

FFFFFD
FFFFFFD
FFFFFD
FFFFFFD

F is frame, D is duplicate frame.

[manono]

TDecimate(Mode=0,Cycle=13,CycleR=2)

[jagabo]

If the pattern repeats perfectly (not likely):

SelectEvery(13, 0, 1, 2, 3, 4, 6, 7, 8, 9, 10, 11)

[Mephesto]

TDecimate(Mode=0,Cycle=13,CycleR=2)

This looks like it would delete 2 frames after every 13th iteration. Not what I asked for. I wanna delete the 6th frame then 7th then 6th after that then 7th etc.

jagabo, no the pattern doesnt repeat perfectly.

[budwzr]

Why can't you use IVTC?

[Mephesto]

Why can't you use IVTC?

Because I'm not converting NTSC to PAL?

[budwzr]

Why can't you use IVTC?

Because I'm not converting NTSC to PAL?

But the long interval between frames suggests a minor change, like 50 to 60, no? Just trying to help figure the algorithm. So you can predict and make a script. I admit I'm not nearly as knowledgeable as Jagabo, aqnd probably whoever else posted.

But I do like to troubleshoot things. Hahaha

I know they have different logics to conform different fps. Maybe I'll learn something too.

[poisondeathray]

TDecimate(Mode=0,Cycle=13,CycleR=2)

This looks like it would delete 2 frames after every 13th iteration. Not what I asked for. I wanna delete the 6th frame then 7th then 6th after that then 7th etc.

This does exactly what you want. It doesn't necessarily do it in that order. It decimates 2 duplicates out of every group of 13


To be clear , you should use more precise notation. I'm assuming this is what you really mean?

ABCDEE
FGHIJKK
LMNOPP
QRSTUVV

[jagabo]

TDecimate(Mode=0,Cycle=13,CycleR=2)

This looks like it would delete 2 frames after every 13th iteration. Not what I asked for. I wanna delete the 6th frame then 7th then 6th after that then 7th etc.

This does exactly what you want. It doesn't necessarily do it in that order. It decimates 2 duplicates out of every group of 13

But not necessarily one frame out of 6 then one frame out of 7. Most of the time it won't matter though.

[Mephesto]

This does exactly what you want. It doesn't necessarily do it in that order. It decimates 2 duplicates out of every group of 13

I don't have two duplicates at every 13th frame, I said I have two PATTERNS of duplicates.

To be clear , you should use more precise notation. I'm assuming this is what you really mean?

ABCDEE
FGHIJKK
LMNOPP
QRSTUVV

That's right. Btw I love how this font perfectly aligned all of those so it looks like theres only one duplication pattern. I love Fixedsys.

[poisondeathray]

But you said the pattern doesn't repeat perfectly, and isn't perfectly aligned - otherwise you could use SelectEvery as above

Did you try those Tdecimate settings ? It's adaptive, so even if you have 2 patterns and there is a slight cadence swap it will still work (it will look for the duplicates wherever they might be within that cycle, not blindly take every 6th or 7th frame) - whereas SelectEvery will make a mistake if it's not aligned perfectly (you need perfect match for the pattern)

I don't have two duplicates at every 13th frame, I said I have two PATTERNS of duplicates.

It's not AT every 13th frame, it's search radius is within every 13 frames. The duplicates might be placed anywhere, and it will select them anywhere within that cycle (ie. it's adaptive)

[Mephesto]

Did you try those Tdecimate settings ? It's adaptive, so even if you have 2 patterns and there is a slight cadence swap it will still work (it will look for the duplicates wherever they might be within that cycle, not blindly take every 6th or 7th frame) - whereas SelectEvery will make a mistake if it's not aligned perfectly (you need perfect match for the pattern)

I'll try it right now. Why was 13 specifically selected though? Would there be too much danger in changing it to 14 or 12?

It's not AT every 13th frame, it's search radius is within every 13 frames. The duplicates might be placed anywhere, and it will select them anywhere within that cycle (ie. it's adaptive)

Yeah, that's why I'm using TDecimate. But my understanding was that the number of frames to decimate was absolute while the range was variable, I didn't know both were variable.

[poisondeathray]

Why was 13 specifically selected though? Would there be too much danger in changing it to 14 or 12?

13 was selected because that is the additive sum of your 6 and 7 pattern (6+7=13)

Yes there is danger of selecting different number because the cycles won't line up (you'll eventually miss a duplicate, or more than it would normally miss) . 13 is "ideal" given the information you've provided

CycleR / Cycle

This means 2/13 (or 2 frames out of the cycle of 13 are selected)

[Mephesto]

Why was 13 specifically selected though? Would there be too much danger in changing it to 14 or 12?

13 was selected because that is the additive sum of your 6 and 7 pattern (6+7=13)

Yes there is danger of selecting different number because the cycles won't line up (you'll eventually miss a duplicate, or more than it would normally miss) . 13 is "ideal" given the information you've provided

CycleR / Cycle

This means 2/13 (or 2 frames out of the cycle of 13 are selected)

Should it not be 11 (5+6)? I never thought about the importance of whether to delete the first or last duplicate frame.

[poisondeathray]

Should it not be 11 (5+6)? I never thought about the importance of whether to delete the first or last duplicate frame.

No, because it won't "see" the outside duplicate

Take this example:

ABCDEE
FGHIJKK


The KK will be missed in that cycle if you chose 11

The "adaptive" part means it doesn't matter if you started on an "A" frame or a "D" frame etc.... because if that pattern is fairly consistent, then every 13 frames will have 2 duplicates

[Mephesto]

Should it not be 11 (5+6)? I never thought about the importance of whether to delete the first or last duplicate frame.

No, because it won't "see" the outside duplicate

Take this example:

ABCDEE
FGHIJKK


The KK will be missed in that cycle if you chose 11

The "adaptive" part means it doesn't matter if you started on an "A" frame or a "D" frame etc.... because if that pattern is fairly consistent, then every 13 frames will have 2 duplicates

Ah, I see. Btw, is there any way to keep track of the original frames in the decimated video? If I use Showframenumber BEFORE decimation then I'm worried about the yellow numbers confusing the TDecimate algorithm. Wish there was a way for Showframenumber to not actually be part of the video.

[poisondeathray]

Ah, I see. Btw, is there any way to keep track of the original frames in the decimated video? If I use Showframenumber BEFORE decimation then I'm worried about the yellow numbers confusing the TDecimate algorithm. Wish there was a way for Showframenumber to not actually be part of the video.

To learn what decisions it's making you can use the debugmode, either display=true to show it overlaid or debug=true to output using OutputDebugString() . Read the instructions for more information (the "inframe" is the original framenumber, starting at zero like avisynth normally does) . Using this you can tweak the dozen other settings to get more customized results as well

[jagabo]

Since you see pattern changes, I suspect it's not truly 2 of every 13 frames that needs to be removed (and also because 11/13 doesn't correspond to any of the standard frame rate conversion). You may want to look at a longer section to determine what the real frame rate is (something close to 11/13 of the source frame rate) then use "mode=2, rate=x", where x is whatever that frame rate turns out to be.

[manono]

Since you see pattern changes, I suspect it's not truly 2 of every 13 frames that needs to be removed (and also because 11/13 doesn't correspond to any of the standard frame rate conversion).

I thought the same, but this guy is an ornery cuss so I gave him what he asked for. And he still had the nerve to argue before even trying it. Or even before reading the doc which is quite clear about Mode 0 and what Cycle and CycleR mean. I have, for example, seen plenty of PAL to NTSC conversions where the repeat pattern is 7 6 5 7 6 5, or some variation of that which averages out to one dupe frame out of every six.

And then rather than us trying to guess what he really has, better might be to provide a small sample from the source.

Should it not be 11 (5+6)? I never thought about the importance of whether to delete the first or last duplicate frame.

Gimme a break.

[jagabo]

And he still had the nerve to argue before even trying it. Or even before reading the doc

As is usually the case with Mephesto.

[Mephesto]

Perfect, this worked. Your guess is as good as mine why the source is so weird. If you knew what I worked with and all the bizarre rare videos that mental fucks on eBay are looking for it might make more sense.

manono and jagabo, both of you can bite me. You might surpass me in technical knowledge but you've achieved them at the expense of intellectual aptitude. I own up when I'm wrong, have many times and do it immediately without any bullshit. I've seen neither of you do so once. You are more apt at lecturing than learning, a trait more common with the uneducated.

Remember our discussion about the benefit of deleting duplicate frames? Funny how poisondeathray and neither of you responded to the evidence I posted in a new thread. Tells a lot about your character and how little you are willing to put to educate yourself.

I'm not interested in being right, I'm interested in being correct, and I live on $3 a day. You can do way better, holms.

And he still had the nerve to argue before even trying it. Or even before reading the doc which is quite clear about Mode 0 and what Cycle and CycleR mean.

Or I could've been using TDecimate for enough years to not recall every function of every setting. In fact, this is the first time I've used any other value in the number of frames remove besides 1, and the first video I dealt with that had two patterns of duplicate frames.