On 09/29/2015 12:46 PM, Paul B Mahol 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.
To produce patch
Hint: > git add
> git commit
> git send mail or > git format patch
-Anshul
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
