What are the best video codec, encoding speed, and file format for rendering animation into a video file?
As far as file-format goes, MultiLayer OpenEXR should be used for all files up to and including the final, from which the “distribution files” (movies, JPEGs, PNGs) are then generated.
This file is an industry standard data storage file format, originally created by Industrial Light & Magic with the “multilayer” enhancement added by the Blender Foundation. It stores the exact data streams (“layers”) that are produced by the render engine, as a loss-less file of floating point numbers. (Yes, that means “the files are big,” but who cares?)
It is very common to break the process of creating an image down into stages, and use of this format will ensure that the exact numbers will be preserved throughout the entire process, with no loss or recoding (codecs). You make decisions abut “codec, encoding speed, and [distribution] file format” only when you are producing the distribution files.
With the humongous file, OpenEXR, will it eat up a lot of computer’s memory?
“Actually, no!”
The file-format is large because, at this point in time, “file size no longer matters.” The only thing that matters now is accuracy and portability. Blender does not have to load the entire file into memory in order to parse its content.
The point is, having done so, Blender now once again has the exact set of floating-point numbers(!) that the writer of the file did. (“One ‘layer’ at a time …”) And: every other piece of software that is cognizant of the file-format will likewise have exactly the same set of numbers.
"Deliverable-file" formats, of course, have an entirely different set of technical objectives. Their goal is to produce an acceptable image – to the human eye that probably isn’t paying attention – (1) in real time, (2) on possibly very-cheap hardware, (3) using a file that needs to be as small as possible. So, that’s why you need to generate each one of them, individually, from a pristine digital source that’s stuffed with information.
When I render videos for YouTube I always render the video as PNG sequence and then use h265 compression using ffmpeg.
Save frame by frame, not video. If you want compositing after render, then save HDR or EXR. If you compress your EXR or HDR files with 7z format, you can save a lot of HDD space.
Trust me on this – there are two(!!) types of digital-files in this world: (1) Those that are designed for “pipeline use,” and (2) Those that are intended for “deliverable files.” Please do not ever mix the two.
Each of the many stages in your digital production process consists of “resource intensive steps that you really don’t want to have to repeat,” each one of which produces a slew of digital data which you need to be able to provide exactly(!) into every future step. This is why such formats are always “frame by frame” … in case you need to re-start a render job … and “compressed” only in guaranteed-loss-free ways.
If you’re running out of space, this is the 21st century!!" Go buy an[other] external hard-drive at the office-supply store and plug it into your USB port or hub.
“Deliverable files,” on the other hand, are designed for “cheap hardware” and “network transmission that might not be fast.” At this, final(!) point in the process, “‘lossy’ doesn’t matter anymore.” “Gamma correction” is needed. And so on. All of these things being things that you absolutely cannot afford earlier in your pipeline!
Therefore: “first, tend to the technical requirements of your pipeline.” Use “OpenEXR MultiLayer” until the very last step – your “final deliverable master” – at which point you can safely discard the “MultiLayer” (if you want to …) while keeping the “OpenEXR.” At the final end of the process, you have your pristine flie of “precious numbers.”
From this OpenEXR master(!) … start producing “the files that are intended for display hardware.” Produce each one individually, in whatever manner is best for that target. “Codec? Encoding speed?” Sure. Because now it doesn’t matter. Each one is getting its data – individually – from the same pristine source.