V2.0 update for code & documentation

[OsaAjani]

• I have provided code that clearly demonstrates the bug and that only works correctly when applying this fix
• I have added suitable tests demonstrating a fixed bug or new/changed feature to the test suite in tests/
• I have properly documented new or changed features in the documentation or in the docstrings
• I have properly explained unusual or unexpected code in the comments around it

---

This is it, the candidate PR for v2.0 release as mentioned in issues #1874, #2012 and #1089, with both code update and documentation update.

I wont go in details over all the changes in this PR as they're too many, but roughly, for MoviePy itself:

• Update of all effects to use class instead of simple functions
• Improve consistency in the entire API and especially for clip methods naming
• Fixing a few bugs here and there
• Getting rid of many dependencies (scikit, imagemagick, opencv, etc.) and reducing image manipulation lib to only using pillow
• Updating many dependencies to more recent versions
• Complete suppression of moviepy.editor and runtime magic such as auto-adding of effects as clip methods
• A complete refactoring of clip previewing to replace pygame and other tools with only ffplay
• Fixing and updating a lot of in-code documentation
• Lot of unit test fixing and updating to follow the new API
• And probably a lot more things I'm forgetting

For the documentation:

• Update to a new sphinx theme with PyData theme
• A total restructuring of the documentation to be in 4 parts, getting started, user guide, developer guide and API manual
• Writing of a 10 minute introduction tutorial to moviepy
• More logical and chronological organization of the previous "user guide"
• Lot of general updating to follow the new API
• Lot of examples writing with more realistic scenarios and full testing on doc examples
• Improvement of the API doc auto-generation
• And again a lot more things I'm forgetting

The documentation certainly need to be improved and proof-readed. I'm sure it's pretty obvious from my english, but I'm not a native speaker, and I'm sure that the documentation will be full of grammatical errors, typos, and down right atrocious writing (and because writing doc is such a tedious and forth and back process, I'm sure there is also many logical error, forgotten sentences, unclear explanations, etc.). So I would strongly advise for at least a superficial proof-reading by a native speaker. If not for substance, at least for form.

I'm sure some old bugs still exists, but everything is passing the unit tests, and most bugs should probably be easily addressable along the road. So, I think this PR should be merged as soon as possible (I would say as soon as the first proof-read is done), the documentation updated (keeping the old doc accessible under something like /v1 would be good though), and the PyPi module updated, then we can see what we want to do for the future.

[Zulko]

Thank you so, so much for all this!! I am taking a look but it will take time! At first sight this looks like a tremendous improvement though 👍

[OsaAjani]

No problem, I am quite busy right now, but if you have any question do not hesitate to ping me!

[Zulko]

Update to say I still haven't had time to look through deeper, but I am taking a week off work next week and this will be high on my todo list.

[OsaAjani]

Ok, do not hesitate to ping me if you need anything

[OsaAjani]

Hey @Zulko any news ?

[mgaitan]

Adding nearly 50MB of multimedia files directly into the codebase of the project (see docs/_static/medias/getting_started/moviepy_10_minutes) isn't ideal. Firstly, these large files can make our repository grow significantly in size. Over time, this makes operations like cloning more time-consuming. Git, by its nature, is optimized for text changes and struggles with large binary files like videos. Every time we modify such a file, Git essentially stores a new full-sized copy, causing rapid bloat. Moreover, GitHub itself has guidelines about file and repository sizes. The files you're adding take up half the recommended maximum for a single item, and we should be mindful of that. I'd recommend looking into Git Large File Storage (LFS) if we want to track these files, or even hosting them externally and linking within our documentation (why not upload them to youtube?). El jue, 21 sept 2023 a la(s) 09:15, Pierre-Lin Bonnemaison ( ***@***.***) escribió:

…

Hey @Zulko <https://github.com/Zulko> any news ? — Reply to this email directly, view it on GitHub <#2024 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAR7EB5JWSL5M5IYXNXTOJTX3QVV7ANCNFSM6AAAAAA3JEOIUA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[Kaszanas]

By any chance does this solve this, Or does this have to be a separate issue?

• https://stackoverflow.com/a/76616129/11187592

/usr/local/lib/python3.10/site-packages/moviepy/video/fx/resize.py:152: in resize
    newclip = clip.fl_image(fl)
/usr/local/lib/python3.10/site-packages/moviepy/video/VideoClip.py:490: in fl_image
    return self.fl(lambda gf, t: image_func(gf(t)), apply_to)
/usr/local/lib/python3.10/site-packages/moviepy/Clip.py:136: in fl
    newclip = self.set_make_frame(lambda t: fun(self.get_frame, t))
<decorator-gen-61>:2: in set_make_frame
    ???
/usr/local/lib/python3.10/site-packages/moviepy/decorators.py:14: in outplace
    f(newclip, *a, **k)
/usr/local/lib/python3.10/site-packages/moviepy/video/VideoClip.py:644: in set_make_frame
    self.size = self.get_frame(0).shape[:2][::-1]
<decorator-gen-11>:2: in get_frame
    ???
/usr/local/lib/python3.10/site-packages/moviepy/decorators.py:89: in wrapper
    return f(*new_a, **new_kw)
/usr/local/lib/python3.10/site-packages/moviepy/Clip.py:93: in get_frame
    return self.make_frame(t)
/usr/local/lib/python3.10/site-packages/moviepy/Clip.py:136: in <lambda>
    newclip = self.set_make_frame(lambda t: fun(self.get_frame, t))
/usr/local/lib/python3.10/site-packages/moviepy/video/VideoClip.py:490: in <lambda>
    return self.fl(lambda gf, t: image_func(gf(t)), apply_to)
/usr/local/lib/python3.10/site-packages/moviepy/video/fx/resize.py:150: in <lambda>
    fl = lambda pic: resizer(pic.astype('uint8'), newsize)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

pic = array([[[23, 28, 27],
        [23, 28, 27],
        [23, 28, 27],
        ...,
        [15, 26, 25],
        [15, 26, ...2],
        [55, 55, 52],
        ...,
        [21, 27, 30],
        [21, 27, 30],
        [21, 27, 30]]], dtype=uint8)
newsize = [360, 640]

    def resizer(pic, newsize):
        newsize = list(map(int, newsize))[::-1]
        shape = pic.shape
        if len(shape)==3:
            newshape = (newsize[0],newsize[1], shape[2] )
        else:
            newshape = (newsize[0],newsize[1])

        pilim = Image.fromarray(pic)
>       resized_pil = pilim.resize(newsize[::-1], Image.ANTIALIAS)
E       AttributeError: module 'PIL.Image' has no attribute 'ANTIALIAS'

/usr/local/lib/python3.10/site-packages/moviepy/video/fx/resize.py:37: AttributeError

there are far more deprecation warnings when I am running my own tests against the features of moviepy that I require.

[EverythingSuckz]

@Kaszanas See #2002

[Kaszanas]

@Kaszanas See #2002

Thank you for this response. I suspect then that opencv-python will be added as a dependency in new release and there will be no further issues with warnings?

[OsaAjani]

This update should in fact fix this bug.

[paulocoutinhox]

+1

[paulocoutinhox]

Support PIL 10 pls to solve the bugs

[t4k]

I see no response to the concern about large media files in the repo. I would like to second those concerns. Including such large files seems like a waste of bandwidth and storage for every person and machine that will use this repo. Links to external videos would probably be fine. I think they should be removed before this PR is accepted.

[OsaAjani]

I see no response to the concern about large media files in the repo. I would like to second those concerns. Including such large files seems like a waste of bandwidth and storage for every person and machine that will use this repo. Links to external videos would probably be fine. I think they should be removed before this PR is accepted.

I do agree it would be best to extract the biggest files from the repo and simply host them somewhere else, maybe just on the web-server used to host the doc.

In fact, there is two different kind of "big files" (comparatively to small text files such as code or doc), the ones used by the tests (mainly anything in /media) and the ones used by the documentation (mainly anything in /docs/_static/medias).

The first type need to stay in the repo somehow (either directly, or with something like git-lfs), because they are used by the unit tests and necessary to ensure there is no regressions.

The second type could totally be hosted anywhere as a simple file to be downloaded. There is almost no point in keeping it in the repository. We just need a place that is cheap as dirt and that we can trust. Git LFS would be quite nice, but it's expensive as f*ck, unless hosting it ourselves, in which case it is lot less expensive but probably a lot more work to maintain.

The resulting trailer should probably be uploaded to YouTube, like @Zulko did for the current documentation, and the documentation updated accordingly. The only reason I didn't do it is that it should be on a trusted channel, not mine.

The big .zip file cannot be uploaded to YouTube though, so we need a way to host this one, maybe some kind of google drive associated to the YouTube channel or something. I leave it for @Zulko to find how he want to do that.

If you can simply tell me where to point the links at I will update the PR to remove the files from the sources and update the doc.

[seven-dev]

It would be cool to move this forward. I'm going to start using it locally to see if I see any problems while using it, maybe eventually I can help maintaining it.

[Kaszanas]

I see no response to the concern about large media files in the repo. I would like to second those concerns. Including such large files seems like a waste of bandwidth and storage for every person and machine that will use this repo. Links to external videos would probably be fine. I think they should be removed before this PR is accepted.

I do agree it would be best to extract the biggest files from the repo and simply host them somewhere else, maybe just on the web-server used to host the doc.

In fact, there is two different kind of "big files" (comparatively to small text files such as code or doc), the ones used by the tests (mainly anything in /media) and the ones used by the documentation (mainly anything in /docs/_static/medias).

The first type need to stay in the repo somehow (either directly, or with something like git-lfs), because they are used by the unit tests and necessary to ensure there is no regressions.

The second type could totally be hosted anywhere as a simple file to be downloaded. There is almost no point in keeping it in the repository. We just need a place that is cheap as dirt and that we can trust. Git LFS would be quite nice, but it's expensive as f*ck, unless hosting it ourselves, in which case it is lot less expensive but probably a lot more work to maintain.

The resulting trailer should probably be uploaded to YouTube, like @Zulko did for the current documentation, and the documentation updated accordingly. The only reason I didn't do it is that it should be on a trusted channel, not mine.

The big .zip file cannot be uploaded to YouTube though, so we need a way to host this one, maybe some kind of google drive associated to the YouTube channel or something. I leave it for @Zulko to find how he want to do that.

If you can simply tell me where to point the links at I will update the PR to remove the files from the sources and update the doc.

I think it is also possible to hold large binary files in a release if uploaded manually. This way you can have a large file download script and check it's expected md5. But that may be breaking other things? I am not sure.

[Paillat-dev]

@OsaAjani Could you please publish a live version of the updated docs? I would appreciate that as I would like to start to test this, so that I can understand the api changes.

[Paillat-dev]

Okay I started using this, and for now it looks very good, I don't see any issues. I will add comments If I find any, but for now it really looks good, and, way better than the master &/ v1. I hope this gets merged at some point, I have high hopes on this.

[mgaitan]

I still don't agree on having this huge media files in the repo. For intance, it will affect CI speed if not taking care of it in during the checkout.

[OsaAjani]

I completely agree with this, but we still need to find a solution to store those large files and allow for management if we need to update them. And I just dont have time to figure it out right now. If someone can offer a nice & simple solution I'll be happy to update the code and remove those files from codebase.