Sorry if this is a noob question but I started using Blender today as a free video editor and now that I'm rendering my project, it's taking a lot longer than I was expecting.

The project is basically splicing two 1920x1080, 60fps videos into one, 6-minute video with a simple fade out/fade in transition between the two videos and I have everything set up to use the correct resolution and FPS.

The problem is, I'm rendering at about 20fps (so about 3x realtime) while my CPU utilization is at 15% so I can't help but feel this could be going much faster if I found a way to increase my CPU usage. I'm curious if I've failed to select the optimal settings for my system or if this is just par for the course with Blender's video encoder?

My specs:

  • Intel i7 4790k
  • Nvidia GTX 970
  • 16GB DDR3 2400mhz
  • Blender 2.73a
  • H.264 encoder with default profile and bitrate set to 30000kbps

3 Answers 3


As far as I know, the Sequencer has no multi-core support in the final rendering. (Surprisingly it has it for rendering proxy files). Also GPU rendering isn't available either.

I just found a recent thread in which a dev claims to work on multi-core support, so maybe it will come in the future. I definitely would appreciate such a feature.

  • $\begingroup$ Multi-threaded encoding is only possible with specific encoders; the proxy tool likely uses a simple editor-oriented codec for this purpose. $\endgroup$
    – Skrylar
    Commented Nov 19, 2015 at 10:07
  • $\begingroup$ That's a dead link now. $\endgroup$ Commented Aug 13, 2018 at 14:03
  • $\begingroup$ Thanks for letting me know. Link is replaced, but looking at more recent answers, there doesn't seem to have been much development blender.stackexchange.com/a/61912/11435 $\endgroup$
    – Felix
    Commented Aug 14, 2018 at 1:31

Multi-threaded encoding of videos is very finicky, it depends entirely on the codec and encoder for availability--and Blender does not offer a lot of flexibility here. Part of the problem is that for a codec like h264, every frame must be provided in order, while rendering on multiple threads will inherently finish the frames out of order and would need to be kept around (stalling) or stored somewhere until the encoder was ready (caching.)

Fortunately you can use the Frameskip option along with multiple instances of Blender. You need to set Blender to render each frame to a png file, give it a directory to store the frames, then save a new Blend file so these settings will be available to other instances. Secondly, give each Blender instance a different starting frame (one from 1, the second from 2, and so on) with each having a frameskip equal to the number of instances being used. Each instance will render a frame to a png file, skip the Frameskip number of frames, and move on, until the video's frames are fully rendered. This may also be used to distribute the rendering process across multiple machines if need be. Do be warned that the speed of your hard drive also comes in to play here--too many instances will end up waiting on the hard drive before they can write another frame, not actually going any faster.

This method will get your video out of the VSE, however its not shippable yet. You would then need to use an encoding program (probably ffmpeg) to take the directory full of pngs and compress that to your file. Using ffmpeg at the command line is a lot less convenient than simply hitting export, however there is one major benefit: you get complete control over the encoding process in this way, including whether to use multi-threaded h264 support, and better control over encoding (Blender and even some commercial tools won't allow you to specify CRF settings).


You can use Pulverize to do multi-process rendering from Blender's Video Sequence Editor:



You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .