Zulko / moviepy

Video editing with Python
https://zulko.github.io/moviepy/
MIT License
12.07k stars 1.51k forks source link

Unable to run moviepy on debian 10 #2189

Open belalsalih opened 4 weeks ago

belalsalih commented 4 weeks ago

I am trying to run some processing on video uploaded by users using azure functions(python), my code runs perfectly on local pc(macOS) however it is not running at all once deployed on kubernetes. logging into the pod and running: 'from moviepy.editor import *' will result in the following error:

>>> from moviepy.editor import *
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.9/site-packages/moviepy/editor.py", line 36, in <module>
    from .video.io.VideoFileClip import VideoFileClip
  File "/usr/local/lib/python3.9/site-packages/moviepy/video/io/VideoFileClip.py", line 3, in <module>
    from moviepy.audio.io.AudioFileClip import AudioFileClip
  File "/usr/local/lib/python3.9/site-packages/moviepy/audio/io/AudioFileClip.py", line 3, in <module>
    from moviepy.audio.AudioClip import AudioClip
  File "/usr/local/lib/python3.9/site-packages/moviepy/audio/AudioClip.py", line 7, in <module>
    from moviepy.audio.io.ffmpeg_audiowriter import ffmpeg_audiowrite
  File "/usr/local/lib/python3.9/site-packages/moviepy/audio/io/ffmpeg_audiowriter.py", line 7, in <module>
    from moviepy.config import get_setting
  File "/usr/local/lib/python3.9/site-packages/moviepy/config.py", line 36, in <module>
    FFMPEG_BINARY = get_exe()
  File "/usr/local/lib/python3.9/site-packages/imageio/plugins/ffmpeg.py", line 173, in get_exe
    return imageio_ffmpeg.get_ffmpeg_exe()
  File "/usr/local/lib/python3.9/site-packages/imageio_ffmpeg/_utils.py", line 28, in get_ffmpeg_exe
    exe = _get_ffmpeg_exe()
  File "/usr/local/lib/python3.9/site-packages/imageio_ffmpeg/_utils.py", line 44, in _get_ffmpeg_exe
    exe = os.path.join(_get_bin_dir(), FNAME_PER_PLATFORM.get(plat, ""))
  File "/usr/local/lib/python3.9/site-packages/imageio_ffmpeg/_utils.py", line 69, in _get_bin_dir
    ref = importlib.resources.files("imageio_ffmpeg.binaries") / "__init__.py"
  File "/usr/local/lib/python3.9/importlib/resources.py", line 147, in files
    return _common.from_package(_get_package(package))
  File "/usr/local/lib/python3.9/importlib/_common.py", line 14, in from_package
    return fallback_resources(package.__spec__)
  File "/usr/local/lib/python3.9/importlib/_common.py", line 18, in fallback_resources
    package_directory = pathlib.Path(spec.origin).parent
  File "/usr/local/lib/python3.9/pathlib.py", line 1082, in __new__
    self = cls._from_parts(args, init=False)
  File "/usr/local/lib/python3.9/pathlib.py", line 707, in _from_parts
    drv, root, parts = self._parse_args(args)
  File "/usr/local/lib/python3.9/pathlib.py", line 691, in _parse_args
    a = os.fspath(a)
TypeError: expected str, bytes or os.PathLike object, not NoneType

thanks.

antonpetrov145 commented 4 weeks ago

Same issue found on garuda linux

moviepy==1.0.3

Seems issue is related to searching for ffmpeg.exe no matter the os

As a workaround I changed

FFMPEG_BINARY = os.getenv('FFMPEG_BINARY', 'ffmpeg-imageio')

to

FFMPEG_BINARY = os.getenv('FFMPEG_BINARY', 'auto-detect')

in /venv/lib/python3.9/site-packages/moviepy/config_defaults.py and error is not present

You can also set the FFMPEG_BINARY=/usr/bin/ffmpeg (or where your ffmpeg binary is at) in your .env file - works as well.

belalsalih commented 4 weeks ago

since we are using azure devops to build/deploy the code, updating 'config_defaults.py' is not an option. setting up an env variable 'FFMPEG_BINARY=/usr/bin/ffmpeg' as per your suggestion fixed the issue.

thanks alot for the help.

antonpetrov145 commented 4 weeks ago

awesome

studioj commented 3 weeks ago

this is also happening on windows. A temporary fix could be to lock

imageio-ffmpeg<0.5

keikoro commented 2 weeks ago

Same issue found on garuda linux

moviepy==1.0.3

Seems issue is related to searching for ffmpeg.exe no matter the os

This would suggest the issue lies with imageio-ffmpeg and should be fixed there, not in MoviePy.

But a Linux system looking for an exe file does not square with:

this is also happening on windows. A temporary fix could be to lock

imageio-ffmpeg<0.5

@antonpetrov145 Are you sure it's trying to look for an .exe file? I had a cursory look at imageio-ffmpeg's code and got the impression it is more a matter of misleadingly named variables/function names.

The info about setting the ENV variable is probably the best advice, in any case, as the variable exists for a reason. Though it might make sense to better surface its existence? It's mentioned in the install instructions but not in the project README, for example.

antonpetrov145 commented 2 weeks ago

@keikoro if user doesn't set the FFMPEG_BINARY variable the default is ffmpeg-imageio FFMPEG_BINARY = os.getenv("FFMPEG_BINARY", "ffmpeg-imageio") but then

if FFMPEG_BINARY == "ffmpeg-imageio":
    from imageio.plugins.ffmpeg import get_exe

    FFMPEG_BINARY = get_exe()

my suggestion is to set the default to auto-detect then if user wants to use ffmpeg-imageio it can be set with ENV variable. With this the risk of the above error will be much lower IMO.

I tried both my suggestions - set to auto-detect and set env variable, both work. The question is - do we want to let users set the ENV or we can set to auto-detect by default in the code and have ffmpeg-imageio as option not relying on imageio-ffmpeg.

keikoro commented 2 weeks ago

Changing a default which a) has been in place for a long term, b) is documented and c) can very easily be circumvented by users may make sense in the long term but, as said elsewhere, would need discussing in one of the threads about the future of the project.

It's not something I'd be comfortable taking responsibility for at this point, with the project being kind of in limbo/awaiting review.

ETA: @antonpetrov145 I saw those variables/functions containing the word "exe", but what led you to believe the code is looking for an .exe file?

antonpetrov145 commented 2 weeks ago

@keikoro good, I was confused by the naming of the function, I checked the code for them and yes - my mistake, I will close this PR.