tdecimate dupe frames in certain pattern

[midts]

Source is 50FPS

Dupe pattern is like this:

1 dupe
no dupe
2 dupes
no dupe
1 dupe
no dupe
2 dupes

and so on

So far mode=7 gives best result, but there's still dupe leftovers. mode=2 is terrible, lots of dupes, it also doesn't work with rate=23.976 the encoding just hangs at 0% in an infinite loop (with megui x264 x64).

This is best outcome I got so far

tdecimate(mode=7, rate=23.976)

Cheers.

[jagabo]

Do you literally mean a repeating pattern like:

1 dupe    no dupe    2 dupes    no dupe    1 dupe    no dupe    2 dupes
A A       B          C C C      D          E E       F          G G G

Then you have 7 unique frames out of every 13. That implies a frame rate of 50 * 7 / 13 = 26.923. But that doesn't jive with your claim that 23.976 fps leaves some duplicates. Maybe TDecimate is discarding some unique frames? Sometimes heavy compression artifacts or a film transfer with a lot of flicker will confuse the decimation process. Is there any blending in the source? You should provide a sample of the video. A long medium speed panning shot is good for this type of analysis.

[midts]

Hi, I might not be correct on the pattern, I attached the sample.

[midts]

Hi, was the sample bad or source really bricked and no solution? Thanks.

[Selur]

Had a quick look -> bad sample to look for a pattern when most of the sample shows an animation where one would expect tons of dublicates. Only interessting part seems to be the end.

[midts]

Hi, I made another sample with no animations. Please check, thank you.

[davexnet]

I counted 25 unique frames per second.
Did you try decimating to 25 ?

[jagabo]

Hi, was the sample bad or source really bricked and no solution? Thanks.

Sorry. I set the video aside after playing with it for a while, then forgot to get back to it.

I believe the original frame rate is close to 25 fps. A simple decimation like SelectEven() leaves many dups and removes many non-dups. Working with longer segments, like TDecimate(Cycle=20, CycleR=10) works a little better than tdecimate(mode=7, rate=25).

Just saw tne new posts, I'll check out the new sample...

[midts]

Hi, I tried (Cycle=20, CycleR=10) and (mode=7, rate=25), looks like they both leave dupe frame 78/79?. Thanks.

[jagabo]

Hi, I tried (Cycle=20, CycleR=10) and (mode=7, rate=25), looks like they both leave dupe frame 78/79?. Thanks.

Yes, it's not perfect.

[davexnet]

There is a unique frame at 163 then the next new frame is not until 167. It's the only place in the source there is such a gap,
seems like a bigger sample is neccesary to properly evaluate it

[hello_hello]

After running a first pass on your second sample with TDecimate, there was one frame (164) I couldn't convince it to drop until I reduced the frame rate to 24fps, and then it zapped it.

I think I removed all the dups from the second sample with DeDup, and given 193 frames went in and 95 came out....

50 / 193 * 95 = 24.612 fps, if my logic there is logical.

TDecimate output 92 frames so it probably dropped a couple from the beginning or the end or at the scene change. I haven't checked.

I also tried similar settings and 2 passes with TDecimate for the first sample. It's far from perfect but I doubt it ever will be.

Test TDec.mkv

CropResize(960)
TDecimate(mode=2, rate=24, Input="TDec.txt", maxndl=4)

Test2 TDec.mkv

CropResize(960)
TDecimate(mode=2, rate=24, Input="TDec2.txt", maxndl=3)

Test2 DeDup.mkv
Encoded at 24fps. I didn't use the timecodes.

CropResize(960)
#DupMC(log="DupMC.txt")
DeDup(threshold=2.0, trigger2=2.01, maxcopies=4, maxdrops=4, log="DupMC.txt", times="DeDupTimes.txt")
AssumeFPS(24)

[hello_hello]

Duration-wise, the TDecimate version is accurate, assuming 24fps is correct. The sample's so short it's hard to know for sure, but I suspect it is. DeDup isn't designed to achieve a constant frame rate so this is no reflection on it.

