WIP: Feat process fit

[zlavergne]

Untested. I implemented the functions I had outside of the tools. Related to #327
cc @josealb

[zlavergne]

@bob3bob3 I wasn't aware of that. I found this in the ffmpeg docs which is why I added the flag:

You can select a video quality level with -qscale:v n (or the alias -q:v n), where n is a number from 1-31, with 1 being highest quality/largest filesize and 31 being the lowest quality/smallest filesize.

It may depend on ffmpeg version though. If -qscale 1 is backwards compatible and still works in the current [email protected] (I think) then it may be better to remove the :v. What do you think?

[bob3bob3]

@zlavergne qscale originally had no v argument I think as it also affected the audio stream. An ambiguity warning is given, but nothing adverse happens for us. I'd suggest keeping the :v argument.

I also mis-spoke on my last. The flag(s) to ensure the value of 1 are -qmin 1 and -qmax 1. I mentioned this in #311 I don't suggest this be changed as the improvement is minimal for a large increase in file size.

[bob3bob3]

Examples; These are index frames taken from the BlackVue DR900 and processed with ffmpeg

ffmpeg -i file.mp4 -vf "select=eq(pict_type,I)" -vsync vfr -qscale:v 1 2q/File_%6d.jpg

ffmpeg -i file.mp4 -vf "select=eq(pict_type,I)" -vsync vfr -qscale:v 1 -qmin 1 -qmax 1 1q/File_%6d.jpg

720KBytes vs 1100KBytes. Does one look any better than the other? (Does github reprocess?) To avoid ambiguity qscale:v 2 might be used as it will give the same result as current. If qscale:v 1 is really desired then -qmin 1 -qmax 1 switches are required.

[fgouget]

The "added missing comma" commit (924b14d) should be merged with commit 1255687.