Why write_videofile() param 'threads=' does not work on windows?
See original GitHub issueWhy write_videofile() param ‘threads=’ does not work on windows? I tested this code on a 48 cores windows server:
ThreadCount = multiprocessing.cpu_count()
bk_clip.write_videofile(output_file_name, fps=VideoFps, audio=False, logger=None, threads=ThreadCount)
There are only 3 ffmpeg.exe appears in the task list as below
But this server is Intel Xeon E5-2678 v3 @ 2.50GHz, 2cpu * 12 cores = 24 cores.
It supposed to be 24 threads, but I only found 3 ffmpeg.exe
Issue Analytics
- State:
- Created 3 years ago
- Comments:11
Top Results From Across the Web
multiprocessing with moviepy - python - Stack Overflow
So I search on the moviepy's docs "threads", I found something in the "write_videofile" function that i can set my threads to speed...
Read more >Problem with write_videofile : r/moviepy - Reddit
write_videofile ("test.mp4") #works test = "test" write_videofile(test + ".mp4") #produces a video with audio, but which is frozen on the ...
Read more >movie-py/Lobby - Gitter
I can't get audio to work, even on a simple read, and write. When I open the result file, the audio is gone....
Read more >Source code for moviepy.video.VideoClip
Note that this does not impact the quality of the video, only the size of the video file. ... Provide the 'codec' "...
Read more >Pushing the Limits of Windows: Processes and Threads
In this case, it's the initial thread stack commit that causes the system to run out of virtual memory and the “paging file...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
I agree that I would love to have an improved speed in MoviePy. Unfortunately, MoviePy is very limited by the number of active contributors (at the moment, only me). For the time being, I am working on changes that increase the usability and stability (both of which have been lacking for some time), which I think are more important at the moment, because once improved, they should reduce the ‘community’ work, such as handling bug reports and questions. It also makes it easier to add new features in the future if the existing code is stable.
For improving performance, there are the following things to take into account:
I can’t give a timeline, because (assuming that it is me that is still managing it), it entirely depends on how much time I am willing to give to this project, which depends on how much I am enjoying it. Sorry.
Like I said earlier, if someone else who really priorities speed comes and works on that, then I’d be happy to review and merge that code (which is what happened in #1157 - will be merged soon).
I just want to leave a ‘Thank you’ note here. Although it is somewhat slow, it is far more practical than anything else I’ve tried. The time it takes rendering has far been compensated by the time it saves to code. And rendering does not require effort! So, thank you @tburrows13 for all the work.