search

Zulko / moviepy

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

The Future of MoviePy project #1874

Open B3QL opened 1 year ago

B3QL commented 1 year ago

I'm opening the issue in an attempt to provide a platform for discussion on the project's future.

The project is unmaintained and it looks like the original contributors lost interest in it. Currently, few fellows giving their best and taking care of reviewing PRs and fixing the issues related to their projects but it's not enough to keep the project healthy. The library is obsolete to the point that 3rd party open source software that depends on it is having problems with being included in the next Debian release.

If we want to save the project we need to build a community around it and/or seek some financial help from OSS foundations.

Nevertheless, we need YOUR help. If you have an idea of how to help the MoviePy project survive, please contribute in the comment.

davidbernat commented 1 year ago

I second this nomination. Very important. Few to no alternatives.

AndersonBY commented 1 year ago

Support! I used to teach some lessons about how to use moviepy to automate the work of video making. Clearly people are interested in this since we are flooded by short videos today and Python is the easiest way many people can learn to automate video processing.

I think one problem now is that moviepy itself is good but the community and other projects that build on it is not famous enough. Therefore not much sponsor would be interested in moviepy.

My rough thoughts about the future of this project:

  1. Make a systematic series of teaching videos and promote so more people can know how to use it.
  2. Maybe build a saas platform that use moviepy with paid features and feed back the project? I can see many successful open source projects are running like this. This can be the self-sufficent way to run this project.
  3. Moviepy itself is just a tool. A tool itself usually is hard to have the wide spread ability. So use moviepy to build some projects which have a more wide spread ability. Topics like AI generated, trolling for content.

Just some random thoughs. Looking forward to your comments.

B3QL commented 1 year ago

Support! I used to teach some lessons about how to use moviepy to automate the work of video making. Clearly people are interested in this since we are flooded by short videos today and Python is the easiest way many people can learn to automate video processing.

Great to hear that, no doubt that moviepy is a great choice for automating video processing, however, it looks like not many hobbyists contributing back to the project.

I think one problem now is that moviepy itself is good but the community and other projects that build on it is not famous enough. Therefore not much sponsor would be interested in moviepy.

My rough thoughts about the future of this project:

1. Make a systematic series of teaching videos and promote so more people can know how to use it.

IMHO the usage of the project is not a problem per se, it's more about how to convert more users to contributors.

2. Maybe build a saas platform that use moviepy with paid features and feed back the project? I can see many successful open source projects are running like this. This can be the self-sufficent way to run this project.

That is an interesting idea but I don't see a clear way how to monetize the project eg. what are the "premium" features?

3. Moviepy itself is just a tool. A tool itself usually is hard to have the wide spread ability. So use moviepy to build some projects  which have a more wide spread ability. Topics like AI generated, trolling for content.

At the current state of the project and its trajectory, I think that people should not build upon an unmaintained library to avoid problems such as https://github.com/Zulko/moviepy/issues/1798#issuecomment-1335912055

AndersonBY commented 1 year ago

@B3QL Came across this project Remotion. Kind of similar to moviepy but more active. It offers a membership subscription. image

As for moviepy, I think cloud rendering and effects templates can be the premium features.

When using moviepy to do some automated editing, I need to spend a lot of times to get the correct effects. Would be great if there is a "template market" to preview and get some effects template code.

tburrows13 commented 1 year ago

Hey, just checking in to say that I’m reading this discussion :) In the past I’ve found that when one or two enthusiastic people get involved in a project, that really helps me rejuvenate interest in it as well.

B3QL commented 1 year ago

@AndersonBY thanks for the inspiration :)

@tburrows13 thanks for all your contributions so far and the will to participate further with additional help. Maybe you have any idea how to organize/improve collaboration to get the project back on track?

komjum6 commented 1 year ago

Maybe it needs an overhaul like from TKinter to Kivy

korantu commented 1 year ago

Is there a specific next step wanna-be contributor with a bit of python experience could have a look at? To add momentum?

xonoma commented 1 year ago

The one thing that's really held MoviePy back IMHO is the documentation.

When I first started I had to go everywhere to look for basic MoviePy-related tutorials and steps. Not everyone's as motivated; a centralized documentation would create interest in users, and help to retain them.

B3QL commented 1 year ago

Is there a specific next step wanna-be contributor with a bit of python experience could have a look at? To add momentum?

@korantu AFAIK there are no extra steps to contribute, just familiarize yourself with https://github.com/Zulko/moviepy/blob/master/CONTRIBUTING.md and that's it :)

I don't know for sure what is the most urgent problem to work on but I try to sort it out and bring some more clarity. For now, I believe that the most benefit we can get from finishing https://github.com/Zulko/moviepy/issues/1089 and releasing 2.0

@tburrows13 correct me if I'm wrong here :point_up: @keikoro maybe you can help me with the priorities?

The one thing that's really held MoviePy back IMHO is the documentation.

@xonoma the documentation looks decent to me. Do you miss something in particular or have an idea how to improve further? Feel free to give it a shot!

Zulko commented 1 year ago

Hi all! Very sorry for this situation. I've been spread thin for years now, and MoviePy has only been held together thanks to the efforts of @keikoro @tomburrows @mondeja and others. Here are my two cents:

Regarding @AndersonBY's comments: I agree that we could have more docs and "official" collections of plugins and effects. But these require a significant time investment, and could also be developed by users independently. Anyone can write a tutorial, release a library of moviepy filters/utilities on Github or PyPI, or build a web service around MoviePy - and a few have. So I would classify that as important, but not blocked by this repo.

The more problematic bottleneck is developer time on this repo (features, installation, test suite). Few users have contributed back to these areas, and occasionally when some attempted to contribute they were left hanging by lack of available reviewers.

I agree that releasing @tomburrows's 2.0 version would be the best move - and the most significant project improvement in years. It would resolve some of the confusion caused by the current API, and so should reduce the number of issues. It would also put the project in phase with its README (which is using the 2.0 API now). Realistically, going to 2.0 would also mean quickly dropping support from pre-2.0 MoviePy, as supporting two APIs would spread developer time even thinner. A bit of an unpopular opinion but a new API also means a smaller userbase, which could make mistakes more forgiving, and MR review less stressfull.

The 2.0 release in itself may not solve a harder problem the project is facing, which is managing dependencies like ffmpeg or ImageMagick, and their subtle differences between versions and OSes causing a lot of our open issues. These are generally difficult and joyless to solve, as they require setting up a specific environment to troubleshoot the issue, and because preventing regressions accross many OSes and several ffmpeg versions requires a large test suite tht could slow down some operations. For a long time, MoviePy was piggybacking on imageio (and its integrated ffmpeg installer) so that that most of the ffmpeg features and issues (such as the one now affecting the Debian release) were ultimately solved on the imageio side. But even coordinating with imageio takes time and we can't expect them to solve all our problems (meaning, even if the fix is pushed on the imageio side, someone has to do the work).

