[FFmpeg-devel] Proposed vf_decimate enhancement

[Paul B Mahol]

On 9/29/15, Ray Cole <the.other.ray.cole at gmail.com> wrote:
> I hope this is the appropriate place to propose an enhancement. This is the
> first time I've offered up code to any open source project...so be gentle
> :-)
>
> First, I love ffmpeg. Wonderful software and thank you for your efforts.
>
> I have been pulling down a number of movies back to 24 FPS (24000/1001)
> using fieldmatch and decimate. However decimate seemed to drop incorrect
> frames from time-to-time particularly on scenes with little motion. The
> pullup filter likewise made poor decisions under similar circumstances.
>
> So...I modified vf_decimate and it is working very well for me. I make no
> claims that the enhancements would work for anyone else. My source is 1080i
> 29.97 fps movies recording from component video. I'm pulling down to 24 fps
> (24000/1001 actually).
>
> The changes are:
> 1) The total and max diffs are used to find the lowest frame to drop rather
> than just the max diff. If these two methods disagree with one another then
> it goes through a 'conflict resolution'. The conflict resolution checks to
> see if either method matches the most commonly-dropped frame (a simple
> short-term history of drops is retained for this purpose). If so, the most
> commonly-dropped frame is assumed to be correct. If they do not match then
> it uses the last dropped frame. This keeps the filter from varying the frame
> drop so often and made a big difference in detection, at least with the
> stuff I'm working with.
>
> 2) The existing vf_decimate allows frame 4 to be dropped immediately
> followed by frame 0 whereas frame 3 dropped could never be followed by frame
> 4 dropped - similar with frames 0 through 2. Having 2 frames in a row
> eligible to be dropped seems wrong and the biggest issue I had was when the
> drop cycle was hitting frame 4. So I put in some code that says if the last
> frame dropped was frame 4 then frame 0 and frame 1 is not eligible for drop.
> If frame 3 was last dropped then frame 0 is not dropped. This enforces 2
> undropped frames between drops. I'm not "married" to this...but it did help
> quite a bit.
>
> 3) I had one movie where frame 4 was ALWAYS the correct frame to drop...so I
> added an option to 'lock on' to a pattern in 1 of 2 ways. The first way is
> for someone to pass force_drop=x where x is the frame number to drop each
> time. The other is passing lock_on=1 to tell it to figure out what frame it
> should lock onto. I mainly used this to assist in finding places where the
> code was dropping incorrect frames. I'm not sure I really consider this
> 'useful' for anything other than such testing where you know what should be
> dropped. It still goes through all the computations as before but insists on
> dropping the specified frame and noting if the computations resulted in a
> different frame than requested.
>
> I realize the attached code needs cleanup to conform to standards but I just
> wanted to put it up for discussion. The first change above is really the
> major change and it could (obviously) be enabled/disabled by an option to
> decimate if desired.
>
> -- Ray Cole
>

Whole file is unacceptable, how one can find what changed?, please
learn how to produce patches.