Blender Stack Exchange is a question and answer site for people who use Blender to create 3D graphics, animations, or games. It only takes a minute to sign up.
Sign up to join this community
I'm putting together a video from the VSE. In the sequencer window it is rendering and scrubbing at near realtime yet during output it is taking around 3x longer.
The frames are taking 0.13 seconds each whilst the CPU is only utilised around 20%. I am rendering onto an SSD and using H.264 format 1280x720. Tile size options etc appear to have no or very little effect.
In short - is there any method to speed up the rendering of frames from the VSE?
Multithreaded VSE rendering is now natively implemented in blender (since around 2.8 or 2.9), which makes this project kind of obsolete, but for more fine grained control of resources (background rendering, utilizing multiple machines) it can still be useful.
I was looking for a free (and maybe even open-source) video editor, and after using it for a while I found out that Blender is very capable of this task, but I was facing the same problem with the unused resources during exporting the finished file. I was searching everywhere, but I couldn't find anything about speeding up the Video Sequence Editor (VSE) rendering that would work for me.
After thinking for a while and trying out things I realized that I can run multiple renders at once from the command line, and it seems like the performance scales pretty much linearly with the number of instances running. Of course until you reach the limit of your processor or the amount of RAM you have. (I was running at 87% CPU and 89% of the memory filled, and I wouldn't recommend going higher, because if one of the rendering processes fail to allocate more memory it will crash and you have to do that part over again.)
After you have the parts/chunks of rendered video, you can put it together using the concatenation functionality of ffmpeg. I tried it with mp4 [H.264] and avi [Xvid], so I can confirm that those are working, but there might be other formats that can be used, but I haven't experimented with those yet.
I don't have time to do a full tutorial now, but if anybody will show interest I might get around to putting together something.
For this to work you need to have the blender and ffmpeg executables in your PATH environmental variable, and the project file needs to be in the current working directory of the command window. The code parts I finally ended up writing and using were these:
blender -b "name_of_project.blend" -E BLENDER_RENDER -s 0 -e 1000 -a
to render one chunk of video. (You can try changing BLENDER_RENDER to CYCLES if that works better for you, and you have to replace the 0 and 1000 with the actual frame range you want to render. I had quite good results with doing it in chunks of 1000 frames and having around 4-6 processes running at once.)
You have to have multiple CMD windows open at once (unless you write a program to automate it), and you need to call them with different frame ranges.
(I would suggest 0 - 1000; 1001 - 2000; 2001 - 3000; ...)
[The frame range is inclusive, so pay attention not to write the ending number as the beginning number for the next process.]
You have to set the output properties in the Blender rendering setting while the project is open, but you can close the window afterwards. I think you can also set memory limit for the individual processes in Blender at File -> User Preferences -> System -> Memory Cache Limit, but I am not entirely sure about what that does.
For generating the list with the filenames I used PowerShell:
dir -n *.mp4 | %{"file '" + $_ + "'"} | Set-Content parts.txt
And for joining them I called ffmpeg (also from PowerShell, but this should work from CMD too.)
ffmpeg -f concat -i parts.txt -c copy ../output.mp4
This seems to be almost instantaneous, so you don't even really need to count this into your rendering time. It puts the resulting video in the parent directory so it doesn't get mixed into the video parts.
(If you used avi, you only need to change the extension of the output file and this should work.)
I hope that I could help somebody!
My main sources for the Blender command line options were these sites:
https://www.blender.org/manual/render/workflows/command_line.html
https://www.blender.org/manual/advanced/command_line.html
http://wiki.blender.org/index.php/Doc:2.4/Reference/Command_Line
And for the joining of the files using ffmpeg:
https://trac.ffmpeg.org/wiki/Concatenate
https://superuser.com/questions/607383/concat-two-mp4-files-with-ffmpeg-without-losing-quality/607384
https://stackoverflow.com/questions/15186500/howto-merge-two-avi-files-using-ffmpeg
Edit 2:
Version v0.4 has been released with the contributions of RedRaptor93.
Edit:
I wrote a very basic application for the purpose of automating this process, that GitHub user MeTwentyFive very generously took upon and updated, so now it's more convenient and less buggy.
I have the code of that publicly accessible here:
https://github.com/Isti115/BlenderRenderController
I also included an executable in the release of the package, but for that to work you need to have the main blender.exe file accessible from the PATH environmental variable for rendering, and the same thing holds true with ffmpeg.exe for concatenating the parts.
If you need any help modifying, compiling or using it then feel free to message me!
ps.: You can get ffmpeg from here: https://ffmpeg.org/download.html
And I assume that you already have blender, since you are here asking questions about it. ;)
Edit 3:
Mikeycal Meyers wrote his own python script as a cross-platform solution for the problem.
You can find his explanation about it here:
https://youtu.be/rgwP5L1bICk
and the actual project here:
https://github.com/mikeycal/the-video-editors-render-script-for-blender
Make sure to check his work out as well, and help him improve it if you know some python! ;)
One common reason for the sequencer to slow down is editing video at a different resolution, for fast editing make sure the input and output sizes are the same. (even one pixel difference will make a significant slowdown)
Another way to speed up things is by enabling pre-fetch frames: *
User Prefs -> System -> Sequencer/Clip EditorThis will use multiple threads to evaluate frames in advance.
If you have enough memory you could also increase the cache limit, which is accessed from the same place.
Warning: There is a bug with pre-fetch which is why its disabled by default, any animated sequence strip values (animated opacity for example), won't be correctly taken into account when pre-fetching, however this may not be important in many cases, and crossfades avoid this issue. Just worth noting.
The pre-fetch option was added before Blender's animation system re-write, and the 2 don't work correctly together.
I have been having the same problem and I found that changing
User Prefs -> System -> Images Draw Method
to "GLSL" or "DrawPixels" from "2D Texture" about doubled my VSE render speed.
You can use Pulverize to do multi-process rendering from Blender's Video Sequence Editor:
https://github.com/sciactive/pulverize
This will divide the rendering time of your project by the number of CPU cores you have.
(This is like Isti115's program, but it runs on Linux.)
For what it is worth I wrote a small addon paraller_render.py (can be found at https://github.com/elmopl/ktba/) that lets you easily select how many instances of Blender in parallel it should launch and into how many parts to split your video.
To install simply download file from addons/parallel_rende.py and put it in your Blender's scripts/addons directory.
You should be able to enable it in File -> User Perfernces... -> Addons and search for VSE Parallel Render.
Once enabled you should be able to just press space in sequencer (or anywhere else really) and search for "Parallel Render" action.
Note: As it launches other instances of Blender and tells them to load the same file it will use last saved version of your file. So if you want your most recent changes to be reflected in those renders just save your file before launching it.
TL;DR
For a solution that doesn't involve code and can be done natively inside Blender (at least, it works inside 2.8X), apparently, when you create a new Blender file, if you choose the "General" option on the splash screen or if you just click out of the splash screen (or have disabled it in your preferences), then video editing will render much slower than if you had clicked the "Video Editing" option in the splash screen.
I think the reason it's faster to use the "Video Editing" option for video editing is that it changes a few settings by default. For example, in Properties -> Render Properties -> Color Management, the "View Transform" is set to "Filmic" for "General" and "Standard" for "Video Editing." In addition, there is no default cube and light in the "Video Editing" template.
If you've already done a bunch of work editing your video after pressing "General," you can try changing the color management setting I mentioned above from "Filmic" to "Standard." It worked for me in a test run, but not on a different project. But you could try it and see if it works.
If that doesn't work, you can try copying all you video/audio strips into a new Blender file. If you try copying them from one window to another, it won't work. But if you copy them, save your Blender file, and then go into File -> New -> Video Editing, then you will be able to paste the video/audio strips.
Finally, make sure you're render output it set correctly. Rendering to image files is safer because, if blender crashes, you can easily reopen the blender file and continue rendering. But rendering to image files is slower than rendering to video files, and for short renders in the Video Editor, it's best to render to a video file. I usually use the "FFmpeg video" File Format.
Then use the "h264 in MP4" preset for the encoding.
Just remember to expand the "Encoding" section, look under the "Audio" section, and change the "Audio Codec" from "No Audio" to "MP3" or whatever audio format you want to use.
And here are all the settings together in one shot:
Those settings usually give me approximately realtime rendering for simple video tracts (I think image sequences are actually slower, but I'm not 100% sure). Note that the render preview will skip frames, so it will still look choppy, but if you check the frame number that it's rendering, you should see it skipping along pretty quickly.
Here is a single very scary command line which does incremental, parallel, resumable renders on Linux --- and it ought to work on Windows to if you have Cygwin.
seq 3041 75966 | parallel --joblog joblog -X -n 20 --eta --bar 'blender -b video.blend -E BLENDER_RENDER --render-frame `echo {} | tr " " ","`'
Replace the two numbers after seq with your start and end frames. Replace video.blend with your Blender file. Then run, and... hope...
It'll show you a pretty clunky progress bar on the command line which looks like this:
5% 184:3463=739s 6861 6862 6863 6864 6865 6866 6867 6868 6869 6870 6871 6872
The 5% tells you where it's got to, the 184:3463 tells you which batch it's reached and how many are left to go (note that frames are processed in batches controlled by the -n argument, and are not the same as frame numbers, increasing -n will make for slightly more efficient renders), the =739s is an estimate of how long there is to go, and be warned that it lies foully, and the rest of the numbers indicate frames it's currently rendering.
If you ^C it in the middle, or it dies with lack of disk space or something, you should be able to resume by adding --resume after the parallel, and it should automatically pick up from where it left off.
Remember to configure for rendering to frames, etc, in the normal way.
