V2.0 update for code & documentation

OsaAjani commented 11 months ago

[x] I have provided code that clearly demonstrates the bug and that only works correctly when applying this fix
[x] I have added suitable tests demonstrating a fixed bug or new/changed feature to the test suite in tests/
[x] I have properly documented new or changed features in the documentation or in the docstrings
[x] 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 https://github.com/Zulko/moviepy/issues/1874, https://github.com/Zulko/moviepy/issues/2012 and https://github.com/Zulko/moviepy/issues/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 commented 11 months ago

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 :+1:

OsaAjani commented 10 months ago

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

Zulko commented 10 months ago

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 commented 10 months ago

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

OsaAjani commented 9 months ago

Hey @Zulko any news ?

mgaitan commented 9 months ago

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 https://github.com/Zulko/moviepy/pull/2024#issuecomment-1729449893, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAR7EB5JWSL5M5IYXNXTOJTX3QVV7ANCNFSM6AAAAAA3JEOIUA . You are receiving this because you are subscribed to this thread.Message ID: @.***>

Kaszanas commented 9 months ago

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 commented 9 months ago

@Kaszanas See #2002

Kaszanas commented 9 months ago

@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 commented 9 months ago

This update should in fact fix this bug.

paulocoutinhox commented 8 months ago

+1

paulocoutinhox commented 8 months ago

Support PIL 10 pls to solve the bugs

t4k commented 8 months ago

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 commented 8 months ago

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 commented 7 months ago

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 commented 6 months ago

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 commented 4 months ago

@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 commented 4 months ago

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.

Zulko / moviepy

V2.0 update for code & documentation #2024