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 <one...@gmail.com> wrote: > >> On 9/29/15, Ray Cole <the.other.ray.c...@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@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel