-
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
V2.0 update for code & documentation #2024
base: master
Are you sure you want to change the base?
Conversation
…llow for text clip. Update setup and some test accordingly.
…ile, as its just a tools to create a composite video clip, just like clip_array
…ip.mask is not None, making code coherent
…s. Also add doc to some functions.
…ge dependency, simplifying resize but removing segmenting
…e now simple effects and have been migrated from function to class + fix a missing @DataClass in FadeOut. moviepy.video.compositing.transitions as well as transfx have been removed
…ts as clip method at runtime
…ed to audioclip/videoclip
…clip inside that have masks
No problem, I am quite busy right now, but if you have any question do not hesitate to ping me! |
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. |
Ok, do not hesitate to ping me if you need anything |
Hey @Zulko any news ? |
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: ***@***.***>
|
By any chance does this solve this, Or does this have to be a separate issue?
there are far more deprecation warnings when I am running my own tests against the features of moviepy that I require. |
This update should in fact fix this bug. |
+1 |
Support PIL 10 pls to solve the bugs |
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 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 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. |
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. |
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. |
@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. |
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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I mean can't we use lfs then have it skip lfs in CI?
Co-authored-by: Martín Gaitán <gaitan@gmail.com>
Co-authored-by: Martín Gaitán <gaitan@gmail.com>
I really think that this could help the project regain attraction. This pr is what we need. Have been using it in a prod environment for now more than 4 months and it is a really good improvement. |
tests/
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:
moviepy.editor
and runtime magic such as auto-adding of effects as clip methodspygame
and other tools with onlyffplay
For the documentation:
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.