Summarizing:

Did that make sense? Did I miss anything?

tburrows13 commented 1 year ago

Just a quick note to say that part of the plan for 2.0 was to not need ImageMagick at all. I think currently it is only used for making GIFs and drawing text. IIRC there are 3 options currently for making GIFs so losing IM would be fine there. There were a couple of explorations for alternatives for text drawing which looked promising, but I think that was one of the main outstanding tasks to complete before 2.0.

B3QL commented 1 year ago

@Zulko thanks for the in-depth insights, it's great to hear back from you! @tburrows13 thanks for clarification with the ImageMagick

We'd need a small team (could be 2 people so there's at least one main dev and one reviewer) for the last push on 2.0.

@tburrows13 would you take responsibility for the coordination of the 2.0 release with the help of current contributors? @korantu are you still willing to help with the release?

We'd need a very involved developer to fix the binary management problem, ideally by having moviepy come with reliable ffmpeg/Imagemagick versions when pip-installed, and/or by expanding tests for different OSes (this might already be largely in place) and ffmpeg releases. Not sure how we'd find that person - could be either someone who really needs it fixed, or looking for a student project. In that last case we'd still need someone from the project available to provide context and reviews.

IMHO the simplest way would be to make the ffmpeg a static dependency and ship it along and support one version at a time, but I may not be aware of all the potential consequences. For now, would be great if we can manage to make some decisions and based on that create smaller tasks for implementation.

We'd need more core developers to review and merge the regular MRs, Issues, improve docs, etc. I believe making an announcement in various places (e.g. Reddit) might help. Again we'd need to make sure there is bandwidth to welcome new devs.

I announced it on Reddit [0][1] & HN [3][4] already, but we can repeat it from time to time. [0] https://www.reddit.com/r/coolgithubprojects/comments/zin6na/the_future_of_moviepy_project/ [1] https://www.reddit.com/r/moviepy/comments/zin2ez/the_future_of_moviepy_project/ [3] https://news.ycombinator.com/item?id=33864865 [4] https://news.ycombinator.com/item?id=33953142

keikoro commented 1 year ago

Hi, thanks for starting this issue! I just wanted to comment that I (too) have been reading along but haven't yet had the time/energy to add to the discussion (or get my thoughts on this in order in the first place, ha).

keikoro commented 1 year ago

(A bunch of which revolve around communication/project management, a point which hasn't been raised yet.)

B3QL commented 1 year ago

(A bunch of which revolve around communication/project management, a point which hasn't been raised yet.)

I believe that that is the main pain point here, so that's why I decided to open the issue and try to coordinate ongoing efforts. I would love to hear your thought about it and the potential ideas, on how to arrange some kind of structure for the future.

BTW can we pin the issue for better visibility?

rolandmas commented 1 year ago

Hi all, I'm the maintainer of the Debian package of moviepy, which is currently not on track to be included in the upcoming Debian 12 "bookworm". I just wanted to mention in this discussion that I'll be glad to provide any help I can related to packaging or testing with Debian. Feel free to poke me either here or on https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004642 :-)

B3QL commented 1 year ago

Hi everyone in 2023! @korantu have you had a chance to contribute so far? @tburrows13 is the 2.0 release on track? Do you need help with it?

korantu commented 1 year ago

I did not get to try my idea yet 😒.

ShakedDovrat commented 1 year ago

What is the status on multi-core CPU processing AND/OR GPU processing? Is anyone working on it? I want to contribute.

B3QL commented 1 year ago

Hey @ShakedDovrat, it's great to hear that :) AFAIK all of the potential acceleration should be available on the FFMPEG level, but in order to unleash it we need to resolve 2 issues:

I know that it might not be the thing that you looking for but I'll be helpful if you give it a try :)

Btw @keikoro you seem to be one of the most active contributors around here. Can you help me with creating the proper structure for the project to enable more people?

ShakedDovrat commented 1 year ago

Thanks @B3QL. I must say that what you are describing is far from my field of expertise. But I see why this might be the most efficient approach.

I was thinking about something easier, which is to separate frames processing/rendering from the video writing, which will enable usage of Python's multiprocessing on each frame (i.e. call get_frame concurrently), while still writing the video frames to file serially. This by itself should accelerate the processing a few times fold, from my understanding. It will not require any change to the relationship between moviepy and ffmpeg.

Given that "a very involved developer" is hard to find for the kind of work @Zulko is talking about, Do you think a change such as what I propose can be accepted?

B3QL commented 1 year ago

@ShakedDovrat unfortunately in the current situation there is no guarantee that the proposed feature will make it to the master. I don't know for sure but it might be problematic due to ongoing work in API 2.0 https://github.com/Zulko/moviepy/issues/1089

IMHO you can open a separate issue for the acceleration, describe the approach, and ask for feedback :)

B3QL commented 1 year ago

Hi all, since I failed with constructing the team and oversee the project the momentum is lost.

I opened the PR to let know the broader audience about the project's state, please review it. https://github.com/Zulko/moviepy/pull/1998

Thanks for all the contributions to the project and overall support so far.

davidbernat commented 1 year ago

Let me throw a wild pitch into this mix, @B3QL. My experience using MoviePy for one year is that there is something fundamentally lacking in its design, despite being invaluable to the Python language and open source. It does not compete with heavier editing tools (some of which may have open source APIs) nor does it compete with heavier production or render tools (an API into Blender can do a lot, for instance). And the opening and closing and clipping and cropping of movie files would be a far more constrained, though truly essential, smaller package, which MoviePy does not want to be. If I were to "take over" the construction (team) of "Movies in Python 2024", I would argue, and organize the team around (our) committee, to first-and-foremost refactor MoviePy to be "native Cloud Function" in design, and operate a pay-for service (via my LLC, or our open source) to execute those services in the cloud IaaS environment. I believe we would all see the growth and sustenance of such a model (and microservices architecture) (think RedHat Linux model) and the natural "room to grow" "Movies in Python 2024" into AI and APIs outbound. I would be delighted to "man" that team were the commitment small (a few hours per month) and objectives slow and time bound by external factors determined by (our) "construction team". What do we think? Form a quorum? 🙋‍♂️⭐

My LLC is Starlight, by the way. You are all welcome to email me in my email address provided in my GitHub bio.

OsaAjani commented 1 year ago

Hi, this project IS useful to many and there is no clear alternative, that actually quite a rare combination, and it would be a shame to let it sink...

I'm not sure if I can help much on the dev side, but as someone who just started to use moviepy, I may offer a fresh eye on what seems to be, in my opinion, the main problems right know for a new user, wich could explain the difficulty to find maintainers.

For me the most important problem, by far, is the lack of clarity about the v2 question. As a new comer, it is absolutely unclear what version I should use, what bugs will or will not be presents depending of the used version.

Surprisingly enough, the version of ffmpeg have not really been any trouble. The version shipped is obsolete, ok, but at the end of the day the invocation of ffmpeg is done through a command line. I can just edit the source of moviepy, point to my local binary, and it should work ok, if i need additional params, I use ffmpeg_params and it works.

The documentation probably lack in examples, etc. But it is actually not so bad, like I have found what I needed, the public API is documented enough that I know at least the direction to look into for 95% of what I want to do. For the 5% of advanced stuff, let's focus on thoses when things will be more stable.

The GPU rendering or at least the CPU parallelization seems to be for me the second most important limitation. We NEED this. Even fairly beginning users may figure out a way to achieved what they want if some function is slightly buggy, they can always use the basic approch of "everything's an image, let use pillow to craft what I need and add it as an ImageClip" and figure theire way out. What they cannot do is find a way to tweak moviepy to allow multithreading, etc., so they can render clips fast enough.

Encoding speed is the real deal breaker. Everybody is fine with writting a few strange line, add a comment saying "this is some bug fix, see issue XXXX", what peoples are not fine with is having no way to generate videos quickly, no matter how big an AWS EC2 instance they may through money at.

Now, as the main developper/maintainer of an open source project myself, I do understand the lack of ressources both in terms of human time and technical competences a project can be strained by. And I also understand the importance of support, stability, predictibility in a project for the end users.

Thoses things in mind, if I had to come up with an action plan for the immediate future of moviepy in order to put the project back on track, here's what it would be :

1 - Merge v2.0 to main right now or delete it

It is my understanding that an updated, more coherent, somehow stable v2.0 have been developped for years now.

If this version is okay and working correctly for thoses who haved used it, we must merge it right now, the more we wait, the more difficult it will be.

It is my understanding that @tburrows13 is the man behind the wheel for v2.0. We should ask him. If he think the current 2.0 is working ok, even if there is evolutions he have not been able to include in yet, then we should ship it immediately as the new main.

If we ship v2.0 we should probably consider closing the old issues regarding v1.0.3, with a message for the original authors saying to try reproduce the issue with the new v2.0 main, and re-open if the problem persists.

If he think the v2.0 is somehow a dead end (maybe it had diverged too much from main and is irremediably out of sync, or any other reason), then we must delete it right now and close all open uses linked to it.

The rationnal behind this is :

For the rest of the action plan I will consider that we ship v2.0 as the new main

2 - Update the documentation to be in sync with v2.0

Once v2.0 is the new main, the first thing to do is to re-generate the old v1.0.3 doc to be in sync with v2.0, we should not even try to make it more complete or better than the actual one, just as complete, and with a chapter on how to update from 1.0.3 to 2.0.

The rationnal beeing that :

3 - Add CPU parallelization

As soon as the basic v2.0 is published and doc updated, next priority should be to add CPU parallelization and/or GPU rendering to moviepy (ffmpeg can already do threads, and probably GPU rendering if the ffmpeg binary and hardware support it, so the bottleneck must be in moviepy, probably in make_frame from what I've read in the existing issues).

The rationnal :

4 - Reduce the support surface

As previously stated, we lack human resources, so we should limit the surface by making our objectives resonnable and dropping support of all the things we resonnably can and clearrly state on the front page what environment we support.

Mainly, I would propose :

The rationnal :

5 - Make things evolve

Once all of this is done, we will then be able to make things evolve, add new features, fix bugs, improve the documentation and add examples.

More than anything else, by defining a new basepoint, we will make clear for potential contributors where they can start to work on.

Don't get me wrong, I know that all of this is work, and that any of those points have his drawbacks, but if I wose to propose a course of actions, this would be it. I hope the reflexion can help.

And again, big thanks to all the peoples that invest time and energy in this project.

davidbernat commented 1 year ago

Hello @OsaAjani and @B3QL: I agree broadly with these recommendations. Yes, v2.0 should be integrated or deprecated; and documentation needs to be made complete. I personally and very interested in tracking the updates of the performance issues; and, even within the chaining of operations there are clear efficiencies that can be mastered natively integrated into the code by someone who knows the system down three levels of abstraction. That said, I believe to manage this project, a "vision" statement needs to be included at the top-down community organization (i.e., microservices IaaS) and a timeline needs to be set (i.e., slow, but persistent; end-of-2024 goals) and a community quorum of at least several individuals need to "man" the management. Even the formulation of this document, in my opinion, should move outside of the GitHub ticket system, and be met with an organization of management process. I.e., sure, within the next six months I would be thrilled to commit to managing the GPU/CPU parallelization and thinking through the chaining together of operations for performance issues (of which there are low hanging fruit). Another "squad" could focus on bug-fixes; another "squad" still could focus on v2.0 integration and documentation. Two representatives of each squad; and a voting system to drive changes of priority. In the process of six months I could follow-along with participants to manage the "Movies in Python 2024" program description, and then execute this throughout a year. This also prepares us time for grassroots and targeted direction of resources (as an essential package we can acquire sponsorship; in my previous post I spoke up licensing and monetization through my LLC, etc.) This is manageable in a way that group glomming onto an asynchronous ticket will alternatively fizzle, and we clearly have enough individualized interest to manage this process forward ahead. Is there a process by which we even want to enable voting on a motion (such as this one)? Form a quorum? 🙋‍♂️⭐

OsaAjani commented 1 year ago

I was taking a more in depth look at the current main, and I think that it is actually already based on the v2.0.0.dev2 release, which was not my understanding until up now. Am I missing something ?

davidbernat commented 1 year ago

That was my understanding; though the documentation is not up to date, and the operations are not consistently v2.0.0 implemented. My understanding is also that no consistent interface standards are applied throughout v2.0 still; i.e., the code is not consistently intuitive, and still needs an architecture redesign and refactoring. I also notice the current state of the code is quite buggy; in recent months my number of kludge functions has grown, i.e., concat issues, sub-clip/clip non-homomorphism, the metadata/orientation problems. And, yes, the encoding speed is slow, and worse in practice. It is not uncommon to have a high level flow that encodes, concats, encodes the concatenation, which results in re-encoding the same sub-clips due to anything from a pixel clip to frame rate change to mystery reason. Lots of 2x, 3x, etc. inefficiencies, at the interface layer above the raw compute of encoding. Hence furthering my drive for a true organized maintenance structure. To be honest, I do not want to use a code package that will simply be pull requests here and there.

OsaAjani commented 1 year ago

Well, if main is already based on v2.0.0.dev2, then I guess the next course of action should be to release and clean :

  1. Do a release of main as v2.0 and put it out there on pipy, pipy is the front door for 99% of peoples, we need it to point to the last version if we don't want to be overwhelmed under old issues already fixed.
  2. Update the documentation to reflect the state of the new v2.0
  3. Close all issues with a message asking the authors to try reproduce with latest release and re-open if the problem persists, same for PR.
  4. Remove all dead branches. We should probably only have one, maybe two branches, main reflecting the latest version for the public usage, and dev for the devs to work on features to be included in next version, with only finalized features/modification in it.
  5. Start working on parallelization and bug fixes for the issues that have been re-open (bug fixes is typically a case small commit by commit by anyone who wants thing, parallelization is probably more of a one man job taking a deep dive into it).

Once this point will be reached, we will have at least reached a point where the project is "working and up to date".

Harmonization of the inner workings, more in-depth optimization, improvement and organization of the project governance, etc. can be discussed at that point.

To me all those points can take place once the project is in a well defined state, as many bug fixes and improvement can probably be coded along the path by individual users without much coordination between them if we just have even few maintainers whose role is not much more than review, check nothing outrageously bad is added, and merge.

To me the governance seems like a question that should take place after a first big spring-cleaning of the project, that only the current admins can do (i guess ultimately the call is @Zulko's). All we can help with until step 5 is updating the documentation.

At the end of the day, moviepy does not need to be a rapidly evolving project at the cutting edge of the technology. It just need to be a well defined tool to do non linear video editing, with a clear way to assemble resources, and a clear explanation on how to create a new special effect if it does not already exists. As well as a project where bug fixes will be applied. The project is used by developers, not end users, and I trust that developers will fix the bugs and PR if they can.

To me, the project is actually almost there... It just need some spring-cleaning so people will understand where things stand and how to help.

davidbernat commented 1 year ago

Much of that makes logically progressive sense, @OsaAjani, though I fear it lacks the sort of vision that does not ultimately put the project back in the same one-man-on-the-switch lingering that the project has undergone for the last several year(s), and I already understand there is a huge opportunity here beyond the maintaining of this software, and my LLC is probably pushing itself to do some of these IaaS changes, as they are already on our roadmap (and were until, as we discussed, the moviepy project became less stable). So, I would be interested in leading that direction of the project, and putting together a slightly formal steering committee that keeps my LLC work tightly integrated to the moviepy devs and updates, and the open source. I know you want to keep the management of v2.0.0 to a minimum, but I feel gauze over my eyes. For instance, I do not even know who is on this list. Who has worked on open source before; managing, or managing lead/independent dev rolls. Even a simple spreadsheet with identifications, roles, talents, and contact information may, in my opinion, go a long, long way to making the operation robust, and, ultimately, more sticky to completion and maintenance.

OsaAjani commented 1 year ago

Well, I do agree that the project will ultimately greatly benefice from having a more structured management board, with a list of well defined maintainer and more than one man able to validate the decisions. But the fact is, right now the current maintainers seems quite tired of it (which I totally get and is totally fine, everybody have lives and other things to do). And in order to attract more people, we need a more clear state for the project.

If that can help you, from what I've grabbed : @Zulko is the original author and probably the guy that know moviepy best, but he only marginally participate since mid 2019. @tburrows13 is the number 2 guy in terms of commit, and I guess inner workings of moviepy since he is behind v2.0.0.dev1/2. His last major work was around 2020-2021 @mondeja seems to have done quite a lot of work on testing and adding support for automation to the repo with work as recent as 2022. @mgaitan seems to be the more recent significant contributor to the project with work merged last month.

And of course @B3QL even also seems to have interest on the project.

I guess thoses 5 peoples would be the first to ping and try to contact.

Also, at least @keikoro, @tburrows, @mgaitan are collaborator on the project, meaning they have at least some sort of rights on the repo to do admin tasks.

(Sorry for all the ping mail you will probably get guys ;))

OsaAjani commented 1 year ago

For general information, as of yesterday I've been starting to work on the documentation to try update it to match the current state of main branch, based on current doc, and the version from https://moviepy-tburrows13.readthedocs.io.

My goal for the doc is to have a clear and up to date "Getting started" part and a few example for basic usages, so new users understand the basics concepts of moviepy, then anything more complex can be figure-out reading the "API Reference".

In order to make starting moviepy as simple and straight-forward as possible for new users, as well as to reduce the surface for maintenance as previously stated in my previous comment, I will also modify a few things in the main branch of moviepy, essentially by promoting most of optional dependencies (pygame, opencv, etc.) as required dependencies.

Thoses modifications are motived by the fact that, in my opinion, both installing, supporting, maintaining and developing moviepy will be far easier if everything shipped with moviepy (mainly effects) works from the base install, and currently many even basic effects depends on having at least one of those lib.

To be clear, I am not shooting for "best", "minimalistic", "modular", "multiplatform" or anything like that. I am shooting for simple reproducible one truth reference point, because I feel like this is all we can afford to maintain and that it is what is in the best interest of the project right now.

My plan is to try finalize in one or two week an up to date version, with a matching documentation, targeting one and only one environment to be released as a v2.0. Once I've reached a finalized version, I will submit it as PR, leaving up to current maintainers to accept or reject it.

If I can I will try to include pending PR that seems relevant, but I guarantee nothing.

davidbernat commented 1 year ago

Thank you for that update. Regarding Steering, is this document too much to ask for at this time? I will allow anyone who comes to this Ticket ping one of us on this document to add themselves. I do not want to add anyone without their request. For your work on v2.0, I would like to contribute an hour or two per week, but I will need to understand what pacing is going to look like so I can plan. I began writing out my plans for Cloud and Product last night on the basis of an application my LLC is building that brought me into the MoviePy ecosystem to begin with.

As for your recommended changes, I must make an opposition. I think we must separate out the essentials from the dependencies. It is irresponsible for MoviePy, which is fundamentally a wrapper to ffmpeg, to require dependencies on OpenCV, PyGame, etc. (It is absolutely understandable in the context of your desire to implement v2.0 and document as quickly as possible in the current circumstances, of course.) Fundamentally, MoviePy is a video loader system first and foremost (MoviePy Essential) and a series of video editing utilities are built around that (MoviePy Editor), of which those dependencies for PyGame, or OpenCV, etc come into play. A canonical example I use is the Ken Burns Pan & Zoom, which is absurdly unintuitive to implement in ffmpeg because of weird dynamic coordinate systems, but should be one line of intuitive software at the level of MoviePy Editor features (i.e., it is on the same level as adding a TextOverlay or Text Scrolling).

That said, we are limited to implementing changes to the Documentation at this time, is that correct? If that is the case, then is my understanding correct that what you really want is to "use the documentation as our organization" etc etc etc...?

https://docs.google.com/spreadsheets/d/1FftaQDTjZi8pMmeLQthY4BNpaKMLB2TDssUnuQZBJQI/edit?usp=sharing

OsaAjani commented 1 year ago

Well, I agree some sort of list of people working on the project on a regular basis and with some sort of power over the project would be something useful, but I really cannot do anything on that front as I am not one of this person, and I have no more way to contact them than you do.

To me one of the first and most easy way to have some kind of view on who works regularly on the project would be to create a GitHub organization for it, I think this would also be the logical step for any sort of future governance of the project.

Concerning the passage of extras to required, I do agree some of those library are probably not justified, but their are, in current state, required for many if not all effects manipulation.

On the other hand, I would disagree with the ideas that "MoviePy is fundamentally a wrapper to ffmpeg" or that "Fundamentally, MoviePy is a video loader system first and foremost". Conversly, I would say MoviePy is fundamentally a module dedicated to video editing with the idea to offer abstraction, readability, editing tools and some sort of framework to writing new effects.

Of course I can be wrong, but I want to say that I do not simply think so based on my own experience, but I also base my interpretation on various passages of the current documentation, among those :

On the home page of the documentation

MoviePy is a Python module for video editing, which can be used for basic operations (like cuts, concatenations, title insertions), video compositing (a.k.a. non-linear editing), video processing, or to create advanced effects.

On the quick presentation page, their is use cases for which we should and should not use MoviePy, all of the pros refer to video editing and effects of some sort, while the cons refer to :

You only need frame-by-frame video analysis You only want to convert a video file, or turn a series of image files into a movie. In this case it is better to directly call ffmpeg (or avconv or mencoder…)

I would (this time personally) argue that like for video file converting, if one just want to load a video, to do something else than non linear editing, one should probably use something like OpenCV instead or some ffmpeg wrapper.

Another thing that let me think that editing in at least some basic form (like resizing, text editing, image support, all of which currently requires some sort of image lib, either imagemagick, pil or opencv) is a core part of MoviePy is the fact that with v2.0.0.devX, the notion of moviepy.editor tend to disappear, like indicated in the doc https://moviepy-tburrows13.readthedocs.io/en/improve-docs/getting_started/efficient_moviepy.html#should-i-use-moviepy-editor.

And also in Updating to v2.0 :

It is generally no longer necessary to import from moviepy.editor. It will still work, but moviepy.editor should now only be loaded if you are using MoviePy to edit videos by hand.

But more than any philosophical questions, at the end of the day there is only two core reasons behind my choice of moving extras into required :

In the future it may be a good idea (though I'm not sure it is) to target a more "modular" structure by extracting all effects into another project or sub-module that would then be installable with extras. But we can always do that later once more structured.

Right now, we need a base version with as little unknown and variations as possible to be used as consensus.

Concerning your last question :

That said, we are limited to implementing changes to the Documentation at this time, is that correct? If that is the case, then is my understanding correct that what you really want is to "use the documentation as our organization" etc etc etc...?

I think most of the structural work on the organization of the project is for now out of our hands. What we can do is :

Your understanding is not correct, I do not wish to use the documentation as our organization.

Current state is, the project is slowly dying. My personal analyze of the situation is that it's due to multiple factors : a lack of manpower ; an unclear state of the project with diverging public release/doc and internal state of the project ; a lack of one true path, do to support of many backend tools and environment, leading to many variations, leading to testing, support, debugging and coding too complicated and heavy compared to available manpower and maturity of the project.

Again I might be wrong on the entire line, but that's where I have to build from.

I cannot do much more about the manpower, and I am not in position to do anything about management (not an admin position, not any kind of legitimacy, and I actually have personally not any interest for it).

What I can do though is invest some of my time to :

The rest will be up to the maintainer. They take it, they leave it, either way I can't do nothing about it.

I will not have the time to work on this in the future, I can give one to two weeks of time right now, and I think the project is worth it, so I will do that, and only that.

davidbernat commented 1 year ago

To me one of the first and most easy way to have some kind of view on who works regularly on the project would be to create a GitHub organization for it, I think this would also be the logical step for any sort of future governance of the project.

I agree. I also agree to move this conversation off-line to email for the time being, until the Maintainers, and other parties, contact us. If you are committed to making changes in the coming weeks, please continue to actively cc me on your tickets, and also, when the time is right, I will create an organization and add you to that conversation. We should give others, and the Maintainers, especially, more time to contribute their needs and intentions, and to ping me about the Spreadsheet above.

Concerning the passage of extras to required, I do agree some of those library are probably not justified, but their are, in current state, required for many if not all effects manipulation.

On the other hand, I would disagree with the ideas that "MoviePy is fundamentally a wrapper to ffmpeg" or that "Fundamentally, MoviePy is a video loader system first and foremost". Conversly, I would say MoviePy is fundamentally a module dedicated to video editing with the idea to offer abstraction, readability, editing tools and some sort of framework to writing new effects.

Hmm. I do agree; however, as we are resource limited, the essentials are the essentials. The editor functions, truthfully, suffer from a lack of congruence, and completeness. In a dream world, in which Essentials were stable, and a Steering Committee existed (i.e., that Spreadsheet), the Community itself would contribute features for Editing in a composable fashion. A great example is the Ken Burns pan & zoom; or Text Scrolling features, which are intended as Editing features.

I would (this time personally) argue that like for video file converting, if one just want to load a video, to do something else than non linear editing, one should probably use something like OpenCV instead or some ffmpeg wrapper.

Another thing that let me think that editing in at least some basic form (like resizing, text editing, image support, all of which currently requires some sort of image lib, either imagemagick, pil or opencv) is a core part of MoviePy is the fact that with v2.0.0.devX, the notion of moviepy.editor tend to disappear, like indicated in the doc https://moviepy-tburrows13.readthedocs.io/en/improve-docs/getting_started/efficient_moviepy.html#should-i-use-moviepy-editor.

Everything you say above I would categorize as Essentials. Manipulating, Splicing, Constituting, changes of speed and format, etc. Image Stills to Clips; etc. Text Overlays are simple enough as well. PIL is sufficient and low-level Python.

In the spirit of MoviePy, I see the Maintainers did what one would naturally do: built a number of Essential tools, then demonstrated that cool editing composites (like swirling text, and so forth) can be built on top of that. Though, that, in my opinion, ultimately complicated the maintenance of the package. That is all. I would estimate 80 to 90% of the project is Essential. I notice, however, that growing changes to the underlying code, and not keeping up with some systems engineering, has caused the Essentials to have pockets of clear improvement available to it, which are most Essential.

Think like Numpy. If you need to manipulate matrices; thank goodness it exists. The second you get to more advanced needs, you probably have other package alternatives in mind (i.e,. SKlearn, ScipyTools; or, Mathematica, etc). In a strict world, MoviePy Essentials exists to handle file data management properties in bulk; i.e., backend serving and loading of different constraints, not for Editing i.e, Creator, because Creators have numerous splashier non-API driven tools. (Really, composing sophisticated looking videos in MoviePy is already hard; and, offloading to open source tools like Blender that have APIs in Python quickly become more valuable time. Notice that the likelihood of Creator Composition in Blender in Bulk is far rarer than, say; I have a machine learning problem to solve except I need to crop out these text annotations at the top, split off the first five seconds of introduction, search the frames for black screens or white noise; and, why I am at it, I should do data augmentation tricks like rotating, color balancing, adding in overlay images, and so on and so forth. Those benchmark for me a handy definition of "low level Essential movies in Python" and also a "need for speed", "need for lightweight dependencies in the backend", and "need for guaranteed maintenance". Hence, I am committing LLC to this project. At this point this is a conversation we should move off-line to email in a separate thread than the one we started.

And also in Updating to v2.0 :

It is generally no longer necessary to import from moviepy.editor. It will still work, but moviepy.editor should now only be loaded if you are using MoviePy to edit videos by hand.

But more than any philosophical questions, at the end of the day there is only two core reasons behind my choice of moving extras into required :

  • For now, we need them for even the most basic usage, like adding a textclip, or resizing an image or a clip. People will need theme in almost any realistic use case. Not including them will lead to many bug and misunderstoods for new users and useless issues. We do not have the man power to filter through thoses, nor to test and support for the multiple variations introduced by supporting so many optional backends.
  • Not including them mean that we always need an awful lot of boilerplate to do even simple tasks in order to know which tool to use, and to fail somehow gracefully (look at https://github.com/Zulko/moviepy/blob/master/moviepy/video/fx/resize.py). Maintaining, writing and supporting 3 times the code is, again, too time consuming for the state of the project.

Theme is helpful. I have not done a deep dive to the code. I notice bugs like Concatenating a bag of Subclips and Clips fails to transfer attributes; and, similar, and have a stack of kludge to solve this. These fixes should boil up through streamlining to improvements like themes naturally, I imagine.

I think most of the structural work on the organization of the project is for now out of our hands. What we can do is :

  • Make documentation a little more clear and as up to date as possible
  • Fix any immediate and simple inconsistencies in the api we come across while doing so
  • Define a standardized target environment and test against it

If you want to task me with one to two hours a week of issue tasks, please create tickets and assign them to me. Especially, if what you want is me to update a subsection of documentation and create code PRs as I identify bugs or inconsistencies.

Current state is, the project is slowly dying. My personal analyze of the situation is that it's due to multiple factors : a lack of manpower ; an unclear state of the project with diverging public release/doc and internal state of the project ; a lack of one true path, do to support of many backend tools and environment, leading to many variations, leading to testing, support, debugging and coding too complicated and heavy compared to available manpower and maturity of the project.

Sad Emoji. I hope that I can contribute a True Path via the Spreadsheet and my LLC. The underlying Essentials ought to be very stable once we find a way to introduce a stable version. ffmpeg is not likely to change substantially for many, many years. Once we nail the basic memory management and efficiency of clips/subclips in basic operations like clipping leading into composition, the solution ought to be stable for many, many, many years. Ditching everything but Essentials should take no more than one hundred to three hundred hours by one moderately expert IC, and probably double that if we support a small team. To me that sounds like muscle for 365 days, or comfortably to the end of 2024. The request for more than one or two hours a week from an individual is unrealistic at this stage unless there is a commercialization angle, which, off-line I have already begun. But getting five people to contribute eye-balls to threads as active lookie-loos, and three people to contribute one to two hours a week as somebody-got-to-do-it I think is the winning proposition. See where I am coming from?

I will continue to add this notice at the end of my posts and I invite you to do the same. People interested in participating or simply curious should email the point of contacts in this spreadsheet. https://docs.google.com/spreadsheets/d/1FftaQDTjZi8pMmeLQthY4BNpaKMLB2TDssUnuQZBJQI/edit?usp=sharing

B3QL commented 1 year ago

@OsaAjani and @davidbernat thanks for the input on the discussion and ongoing coordination effort.

From my perspective, it's more about a lack of communication and general interest in the project. Long waiting time from PR to merge (not mentioning to release) and the need to constantly push to make it through. Until that will be solved any proposed technical solution like focusing on v2/docs/etc won't make any difference in the long run.

IMHO the bottleneck on the organization's side is the right to publish the PyPI package and the right to empower new contributors. That power is held by @Zulko and @tburrows13 so either they will need to donate more focus toward the project to enable more developers or the project along with PyPI stuff should be transferred out.

Assuming that @Zulko will agree to do that I see 2 potential places:

In case we won't be able to reach him the only way to go would be to fork, change the project name (for PyPI), and point ppl to the "new" project.

Nevertheless, I would like to merge https://github.com/Zulko/moviepy/pull/1998 and keep it until we find some solution.

ShakedDovrat commented 1 year ago

I want you to know that MoviePy is very important to me. It is used in my product intensly and enables me to create very cool videos automatically. I would hate to see it sink! I agree with what @OsaAjani, @davidbernat and @B3QL wrote. I hope you can take contol of this ship and guide it to calm waters. I also hope I can contribute modestly, especially in the much needed parallelisation & optimization realms. Thank you for caring and contributing, and good luck.

davidbernat commented 1 year ago

I am not one for metaphors at this moment though I do agree that the industry needs a low-level, high-functionality wrapper to ffmpeg in Python for the benefit of the AI/ML communities and also defense industry partners, both of which I am knowledgable for, and which are the driving purpose behind my LLC on this matter. I have begun writing up organization (steering) and functional (performance) documentation from within my LLC that will guide later control initiatives with this community. I also intend to develop what will be necessary to inter-relate this system with Blender (as a state-of-the-art open source render API) and AI technologies from the ongoing field, without sacrificing the low-level expectations of ffmpeg and moviepy. I agree with both of the contributions to this discussion that were made overnight on this ticket. @OsaAjani, @Zulko , @tburrows13 , @ShakedDovrat , and @B3QL please email me from the email address listed in the spreadsheet above and give me permission to add you to that spreadsheet and what information you would like added. It seems like we almost have the start of a quorum here for steering. Let's see what happens next from the change-list masters, owners.

I will continue to add this notice at the end of my posts and I invite you to do the same. People interested in participating or simply curious should email the point of contacts in this spreadsheet. https://docs.google.com/spreadsheets/d/1FftaQDTjZi8pMmeLQthY4BNpaKMLB2TDssUnuQZBJQI/edit?usp=sharing

OsaAjani commented 1 year ago

To keep everyone posted. I'm still working on doc and cleaning for v2. This is really tedious and boring work, even more considering I have to go forth and back between doc and code to make sure things are up to date, etc., and sometime writing the doc uncover incoherent API, undocumented params, etc., and I have to fix and improve. And no doubt I will miss things. But I'm making progress, one step at a time.

For info I've managed to completely remove dependency to ImageMagick, which is always so much trouble, by using only imageio for gif generation (already required) and pillow (which was already required) for text clip. It change the API a bit, but I have mostly managed to keep the actual behavior (inherited from ImageMagick) supporting automatic best size font selection and label/caption methods... (let me tell you, text writing to image in python is a pain).

I'm pretty confident we will be able to also remove dependency to opencv in the future, or at least reduce usage to such specific use case will be able to make it optional, but for now it will remain required. I will just try to always use pillow instead of opencv and remove opencv for functions that already support both if I see some.

davidbernat commented 1 year ago

@OsaAjani Great work. Very impressive given the self-initiative. Four quick notes that should be improvements.

  1. PIL creates gifs, if I am not mistaken, through its Frames API/mechanism.
  2. Removing ImageMagick may be possible: automatic best font, etc, is straightforward, for instance, and I have implemented it myself elsewhere. Fewer dependencies is awesome; and I should educate myself on its dependency.
  3. If you want to split off a part of the document, I read through the document this weekend and can help.
  4. Toss me your changes to do a code review? Directly assign me a review, etc.
Zulko commented 1 year ago

Apologies for my lack of communication.

I agree that completing the v2 transition is the best option. @OsaAjani thank you so much for pushing it forward and thank you @davidbernat for offering to help. @tburrows13 as the main architect of v2 would you also be available to assist/review by any chance? Otherwise I can promise to do my best to review, and if that's too slow I can give you merge rights on the repo.

Regarding governance, I am not opposed to a transfer in principle, but that will take a good amount of faith. As unmaintained as it is, MoviePy still installs and runs fine (?), is useful, and used by many. There is always a risk that a move would leave the project even worse off (this is not a judgement on anyone's competence, simply a remark on project dynamics when there is no other incentives than the members' own motivations).

Some general comments towards v2 after reading the latest messages:

mgaitan commented 1 year ago

Hello everyone,

Wow, it's nice to see so many people interested in Moviepy, but boy, do you like to write! 🤣

I want to make my contribution as pragmatic as possible.

I'm about to start my vacation, so I won't be very active, but I would love to help with any of these tasks when I return.

OsaAjani commented 1 year ago

If you want to split off a part of the document, I read through the document this weekend and can help. Thanks for offering, but right know I feel like it's just too messy to be able to split the effort and remain consistent.

@Zulko So glad to see you here ! Thanks so much for your work on moviepy !!!

  • OpenCV and pygame (and moviepy.editor) can probably go away in v2, they might have been a false good idea to begin with, and the corresponding features might have no userbase today.

Well, it would need rewriting preview, which I think is the most (and really probably only) important feature using it right now. But I guess I could do that.

  • For imagemagick and text generation, my understanding was that @tburrows13 was to replace it with cairo or PIL-based text generation?

Well @tburrows13 have mentioned the idea in the past (totally why I've done it), but it was not included in the v2.dev nor main release. Cairo would have been a new dependency, so I used pillow (cairo would probably have been nicer though, god I hate pillow text api soooooo much). We lost the kerning params in the fight though. Not technically impossible to implement, just too messy and cumbersome for now.

Regarding governance, I am not opposed to a transfer in principle, but that will take a good amount of faith.

I think you should keep an ultimate governance on the project. I like @mgaitan idea to automate release on pipy. I also think it would be good to allow more people to merge PR, etc. I don't know what technical solution would make it possible, but it would be a nice solution to be able to do something where PR that do not conflict can be merged by a voting system. For example, we could consider that any contributors on the project have a vote. When someone post a PR, all contributors are notified and can review and vote. If X (for example 2, or 3) contributors vote for merging, the PR is merged. If the author of the PR is new, he is now be a contributor, and can in turn vote on futures PR. Of course no vote for yourself. Administrator of the project can reject/accept a PR without voting, or block a contributor deemed toxic.

Same principles could be later extended to other

We need to smooth the transition to 2.0 to make it less traumatic.

Well, on one hand, going from 1.x to 2.x mean by definition API breaking, and I would rather not write more code we will have to maintain to check for old method names calls and offer dropout replacements. And even if depreciation notice are nice in theory, in practice it tend to make writing new code more time consuming, and people mostly ignore them until the real break point happen anyway. On the other hand, I do agree that transition to 2.0 must be as smooth as possible. So I think that rather than adding checks in the code, we should make a very clear and accessible documentation page "Upgrading from 1.X to 2.X", informing users of the changes and how to migrate from previous to new version, and add a big red warning on top of the doc. As well as add an alert message to advise people to take a look at this section of the doc on issue creation.

Also, when people will write code using the 2.0, the IDE will probably show an error if they try to access an unknown method, doing part of our work.

tburrows13 commented 1 year ago

So I think that rather than adding checks in the code, we should make a very clear and accessible documentation page "Upgrading from 1.X to 2.X", informing users of the changes and how to migrate from previous to new version, and add a big red warning on top of the doc.

Hey, just checking in - I haven’t read everything thoroughly but this all sounds exciting. I started work on a docs page for exactly this, I will try to dig it up.

tburrows13 commented 1 year ago

Well @tburrows13 have mentioned the idea in the past (totally why I've done it), but it was not included in the v2.dev nor main release. Cairo would have been a new dependency, so I used pillow (cairo would probably have been nicer though, god I hate pillow text api soooooo much). We lost the kerning params in the fight though. Not technically impossible to implement, just too messy and cumbersome for now.

I think the issue was more with imagemagick specifically being a very hard-to-deal-with dependency. If Cairo is easily installable through PyPI then I have no issues with it. But if pillow is suitable, then I suppose that would be even better. There was some prototyping of draw_text done by someone using some non-imagemagick solution, but starting from scratch is probably best.

davidbernat commented 1 year ago

Thank you @Zulko for beginning to move the quorum forward with your significant oomph, and thank you everyone, especially for all the writing, as this is the only way we move forward, even though of course this is a lot of reading.

A few points to @Zulko (c.f. @tburrows13 @B3QL @mgaitan @OsaAjani):

  1. If you have not reached out to me by email and given me permission to add you to the spreadsheet; please do. I. know, I know, it is annoying, but it moves these things to fruition. I promise. I have been there before.

  2. @Zulko, I agree with your points. I have very slowly started developing moviepy into a cloud server and I have reached the point where I have to educate myself on increasing performance and optimizations. I spent a few hours reading last night and ffmpeg at its native bin and wrapper levels all operate on filepaths and therefore cannot easily be handled in pure RAM; but, I see there may be workarounds. The encoding and manipulation at the ffmpeg level especially seems to have a lot of fine-tuning optimizations that can happen, though this seems to be a magic art deep in the bowels of newsgroups; and, of course, I am planning for what open source video codex of 2026, etc, will be. In short, @Zulko, can you please kindly email me to help me point ourselves in the direction this inquiry needs. Anyone who wants to be in the conversation please kindly email me as well.

  3. I agree "We need updated narrative documentation and improved API self-documentation." I would be thrilled to take a crack at updating the document page for the over-arching narrative if @OsaAjani and @B3QL approve. This is in part what I am trying to do with the "Steering Committee" so again please email me your contact information.

  4. I agree "We need more administrative permissions." I am very happy to perform the role of code review, as well, so, please, everyone you have permission to at-add me to the pull requests you want to have submitted. OK?

  5. I must continue to insist on shedding packages. Especially from essential features. On the other hand, I am not the one who build the TextClip functionality. The PIL text draw has never caused me trouble. What is the trouble, @tburrows13? https://www.geeksforgeeks.org/python-pil-imagedraw-draw-text/

Thank you to everyone. I want to make moviepy 2024 a lean, distributed machine learning technology.

cc: @Zulko (c.f. @tburrows13 @B3QL @mgaitan @OsaAjani) I will continue to add this notice at the end of my posts and I invite you to do the same. People interested in participating or simply curious should email the point of contacts in this spreadsheet. https://docs.google.com/spreadsheets/d/1FftaQDTjZi8pMmeLQthY4BNpaKMLB2TDssUnuQZBJQI/edit?usp=sharing

OsaAjani commented 1 year ago

Hey, just a heads-up to say I'm still working on all of this. I have written the quick prez, the loading, modifying (including creating your own effects), and compositing part of the getting started, as well as make them more chronological (i.e first you load, then you modify, you compose into a final clip, and finally you will preview or export - that's the next thing to be written).

Those page are not new, I have kept part of the old structure, updated what needed to be, add more example, add doc for previously missing kind of type (the UpdatedVideoClip was something to understand, and even more to find a good yet easily understandable example ^^). Meaning those are pretty heavy pages, with a lot of info. Somewhere between a tutorial and an API. I think it might be interesting to start with a short tutorial, something like a page with an example project step by step (we load, we fadein/out a title, we apply effects, resize, compositions, etc., with preview of different steps, and finally upload), where each step point the user to the more indepth matching part.

Now, from a code point of view, I've been able to rewrite preview (without interaction, but I really dont think we need it) to not use pygame or opencv anymore, making theme mostly removable (we loose manual tracking in the process, but I dont think anyone use them anyway), but instead to use ffplay.

I would have loved to find a way to do it without ffplay, but that seems really hard.

What I like about my current solution is that, if you have installed ffmpeg on your system, you will also have ffplay, so we depend on only one project, and we have the same global logic for preview and writing.

What I dont like is that ffplay don't come with imageio. Meaning you need to install it yourself. Just like imagemagick before.

But the more I look at the code, the more I realize we actually don't use imageio that much. In fact, we use it for 4 things.

  1. Ship ffmpeg with moviepy
  2. Write to GIF
  3. Read an image
  4. Save an image

Point 2, 3 and 4 can all be done with either ffmpeg or pillow. Actually, writing a gif with ffmpeg is basically the exact same thing as writing a video.

I would want the opinion of @Zulko and @tburrows13 (obviously all other opinions are also welcome) about the following proposition:

This way we would once and for all separate ourselves from the ffmpeg question. Its up to the user to install, choose, manage, etc. his version of ffmpeg, we just invoke it, we officially support only the standard ffmpeg, from version X to Y.

So basically a normal install from a brand new system would just be something like: 

sudo apt update -y && sudo apt install -y python3 python3-pip ffmpeg
pip3 install moviepy

From that point, we have everything ready to go.

PS : @davidbernat

I spent a few hours reading last night and ffmpeg at its native bin and wrapper levels all operate on filepaths and therefore cannot easily be handled in pure RAM

I might miss a point, but I think this is not true, ffmpeg is capable of both reading and writing from/to stdin/sdtout with pipes, that's in fact how moviepy communicate with ffmpeg.

davidbernat commented 1 year ago

Happy to discuss further. Please include me in peer-review and other documentation/steering discussions earlier. Very happy to see you currently running with the baton. Currently I am working on improvements to software offline.

Zulko commented 1 year ago

Some remarks:

the UpdatedVideoClip was something to understand

This is a good example of application-specific clips that don't really belong in moviepy-core, could be taken out to an "add-on" library. For this particular case (looks like it's to simplify animations from simulations) it's just 5 lines of code and I think people who need something like this will figure it out by themselves. Could be simply removed.

We remove completely the editor notion (no need anymore as we never create a pygame session)

Yes please, as long as the most important classes and functions are at the root of the library, so that basic examples don't need to import from many different submodules.

We remove imageio, opencv and pygame. We stop shipping ffmpeg with moviepy. In the installation guide, we clearly state that it is mandatory to have ffmpeg & ffplay installed on your system with a clear explanation of how to transmit ffmpeg and ffplay path to moviepy (os.environ).

Yes to removing opencv and pygame, but I'm not sure about imageio.

Ideally we'd keep MoviePy beginner-friendly, which means "pip install and start making videos". If we ask users to configure their own setup, we will probably see a rise in issues for different systems (Windows in particular). My understanding is that imageio has solved this problem on their side, and that there are no downsides to just using what they have, and this is a good example of why MoviePy should rely on imageio.

Beyond just getting the ffmpeg binary, MoviePy should probably use imageio more, not less. The idea here is to separate the low-level (reading and writing frames with ffmpeg) which would be done with imageio, from the high-level (mixing clips together) which MoviePy would focus on. ImageIO could be the "numpy" of frame encoding, the one place where low-level ffmpeg problems are solved.

It is unfortunate that moviepy video reading/writing doesn't use imageio, that was definitely the intent a few years back and I can't remember what was missing. It looks like the project is still maintained and has added a lot since then, they might even have some of the GPU features some users have requested

use ffplay

I don't know ffplay very well but this sounds like a nice idea. As long as ffplay is optional and not required until a user wants to use `preview(), that sounds good to me. Sad to lose manual tracking but yeah I must have been the only one to use it, and the last time was 5 years ago.