Moviepy Roadmap - version 2.0

[tburrows13]

I’d like to propose an upcoming v2.0 which would allow us the opportunity to make a few small breaking changes, and remove some of the previously deprecated features.

Here’s some of the things that I’d like to include:

• [Start v2.0 branch. Remove support for Python 2.7 & 3.4. #1103, Remove support for Python 3.5 #1106] Remove support for old Python versions (Drop support for python < 3.6 #1081)

  • Definitely 2.7 and 3.4, perhaps 3.5 as well?
  • Py3.5 is not EOL yet, accounts for about 2% of our installs (https://pypistats.org/packages/moviepy), and the number of new features in Py3.6 is very small (but it might be worth it just for the f-strings)
  • This would allow us to get rid of a lot of complicated and hacky code

• I’d like to go through the backlog of complaints about resource usage and proper closing of clips and create a consistent cross-platform solution that can work for everyone, using some to-be-decided combination of .close(), .__del__() and context managers (with ...:). This would most likely not be backwards-compatible (Fixed problems with proc package #1016, Don't close the audio reader which might be linked from a shallow copy. #1059).

• We could enforce use of “keyword-only” arguments with the * (https://www.python.org/dev/peps/pep-3102/)

  • For instance, the definition of VideoFileClip would become

    def __init__(self, filename, *, has_mask=False,
         audio=True, audio_buffersize=200000,
         target_resolution=None, resize_algorithm='bicubic',
         audio_fps=44100, audio_nbytes=2, verbose=False,
         fps_source='tbr'):
    

  • So VideoFileClip("file.mp4", True, True, 100000) would now be invalid

• If it were possible to get rid of ImageMagick as a dependency, that would be amazing, its possible that everything that we use it for can now be done with imageio or one of our other, better behaved, dependancies. (Discussion in Imageio's new use of imageio-ffmpeg #908, TextClip produces low quality text #1472)

• There are a lot of functions/methods with lots of optional parameters like https://github.com/Zulko/moviepy/blob/master/moviepy/video/fx/crop.py that require certain combinations of arguments to work. It would be nice to have a neat way of expressing this, maybe with decorators?

• [Remove deprecated functions and parameters #1115] We can remove old deprecations

  • to_videofile -> write_videofile
  • to_audiofile -> write_audiofile
  • ColorClip(col=...)

• [Renaming methods, parameters and variables for increased usability, consistency and readability #1170] We could go even further and improve the API even more

  • set_duration -> with_duration etc is a common sticking point for new users not realising that it doesn't act inplace (TextClip positioning does not work #886) (or do what pandas does and have an inplace=False parameter to everything, possibly handled by a decorator)
  • Similar improvements to the set_start (set_start and set_end have no effect other than changing the clip's duration #995)

There are other things that need to be done, that, whilst they could be released at any time, would be good to include as part of a larger package

• Implement basic data model #1076 implements support for built-in Python operators
• I'm working on improving the install/test/build/release system
• Updated/checked examples would be great
• Generally the documentation is lacking in some areas; at a minimum it should state every parameter that a function accepts
• Any other small features (Add support for path-like objects #924...)

Since there's a lot of changes here, I'd propose merging them into a v2 branch first, before finally merging that into master when we're ready to release.

Anything else that you can think of, agree/disagree with, let's discuss either here or on gitter!

[misland]

hi,do you hava a plan for this package to make it support GPU?

[tburrows13]

@misland Thanks for the suggestion, I'll add it to the list. There's clearly interest (#790, #923), and it looks like it would be just a case of configuring FFmpeg settings.

[misland]

@tburrows13 thanks for your reply,I also checked #790 and I will test ffmpeg which compiled with gpu library later,I will post the result when I finish testing.

[misland]

@tburrows13 hi,I modify the ffmpeg_reader.py as follows:

I execute one python script to process mp4 video,then I do see two processors by nvidia-smi,as follows:

it seems to worked,but the cpu cost didn't go down at all,so I don't think gpu acceleration take effect,hope it helps to you :(

[tburrows13]

@misland, thanks for investigating. I'll have a look at some point to see if it would be benificial, but it doesn't seem to require much extra code on our part, so it will probably end up being an option for end users to use if they want to.

[tburrows13]

I don't think that having v2 as a separate branch is really working, so I'll release v1.0.2 today, and then merge master into v2, then v2 back into master, so that new contributions will automatically be based off the v2 code.

[tburrows13]

I don't think that having v2 as a separate branch is really working, so I'll release v1.0.2 today, and then merge master into v2, then v2 back into master, so that new contributions will automatically be based off the v2 code.

Now done, so all v2 code is in the current master branch.

[mgaitan]

Oh, didn't see these last comment. I've been opening the prs against v2 :-)

[tburrows13]

Ok, I'll delete v2 now as it doesn't seem to have any purpose.