[FFmpeg-devel] Proposed vf_decimate enhancement

[Ray Cole]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vf_decimate.c
Type: text/x-csrc
Size: 20365 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20150928/5404a24a/attachment.c>