Allow resizing frames in ffmpeg when reading

[gyglim]

This PR is adds the possibility to read videos frames that have been resized in ffmpeg.
This is much faster than streaming in high-res and then resizing in python and important for applications where speed is crucial

[coveralls]

Coverage decreased (-0.08%) to 46.781% when pulling 124109a on gyglim:lowres into caf955c on Zulko:master.

[Zulko]

Interesting. Ideally, I would be for using ffmpeg just for decoding the video, and then do all the logics inside moviepy. Can you give numbers on how much you time your PR saves ? How do you explain the speed difference between resizing on ffmpeg side versus on moviepy's side ? It's C routines on both sides.

[gyglim]

I had a look at 1 minute of video at 1280x720 resized to 128x128 and got the following numbers

Linear interpolation:
Read resized with FFMEG linear:
1 loop, best of 3: 4.66 s per loop
Read resized with FFMEG fast_linear:
1 loop, best of 3: 3.83 s per loop
Read and resize with OpenCV:
1 loop, best of 3: 5.18 s per loop
Note: OpenCV does not provide fast_linear.

Area interpolation, which is used by moviepy, as I understand:
Read resized with FFMPEG:
1 loop, best of 3: 5.47 s per loop
Read and resize with cv2:
1 loop, best of 3: 10.4 s per loop
Read and resize with moviepy:
1 loop, best of 3: 11.2 s per loop

differences for cubic are smaller.
I suspect ffmpeg has more efficient resizing. And there is a little bit of cost of writing and reading the binary stream I would assume.

Also run the same comparison of OpenCV2 vs ffmpeg on a larger machine (32 cores) and got
Read resized with FFMEG linear:
1 loop, best of 3: 1.36 s per loop
Read and resize with OpenCV:
1 loop, best of 3: 5.8 s per loop

So it seems ffmpeg has better mutlithreading.
@Zulko What do you think?

[coveralls]

Coverage decreased (-0.08%) to 46.781% when pulling 469a6e4 on gyglim:lowres into caf955c on Zulko:master.

[coveralls]

Coverage increased (+0.2%) to 47.605% when pulling 57bd77a on gyglim:lowres into 0b40803 on Zulko:master.

[ghost]

@Zulko Since you have contributed to this conversation, I want to give you a chance to approve/disapprove this PR.

[Zulko]

I'd say approve. I am a bit against creating another way of resizing and against using ffmpeg for more than read/write, but in this case it seems that there is much to gain (and I cant think of a simple way to get the same performance).

[coveralls]

Coverage increased (+1.2%) to 48.624% when pulling 097b4a6 on gyglim:lowres into 0b40803 on Zulko:master.

[gyglim]

Awesome. Another advantage I see is that it is the same for everyone. The resizing in moviepy tries OpenCV, the PIL, then scipy:

moviepy/moviepy/video/fx/resize.py

Line 4 in 32b7007

# TRY USING OpenCV AS RESIZER

But everybody needs to have ffmpeg if they are using moviepy. Not necessarily OpenCV. Resizing with PIL is much slower

bilinear:
1 loop, best of 3: 12.1 s per loop
ANTIALIAS (as used in moviepy):
1 loop, best of 3: 21.7 s per loop

where ffmpeg bilinear was:
1 loop, best of 3: 5.47 s per loop

I know scipy is also slower from earlier tests.

[gyglim]

give me a minute before merging anything

[Zulko]

@gyglim I know, I use Pillow by default in moviepy because it's lightweight and easy to install everywhere. It's not difficult to create a custom filter using opencv's resize.

Thanks for the PR, it's a solid one. For future contributions, please make sure to use PEP8 (all lines <80 chars) and consistent names (resize_algo vs resize algorithms).

[coveralls]

Coverage increased (+1.2%) to 48.624% when pulling 3ff5169 on gyglim:lowres into 0b40803 on Zulko:master.

[gyglim]

@Zulko Thank you.
re PEP8 and variable names: Will do.

fixed that you can do also up-scaling incl. test (was an artifact from our own version).
From my side it is all good now