Original
1000ms / 50fps * 193 frames = 3860ms

DeDup
1000ms / 24fps * 95 frames = 3958ms

TDecimate
1000ms / 24fps * 92 frames = 3833ms

Had TDecimate dropped one less frame (output 93 rather than 92) it'd be 3875ms, so either way it couldn't be exact.

[midts]

Hi, I get skips with anything below <25fps with TDecimate(mode=2, maxndl=4)

But with TDecimate(mode=2, rate=25, maxndl=4) so far I think I get best result, no skips and a duplicate frame maybe every 20 frames here and there and sometimes a whole minute of no duplicates.

I think I will go with this, result is pretty acceptable.

Thank you everyone for help. Cheers.

[hello_hello]

You'll probably get better results running two passes. Have you tried that?

[midts]

I don't really have experience with two passes. I couldn't even load that DeDup right. I need to read more documentations.

[jagabo]

I don't really have experience with two passes. I couldn't even load that DeDup right. I need to read more documentations.

It will look like this:

first pass:

LWLibavVideoSource("test.mp4") 
DupMC(log="blah.dup.txt")

second and later passes:

LWLibavVideoSource("test.mp4") 
DeDup(threshold=4.0, maxcopies=10, maxdrops=5, log="blah.dup.txt", times="blah.times.txt")

I usually use one script and comment out the line I don't need:

first pass:

LWLibavVideoSource("test.mp4") 
DupMC(log="blah.dup.txt")
#DeDup(threshold=4.0, maxcopies=10, maxdrops=5, log="blah.dup.txt", times="blah.times.txt")

second pass:

LWLibavVideoSource("test.mp4") 
#DupMC(log="blah.dup.txt")
DeDup(threshold=4.0, maxcopies=10, maxdrops=5, log="blah.dup.txt", times="blah.times.txt")

Open the first pass script in an editor and quickly run though the entire script. I usually use VirtualDub2's File -> Run Video Analysis Pass. The program will run through the script as quickly as it can and DupMC() will write information about each frame to the log file. When that's done switch to the DeDup() script to use that information to decimate the frames.

[midts]

Hi, I tried that out, as I understand I had to add AssumeFPS() too, without it it was at 50fps. I tried both 24 and 25, I would say I still get about same amount of lone duplicate frames here and there. Result feels like same as TDecimate(mode=2, rate=25, maxndl=4)?

Also I'm confused here about two passes. I put it through VirtualDub's Video Analysis Pass first, but then I loaded it up on MeGUI and used --crf Constant Quality Encoding Method, which is just one pass? Am I doing this right?

[jagabo]

Also I'm confused here about two passes. I put it through VirtualDub's Video Analysis Pass first, but then I loaded it up on MeGUI and used --crf Constant Quality Encoding Method, which is just one pass? Am I doing this right?

You already ran the first pass in VirtualDub. The log file stays where it is until you delete it. Assuming you used DeDup() rather than DupMC() in Megui, megui is running a the second pass, using the log from the first pass in VirtualDub. If you used DupMC() in Megui you're just running the first pass again -- there will be no decimation.

[hello_hello]

I was actually suggesting two passes with TDecimate, but try both.

Analysis pass:
TDecimate(mode=4, Output="TDec.txt")

Second / encoding pass:
TDecimate(mode=2, rate=24, Input="TDec.txt", maxndl=3)

You can use MeGUI to run the analysis pass. Load the script and click the Queue Analysis Pass button. Once it's done, don't re-load or open the script again until you change it for the second pass otherwise the metrics file will be over-written and you'll have to run it again.
Once you've opened the second pass script you can adjust the TDecimate frame rate and play around with it's other settings if need be.

DeDup is designed for a variable frame rate output. If the remaining frames are spread out unevenly it can still look "jittery". I think by default, when there's a bunch of dupes in a row, DeDup will keep the middle frame, so that might help smooth it out even if you encode as VFR. In this case I was more using DeDup to work out what the average frame rate would be after the duplicates were removed. You can try encoding at an average frame rate as I did (I used the metrics and timecodes files to work out the new frame rate for AssumeFPS), in which case you won't need the timecodes file for encoding. Normally for DeDup, after the first pass you'd create the timecodes file with the second pass script and add it to the x264 command line. You can add it to the custom section in MeGUI's encoder configuration. That way you'll encode in VFR mode and the frame rate of the script doesn't matter.

