-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Imageio's new use of imageio-ffmpeg #908
Comments
Thanks so much for writing this, it helps me wrap my head around the issue. I believe this supports my impression that I have solved the problem in moviepy and that all is left is to push to PyPI (and document the marginal linux case). Great work on imageio and imageio-ffmpeg btw. |
I'm glad it helps (note that I made a few small changes). Sorry again for not putting you in the loop earlier; you would have been able to better anticipate. |
I was in the loop really, since the end of last year when you tagged me on some imageio PRs or issues, so I saw it coming. I just never had the time and brain space to work on it or even think about it 😛 . |
Yeah, the plan to "change something about imageio's ffmpeg plugin" has been lingering for quite a while. However, the choice for "how", and the change itself, happened rather quickly. I should've written this issue when that happened :) |
tiny question: as soon as I try old moviepy example, like
Is it because of an old example, or could we benefit the imageio_imagemagick wheel treatment for that too ? (windows user) |
I had no clue this package existed, it could definitely be a solution! Although I would be happy to ditch ImageMagick altogether (I used it as a quick way of prototyping MoviePy, but it is big and slow) and replace it with Pillow or Cairo. |
Hum, the package doesn't exist . I would prefer you move to pillow/ Cairo, if it was possible |
Oh I see. The problem with PIL is that you need to provide the TTF font files every time you want to use a non-default font. See here for an example. The problem with Cairo is that it is difficult to install for some systems. But you can use this method to generate texts with it. |
Correct me if I'm wrong, but I think @stonebig was asking whether the approach to package a binary in platform-specific wheels (as done in imageio-ffmpeg) might be a viable solution for Imagemagick too. If that was indeed the question, I would wait for a few months to see how this approach works out for imageio-ffmpeg :) But I obviously anticipate that it makes things easier. For the record, the platform-specific binaries can be build and uploaded with a single command from any Unix platform. |
You're not wrong. |
I believe this is the reason why Dockerfile fail to build with |
Fixes yownas#41 by adding imageio-ffmpeg to extension requirements/dependencies. This is required due to some changes with moviepy's underlying imageio library, which has deprecated/removed the old autoinstallation method around 2019-ish, and as such moviepy is no longer capable of autoinstalling ffmpeg. See Zulko/moviepy#906 and Zulko/moviepy#908 for further details on the moviepy side. This does result in downloading ffmpeg on systems where it may already be installed, but it's a reasonably small download and on some systems (eg Ubuntu 22.04) moviepy 1.0.3 fails to pick up system ffmpeg anyway.
edit: hit the wrong key and posted this before it was done.
Hi there,
I meant to post an issue for a heads-up about the new situation, but I guess I forgot. So here it is. I realize that the change means some "upstream pain", but it was needed to keep imageio managable.
In short
Imageio previously had you download the
ffmpeg
executables using a function or a CLI command. This behavior has changed. Instead, using imageio's ffmpeg plugin now requires the newimagio-ffmpeg
library. This library contains a low-level ffmpeg wrapper, and ships the ffmpeg binaries via platform specific wheels.Background
(You can skip over this)
The reason for the change is that the strategy with the explicit download was clumsy, and more importantly a security hazard. Combined with the fact that about 50% of imageio's incoming issues were related to ffmpeg, I decided to spin the ffmpeg bit out. We also considered other ffmpeg wrappers, but distribution remains hard, so I decided on a solution that ships the exes in the platform specific wheels. The (low level) wrapper should also be more stable (e.g. wrt terminating ffmpeg subprocesses), and can be improved upon by people who care about ffmpeg more easily.
What to do (for Moviepy and its users)
Dependencies
The eventual solution should be to add a dependency on
imageio-ffmpeg
, but I could not put myself to write py27 compatible code in 2019, so as noted above,imageio-ffmpeg
is py3k only. I guess that Moviepy will drop 2.7 support somewhere this year? Ah, I just saw that you pinned imageio to<2.5.0
for older Python versions. That should do it.The binaries will stay up for the old versions of imageio. At some point I removed some older ones (matching a 1.5 year old imageio version), but these are restored.
The platform specific wheels do not work on all platforms
The platform-specific wheels are, well, platform-specific, so some platforms will just install the tarfile (some Linuxes). Also, some platforms may install the wheel, but the ffmpeg exe may not work (e.g. Windows XP).
Also see the corresponding issue. In short, I suspect that the platform does not match
manulinux2010_x86_64
, which is a consequence of the platform that the (new) ffmpeg exes were build on. The solution is to document that Linux users (that don't use a "modern desktop Linux") may want to use:Other needed changes?
@Zulko It would be good to have a look at these release notes. The main part, other than what you know now, may be that the wrapper no longer attempts to guess the number of frames from the fps and duration. The
reader
object has a method to get an exact count, but its slow (so we can't use it by default).I am not sure if Moviepy uses other imageio functionality, but it may be worth considering using
imageio-ffmpeg
directly. Note though, that support for webcams, seeking, and looping, is still implemented by the ffmpeg plugin.The text was updated successfully, but these errors were encountered: