Log in

View Full Version : Smart "Duplicate Frame Detector"


bxyhxyh
9th December 2012, 13:28
1. Detects duplicate frames
2. Chooses cheapest one from duplicate frames
3. Replaces them with chosen cheapest frame

Is there any filter that can do such things?

Guest
9th December 2012, 13:50
What do you mean by "cheapest"? If they are duplicates how can one be "cheaper".

bxyhxyh
9th December 2012, 14:40
What do you mean by "cheapest"? If they are duplicates how can one be "cheaper".

Something like

duplicates=ABCD

A=10 bytes
B=9 bytes
C=11 bytes
D=13 bytes

chooses B as cheapest then result is BBBB.
-------------------------------------------
Sorry my english is not so good.

sneaker_ger
9th December 2012, 16:20
I don't think such a filter exists. The problem is that AviSynth works with uncompressed video data, so all frames will have the exact equal size.

martin53
9th December 2012, 17:12
bxyhxyh,
use Donald Graft's dup filter made in 2003, or use RT_LumaCorrelation() from StainlessS's RT_Stats package to measure the similarity of two frames. Identical frames would have RT_LumaCorrelation==1.

If what you call cheapness is the contrary of what I call quality, then you find a filter in the script FSubstitute provided in the thread 'bye bye blurred frames'.

bxyhxyh
9th December 2012, 17:46
Thanks for responses.

I don't think such a filter exists. The problem is that AviSynth works with uncompressed video data, so all frames will have the exact equal size.

I thought some debugging filters can choose small sized frame from duplicates.

Such as
We know a.sharpen(0.2) is more "expensive" than a. But problem is can avisynth knows it?
subtract(a,a.sharpen(0.2))
http://farm9.staticflickr.com/8066/8257244307_e2937292ff_b.jpg

subtract(a.sharpen(0.2),a)
http://farm9.staticflickr.com/8060/8257243967_35f7dcdd07_b.jpg

bxyhxyh,
use Donald Graft's dup filter made in 2003, or use RT_LumaCorrelation() from StainlessS's RT_Stats package to measure the similarity of two frames. Identical frames would have RT_LumaCorrelation==1.

If what you call cheapness is the contrary of what I call quality, then you find a filter in the script FSubstitute provided in the thread 'bye bye blurred frames'.
I know about dup, dupped, and bye bye blurred frames.
dup and dupped can't choose "cheap" frame cause result may big or small sized when compress it. (because sometimes chosen frame is more noisy than others etc)

I desired smallest possible file size by replacing duplicates with "cheap" frame.

By the way I don't desire VFR. Even if it is VFR, filter has to drop "expensive" frames.

johnmeyer
9th December 2012, 18:27
You might take a look at some of the following posts from several years ago.

automated framedrop filler script (http://forum.doom9.org/showthread.php?p=753779#post753779)

FillDropsI (http://forum.doom9.org/showthread.php?p=1493082#post1493082)

Sometimes the capture card drops a frame, and this creates a "jump" in the motion. Then, to keep the audio in sync, it adds a duplicate frame, but doesn't get around to doing this until several frames after the dropped frame. In this case, you want to decimate (remove) one of the two duplicate frames, but then you have to go looking for a nearby "jump" in the motion, and insert your motion-estimated frame at that point. This is a much, much more difficult chore, but one that can still be done (in some cases) in a single pass, with conditional logic. I started a thread last spring about this exact subject, and got a tremendous amount of help that resulted in (for me) a very good solution. Here's the link to that thread:

Automatically fix dups followed (eventually) by drops (http://forum.doom9.org/showthread.php?p=1510780#post1510780)

I think this last link may give you something that will choose the "cheapest" frame.

jmac698
9th December 2012, 20:37
You might be better off just averaging all the duplicates, now they have less noise and will compress even better than any one of them.

martin53
9th December 2012, 21:34
It seems you head for a more academic than practical approach.
If intricateness it not a matter for you, you can
use ImageWriter() with a compressing format for every frame, then Call() an external program that gives you the size of the image file.
That way, you will certainly get information about 'cheapness' of any frame on itself.
Anyway, you should keep in mind that for the smallest file size possible, compressibility of delta between pictures matters - since you are not going to compress it with MPEG1, are you?

So, with the information that one frame contains little information, nothing is won. You need to know if the information this frame lacks is more or less constant from a previous frame to a following one. Then, an apparently less 'cheap' frame would lead to better overall compressibility.