DeDup(threshold=2.0, trigger2=2.01, maxcopies=4, maxdrops=4, log="DupMC.txt", times="DeDupTimes.txt")

x264 command line:
--tcfile-in "D:\DeDupTimes.txt"

TDecimate also has a VFR mode (mode=5) for the second pass. It'll create a timecodes file, but TDecimate's VFR mode is for hybrid NTSC DVD sources. The timecodes would effectively be combinations of 23.976 and 29.97 frame rates. I don't think it's designed for anything else.

DeDup will work but I think TDecimate(mode=2) is what you want here as it outputs a constant frame rate. See which one looks best. If you try DeDup, once you create the second pass script, the timecodes file will be created or over-written each time you open it, but the log file doesn't change, so you can play with DeDup's settings without having to keep re-running the first pass.

I don't think there's a 64 bit version of DeDup. You might need 32 bit MeGUI to use it.
Or there's ExactDedup. I haven't used that one myself so I don't know what the differences are.

[hello_hello]

I forgot to mention, the DupMC log file is people friendly, so you can open it to look for the threshold needed to remove duplicates, or to see where they are. This is from your second sample.

frm 156: diff from frm 157 = 29.5254% at (736,160)
frm 157: diff from frm 158 = 0.7588% at (192,160)
frm 158: diff from frm 159 = 24.4128% at (288,64)
frm 159: diff from frm 160 = 0.7438% at (352,192)
frm 160: diff from frm 161 = 25.6819% at (576,192)
frm 161: diff from frm 162 = 1.1764% at (928,480)
frm 162: diff from frm 163 = 25.2157% at (128,96)
frm 163: diff from frm 164 = 1.5417% at (480,480)
frm 164: diff from frm 165 = 0.4737% at (928,480)
frm 165: diff from frm 166 = 0.4235% at (928,480)
frm 166: diff from frm 167 = 32.3807% at (32,128)
frm 167: diff from frm 168 = 0.8365% at (64,256)
frm 168: diff from frm 169 = 31.4457% at (192,160)
frm 169: diff from frm 170 = 0.9857% at (640,64)
frm 170: diff from frm 171 = 28.3008% at (704,160)
frm 171: diff from frm 172 = 0.6479% at (480,64)
frm 172: diff from frm 173 = 23.4250% at (864,192)

I think frame #163 was the duplicate with the greatest difference from it's surrounding frames (1.5417%) so DeDup(threshold=2.0) should get them all, and for that sample I'm pretty sure the longest string of duplicates was three, so maxcopies=3, maxdrops=3 should be fine. Setting those options higher shouldn't change anything.

The first sample was more of a mess. Due to noise and encoder artefacts etc. there were duplicates with much less similarity to their surrounding frames, and lots of them, so setting threshold, maxcopies and maxdrops might require some experimenting, but I don't think the first sample will ever be completely smooth. My previous TDecimate encode might be as good as it gets for that one.

[midts]

So after another dozen of tests I think I get best result with this:

DeDup(threshold=3.0, maxcopies=4, maxdrops=4, log="blah.dup.txt", times="blah.times.txt")
AssumeFPS(25)

Framerate is consistent 25, no produced skips and no duplicates, tested on my uploaded test2.mp4 and complete source. 2 pass tdecimate still produces duplicates.

DeDup x64 is included on official avisynth download page.

[jagabo]

But does it have the correct running time?

[midts]

You're right, it's shorter. I guess audio is going to be not synced.

Looks like running time is changed with dedup, but not with tdecimate. But tdecimate doesn't remove duplicates as good a dedup.

[poisondeathray]

dedup is for VFR .

The duplicates are removed , the timecodes are used keep sync to compensate for the removed frames

times="blah.times.txt" are the timecodes (timestamps)

[midts]

I'm not sure I understand. What do I do with them?

[poisondeathray]

You either encode with the timestamps (e.g. x264 has --tcfile-in ) , or mux them into the container (e.g. mkvtoolnix , or mp4fpsmod for mp4)

That text file, the timestamps, controls display time per frame.

[jagabo]

But you don't want to use the timecodes. You'll end up with video that's about as jerky as the original.

[hello_hello]

I'm not sure I understand. What do I do with them?

I explained that in post #20.

Are you insisting on TDecimate giving you 25fps? Have you tried rate=24 instead to see if the duplicates are removed at that frame rate when doing 2 passes? Or after Dedup, work out the average frame rate using the method below and try using it as the frame rate for TDecimate.

For Dedup, you can try encoding as VFR with the timecodes to see if it's smooth. If it's not you'll need to work out the correct frame rate for AssumeFPS().

You can add Info() to the script to get the original frame count before Dedup, and again after Dedup to get the new frame count. Or you can use the log and timecodes files to work it out.

The end of the DupMC log file should look something like this. This source had a total of 9596 frames.

frm 9589: diff from frm 9590 = 0.0000% at (0,0)
frm 9590: diff from frm 9591 = 0.0000% at (0,0)
frm 9591: diff from frm 9592 = 0.0000% at (0,0)
frm 9592: diff from frm 9593 = 0.0000% at (0,0)
frm 9593: diff from frm 9594 = 0.0000% at (0,0)
frm 9594: diff from frm 9595 = 0.0000% at (0,0)
frm 9595: diff from frm 9596 = 100.0000% at (0,0)

Open the timecodes file with a text editor that'll display the line numbers. There's 8367 frames in this case (the last timecode is on line 8368 but the first line isn't a timecode).


[Attachment 62365 - Click to enlarge]

The original frame rate was 23.967 (24000/1001), so....

(24000/1001) / 9596 * 8367 = 20.9053 fps - AssumeFPS(209053, 10000)

For you it'd be
50 / original frame count * new frame count.

The problem you might have doing that way, is Dedup removes the duplicates and the remaining frames are spread out evenly. So if the dupes aren't fairly evenly distributed it can put the video out of sync with the audio. Imagine a video where every second frame is a dupe for the first half but there's no dupes in the second half. If you remove the dupes and encode at the average frame rate, it'd speed up the video for the first half and slow it down for the second half and make a mess of the A/V sync.

It can't hurt to try though. If you lose audio sync you'll probably have to reduce max copies and/or maxdrops to force Dedup to keep some dupes. Or encode as VFR.

That's possibly why TDecimate isn't removing every duplicate. I don't know anything about the algorithm it uses, but I suspect it tries to maintain A/V sync. Either that or you're forcing it to output the wrong frame rate.

[jagabo]

DeDup will disproportionately remove more frames from still shots. That will cause A/V sync errors unless you encode VFR. But if you encode VFR the unique frames will be marked with their original time codes so the video will playback as jerky as the original. The main purpose of DeDup is to remove duplicate frames while keeping the same timing (using the timecodes) not to smooth the video. But it can be useful for analyzing the original frame rate of video with dups.

I based my original 25 fps estimate on a 200 frame sequence (frames 200 to 399) of the first video using DeDup. There is continuous and significant motion during that entire sequence so it's easy to tell what's a duplicate and what's a unique frame.

LWLibavVideoSource("test.mp4", cache=false, prefer_hw=2) 
Trim(200, 399)
#DupMC(log="blah.dup.txt")
DeDup(threshold=4.0, maxcopies=4, maxdrops=4, show=true, log="blah.dup.txt", times="blah.times.txt")

Threshold values between 4 and 16 all results in 99 unique frames out of the 200. There's at least one missing frame in the original sequence as indicated by a 2x bigger motion than in others in that region (between frames 39 and 40, after the trim, before removing dups, between 18 and 19 after). That shot is very synthetic so it may not be indicative of the rest of the video.