[FFmpeg-devel] Proposed vf_decimate enhancement

[Stephen Cole]

Thank you for the responses. I assumed the comments would suffice for discussing it initially so one wouldn't have to interpret the patch. I'll produce a diff and resubmit.

> On Sep 29, 2015, at 2:16 AM, Paul B Mahol <onemda at gmail.com> wrote:
> 
>> 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.
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel