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
