Alternatives to Fdecimate and Tdecimate

[rec]

Are there any alternatives to Fdecimate and Tdecimate for removing duplicate frames?

Thanks!

[Didée]

DeleteFrame()

[rec]

Thanks, but I meant something that can seek out and destroy duplicate frames.

[manono]

Decimate is another one.

Do you have a particular problem with the decimation? If so, can you post a small sample showing the problem?

[rec]

I understand and appreciate that these decimation algorithms are designed to maintain a target frame rate. So, if you have a clip with too many duplicates, they won't remove all of them because the target frame rate would change and audio would go out of sync.

I have clips where that is exactly the problem.

The ideal decimator would be one that destroys the duplicates regardless of how many there are, and if the resulting frame rate falls below the target, it would synthesize in-between frames using mvtools.

Is there such a thing?

[manono]

Decimation keeps the video length the same so there's no reason for the audio to go out of synch. If it does it's for a different reason. If the 'base' framerate is something different from the usual ones, the Decimators can be configured to decimate to that framerate. If the dupes are in some sort of random pattern with no true average framerate, your best bet might be neuron2's (Donald Graft's) MultiDecimate filter. It's possible to get out of synch audio when using it, but the parameters can be tuned to keep that from happening (usually). As for creating new frames to keep the audio from getting out of synch, maybe someone else can help. I've never seen such a video stream where that might be necessary.

[bin_ch]

DeDup is probably what you are looking for.

[rec]

I tried DeDup, but unless I'm missing something, I don't see any provision for synthesizing new frames.

[AzraelNewtype]

The closest thing to what you're describing is probably Dup, which doesn't destroy frames but inserts copies of the first so they have no delta and compress to nothing. Of course if you don't have any reason you can't use a proper vfr container DeDup is probably better.

I'm not entirely certain what you mean by synthesizing in-between frames though. If you're destroying duplicates, there's no differences to interpolate, unless you want to create new frames in places that didn't originally have them to bolster the fps, but that will similarly destroy a/v sync.

[rec]

The problem with these clips is the duplicate frames were inserted in place of real frames when the video was originally captured. If you remove all the dupes, there won't be enough frames left to maintain audio sync. So, either you don't throw out all the dupes (which is what fdecimate and tdecimate do), or you throw them out and synthesize in-between frames to fill in what should have been there in the first place.

The situation is further complicated by the fact that some duplicates are just duplicates - there's no missing frame involved.

This is a very difficult problem, and it's probably not possible to solve. But, I thought I'd throw it out here to see if somebody had done anything like it.

[osgZach]

Couldn't this problem be solved with VFR Decimation ?

Either way, it sounds like what you really need is to manually decimate the file, picking and choosing which dupes you want to keep. Is your source animation or live footage?

[Maccara]

Could you lay out what you actually want/need to achieve? It is not currently quite clear and a bit conflicting.

This sounds like you want to do something like MVFlow etc processing for the duplicate frames (i.e. interpolate the missing frames)? Can do, but is either a bit of manual work or some custom scripting - don't know of anything out of the box. And the results can not be perfect.

You are also talking about how sound sync is destroyed and that's why DeDup etc are failing. However, if you just want to get rid of the dupes, DeDup + VFR muxing will do the job just fine and will preserve audio sync.

If sound sync not working with DeDup, there's a problem with playback (or something else done incorrectly). Just played with it a week back with footage which had mostly duplicate frames and had no sync issues after processing, even though ~80% of frames were decimated (70fps footage reduced to ~15fps). This of course requires a container which supports variable framerate (f.e. mkv or mp4) and may be problematic if you're targeting some specific standalone playback device.