# Workflow to convert rendered images to video

I have had recommendations to render images, rather than animation, so if an error occurs I do not need to rerender the entire sequence. I like the idea, but have had issues with high quality conversion of images into video. I have tried: ffmpeg, timelapseassembler, iMovie, Blender VSE. These can all do a decent job, but I find a lose quality in the images, relative to just rendering the straight workflow.

So to reword the question: "What is your workflow from rendered images to high quality video?"

• If you are rendering to a lossless image format like png there should be no difference.. – gandalf3 Oct 27 '14 at 22:11
• I do render to png but somewhere in my video creation, it looks like a bunch of compressed jpegs. – PhDeadlift Oct 29 '14 at 23:12
• Hm. And it works fine when rendering straight to a video? I normally use the VSE, and noticed nothing aside from the normal minor compression artifacts which are to be expected when rendering to a video format.. – gandalf3 Oct 29 '14 at 23:19
• Yes, there were than the typical artifacts, which is likely some setting I had incorrectly set. I will be trying @Plenus Franckly's "recipe" for ffmpeg when I get a chance tomorrow. – PhDeadlift Oct 29 '14 at 23:40

The only tool I've ever needed is ffmpeg. Here is my standard "recipe" for command-line conversion:

To convert default Blender sequenced PNGs at 24fps to a lossless 24fps YUV420p colorspace, x264 format video:

ffmpeg -r 24 -i %04d.png -c:v libx264 -r 24 -pix_fmt yuv420p -qp 0 output.mp4


The quality is determined by "-qp", with 0 best (lossless) quality, 51 worst. Also, know that the first "-r" determines how long each PNG will be shown, while the second "-r" determines the actual framerate of the output video.

As an example using that same command above, but starting from 0100.png, with each image viewable for 5 seconds in a video with a framerate of 30fps, plus a forced-rescale to 1920x1080 thrown in too:

ffmpeg -r 1/5 -start_number 100 -i %04d.png -c:v libx264 -r 30 -s 1920x1080 -pix_fmt yuv420p -qp 0 output.mp4

• Thanks for the detailed response. I will give these a shot and get back to you if it works for me. I was not previously specifying a colorspace, nor the quality. – PhDeadlift Oct 29 '14 at 23:14
• This looks much better! Thank you. When I start the conversion, I notice that it seems to skip over every two frames when displaying information in the terminal. Is it not totally reading in all the frames? Also, it starts at frame 8. A samples of the terminal output is here: frame= 8 fps=0.0 q=0.0 size= 642kB time=00:00:00.20 bitrate=26309.8kbits/ frame= 11 fps=9.3 q=0.0 size= 1155kB time=00:00:00.35 bitrate=27023.7kbits/ frame= 14 fps=8.2 q=0.0 size= 1738kB time=00:00:00.50 bitrate=28477.8kbits/ frame= 17 fps=7.3 q=0.0 size= 2409kB time=00:00:00.65 bitrate=30359.1kbits – PhDeadlift Oct 30 '14 at 6:57
• Hmmm... I've never noticed any skipping of frames. I'd guess you're simply seeing a screen data refresh delay. Is the resultant video the correct length in time? – Plenus Franckly Oct 30 '14 at 12:57
• It seems to be what you say. It is the correct length. Thanks a lot! – PhDeadlift Oct 31 '14 at 21:21
• You weren't mislead. Always render to still frames and control the encoding from a suitable tool. The only thing I would add to the answer is to pay attention to your color matrices otherwise FFMPEG will output files that will likely be displayed incorrectly in other software. In particular, -vf "scale=in_range=full:in_color_matrix=bt709:out_range=tv:w=1920:h=1080:out_color_matrix=bt709" etc. The range flags are deadly important, so be careful there. – troy_s Jan 7 '15 at 20:11