Possibility to avoid code duplication

[almarklein]

A while back I took some code from moviepy and used it to create an ffmpeg plugin for imageio. Since then I suppose both pieces of code for this purpose have diverged, which is a bit sad. Similarly, both projects now have code for gif. I was hoping we could explore a bit the possibilities for avoiding code duplication related to reading and writing of movie data.

I suppose to start off, we need a clear idea of the purpose of both projects. Imageio is intended to provide easy reading/saving of all sorts of image data. From simple images to volume, and including movie data. Imageio currently has plugins for ffmpeg, avbin, animated gif and swf (flash). The purpose of moviepy is (correct me if I'm wrong) to allow editing/processing of movie data (which is precisely what imageio does not want to do).

One option would be to make imageio a dependency of moviepy, but I can imagine you're not waiting for another dependency. Also, I suppose you need dealing with sound, which imageio does not support. Similarly, I'm reluctant for an extra dependency for imageio.

Another option could be to write the code for ffmpeg and gif in a way that we could both use it in our projects. We'd have to agree on which library holds the reference, or at least be consistent with backporting. Not sure if it would work well in practice, but it might be worth a try ...

WDYT? Is this worth looking into, or would it be more pain than gain?

[Zulko]

That's a valid point. MoviePy is really about the clip classes and I wouldn't be against outsourcing the IO to imageio (maybe when I want avconv support). However I am not in a hurry right now, I like to be in control of my IO a little longer to try some more advanced stuff. For instance, if I find the time I'll try some advanced things like a file connection manager which allows users to connect to hundreds of images and videos simultaneously. I'm not sure if you want that in ImageIO (it's an additional layer of complexity in the program) but that can be useful.

[almarklein]

I'd have to know some more about the file connection manager, but I suspect it's a layer that's more at its place in moviepy. Even if we can find a subset to put in "shared codebase", I suspect that that bit would be relatively small, due to the different purposes of the libraries.

Maybe the most lightweight solution is simply to keep in touch, and share new functionality or important bugfixes, that we can then each backport to our own projects.

BTW: what do you use for gif, is it a pure Python module?

[Zulko]

Ok, let's use this issue as a discussion thread.

For Gifs withs MoviePy (source code)can use either ffmpeg (it works exactly like for videos, but produces very noisy gifs) or ImageMagick. ImageMagick is very powerful when it comes to optimizing, but it is yet another external dependency, it is slow, and it requires all the frames to be in the RAM at some point (you can also choose to write them to a file).

Speaking about functionality, I have one important functionality that I can't find in ImageIO and that I am sure the scientific community digs, it's the capability to go fetch a time in a video file. Say for instance I want to read a 3 hour long video starting at 1h30, ffmpeg (and avconv) can start there in a way that is much faster than just iterating through the frames. I don't know if it's possible in imageio/ if you'd be interested by that.

[almarklein]

This should work:

 reader = imageio.read('cockatoo.mp4', 'ffmpeg')  # explicitly use ffmpeg
 meta = reader.get_meta_data()
 im = reader.get_data(frame_in_seconds * meta['fps'])

The ffmpeg plugin should be be selected, because the avbin plugin cannot seek (avbin itself does not support that).

[almarklein]

Ah, I was secretly hoping you had a pure Python implementation for GIF :)

You could consider using imageio as on additional "gif-backend". The gif plugin is based in freeimage. Compression is good (neuqant algorithm). Not sure how it currently behaves with large files. FreeImage may keep frames in memory for performance, but that can be turned off with a flag.

[Zulko]

After a few tests of ImageIO I am impressed. I like how the binaries are imported smoothly and the gif generation is just wow, now I can't believe I stuck with ImageMagick so long. Maybe MoviePy can stop being "the library that takes one day to install and even longer to make a GIF".

My current plan is to make imageio a dependency of MoviePy, with the following steps:

• First, a hack which will simply use imageio to get a ffmpeg binary when necessary and retrieve the path of this binary. This ffmpeg binary will be used by MoviePy's original code (not imageio's code) for audio and video extraction/writing.
• Then, make GIFs with imageio by default.
• Finally replace the video writing/reading by imageio-based routines. I am not sure in what extent this will be possible, MoviePy's code is tweaked in many ways, I am a little afraid of breaking something.

Are there any difficulties I should be aware of ? Can you confirm that it works on Windows/Mac/Linux, Python 2 and 3 ?

[almarklein]

That's awesome! Great that we can divide the roles of the packages in this way. You're approach seems very reasonable. I'd be happy to accept any necessary changes to make this work for you.

Imageio is designed to work for Windows/Mac/Linux, and Python 2.6+ and 3.x. Also Pypy. I have plans to make it work on raspberry pi. It may also be of interest that I am considering making Numpy an optional dependency, which would make it easier to install, and should make it available on Jython and IronPython.

[Zulko]

FFMPEG download and default GIF writing are now through imageio in MoviePy ! Fingers crossed !

[keikoro]

Since imageio was integrated into MoviePy a long time ago, this can be closed.