search

tfaehse / DashcamCleaner

Censor identifiable information in videos, in particular dashcam recordings in Germany.
GNU Affero General Public License v3.0
131 stars 27 forks source link

introduce `-crf` option for ffmpgeg compression after blurring #26

Closed joshinils closed 2 years ago

joshinils commented 2 years ago

since the resulting video files can be unnecessarily huge (and not really playable with vlc on my machine...) i introduced the -crf option which gets passed to ffmpeg after blurring.

the default for the new -crf option is the same as previous behaviour, i.e. -1 which is outside the range for ffmpeg.

but changing the default to something more sensible is also an option. ffmpeg has a default of 23 if you do not specify -vcodec copy. I have never been able to see a difference for values lower than 18, which to my eyes almost looks lossless.

Of course if one wants to edit the video clip afterward into a collection of other small clips then using the lossless video and an extracted frames quality of 10 is ideal, but that will require a larger burden in their machine while editing

joshinils commented 2 years ago

so far the code has a problem, it can not find the dict value...

joshinils commented 2 years ago

so far the code has a problem, it can not find the dict value...

ah, i misstook the self.parameters for an object, it is a dict. all fixed now, i hope.

joshinils commented 2 years ago

image example table for a very short clip. the crf -1 and 0 filesizes are identical. of course the crf 43 videos look like garbage and the quality 1 too. but comapred to the original unblurred test-clip of size 20.5MB the 260MB are unreasonably big i think

tfaehse commented 2 years ago

I think we may be able to skip this - I've taken a deeper look at imageio, it looks like the quality option (that the cli/gui expose directly already) is just an abstraction by imageio. On the inside, it actually uses the crf parameter in ffmpeg, but only when using libx264 (we do).

So effectively, changing the quality for the original writer already sets crf, doing it again at the end would just re-encode the video once more. A quality of 5 corresponds to a crf of 25, which explains why re-encoding it with 23 still slightly reduces the file size. I guess that if you were to try that with 25 the files would be a near-exact match.

joshinils commented 2 years ago

aha! i just tried allowing a float for quality, that works! so changing the cli type to float and the range to a list of floats will work.

I will prepare a Pull-request for that, allowing one decimal place for quality and thus finer control.

so for my understanding, imageio creates a video file with the same compression as ffmpeg would in a second pass? i did not know that.

interestingly the imageio assert does not allow for a crf value higher than 45: https://github.com/imageio/imageio-ffmpeg/blob/7bfe71d4a23fa881c792d23e0cf67ef4fc446dd8/imageio_ffmpeg/_io.py#L486

since (1 - 46 / 51) * 10 < 1 ... :stuck_out_tongue_closed_eyes: but I guess that bad of a quality no one cares about.