Return to Answer

Footnote 2: Other codecs like h.265 (with the x265 encoder) or VP9 can offer even better rate distortion tradeoffs, but at the cost of much more CPU time to encode. For a fixed encode time, I'm not sure if there's any advantage to x265 over x264. But decoder compatibility with h.265 is much less widespread than h.264.

Decode compatibility is very good for h.264 main profile, and hopefully also high profile these days. (8x8 DCT is most useful for high resolutions like 1080p and especially 4k.) x264's default is high profile. Some obsolete mobile devices might only have hardware decode for h.264 baseline profile, but that's significantly worse quality per bitrate (no B-frames, and no CABAC, only the less efficient CAVLC for the final step of losslessly encoding structs into a bitstream.)

Footnote 2: There's also -preset placebo which takes much more CPU time, for maybe 1% better quality per bitrate. i.e. pushing much farther into the diminishing-returns of spending more CPU to compress better.

Other codecs like h.265 (with the x265 encoder) or VP9 can offer even better rate distortion tradeoffs, but at the cost of much more CPU time to encode. For a fixed encode time, I'm not sure if there's any advantage to x265 over x264 for presets near x264 medium or slow at least. But decoder compatibility with h.265 is less widespread than h.264. But if you don't mind spending more CPU time encoding, -c:v libx265 -preset slow is pretty reasonable and probably better quality than x264 -preset placebo for the same bitrate on some content. (x265 does have more of a tendency to smooth out texture detail, though.)

Decode compatibility is very good for h.264 main profile, and hopefully also high profile these days. (8x8 DCT is most useful for high resolutions like 1080p and especially 4k.) x264's default is high profile. Some obsolete mobile devices might only have hardware decode for h.264 baseline profile, but that's significantly worse quality per bitrate (no B-frames, and no CABAC, only the less efficient CAVLC for the final step of losslessly encoding structs into a bitstream.) Many old guides recommend baseline profile for max compatibility, but that sucks a lot. (Perhaps as much as 40% worse quality per bitrate vs. high profile, on 1080p live-action, if I'm remembering correctly from some codec-testing results.)

Related:

• https://trac.ffmpeg.org/wiki/Encode/H.264
• https://slhck.info/video/2017/02/24/crf-guide.html (some info about the bitrate -crf 23 will chose on different content.) Unless you want a specific bitrate, CRF rate-control is almost always the best choice, potentially with upper limits from VBV. (e.g. so local bitrate doesn't go through the roof for a second if you encode the HBO logo = screen full of static.)

This is mostly orthogonal to rate-control, which decides how many total bits to spend. x264' default rate-control is CRF 23 (ffmpeg -crf 23); if you want smaller files, use -preset veryslow -crf 26 or something to spend fewer bits for the same complexity, resulting in more blurring. It's logarithmic so bumping up the CRF by a few numbers can change the bitrate by a factor of 2. For nearly transparent quality, -crf 18 or 20 is often good, but costs more bitrate.

That's why you don't get progressively smaller files at identical quality; -preset veryfast typically looks worse . -preset ultrafast is usually noticeably bad even at high bitrate, but other presets can look as good as veryfast if you spend much more bitrate.

This is mostly orthogonal to rate-control, which decides how many total bits to spend. x264's default rate-control is CRF 23 (ffmpeg -crf 23); if you want smaller files, use -preset veryslow -crf 26 or something to spend fewer bits for the same complexity, resulting in more blurring. It's logarithmic so bumping up the CRF by a few numbers can change the bitrate by a factor of 2. For nearly transparent quality, -crf 18 or 20 is often good, but costs more bitrate.

That's why you don't get progressively smaller files at identical quality; -preset veryfast typically looks worse at the same CRF. -preset ultrafast is usually noticeably bad even at high bitrate / low CRF, but other presets can look as good as veryslow if you spend much more bitrate.

Yes, h.264 has a lossless mode, as part of the Hi444PP profile. No, you don't want to use it over the internet; many decoders other than FFmpeg lack support for that special feature, and the bitrate is enormous, like 100 to 200 Mbit/s for 1080p30 YUV 4:2:0 or RGB 4:4:4. How to create an uncompressed AVI from a series of 1000's of PNG images using FFMPEG has some test results from the Sintel trailer.

Decode compatibility is very good for h.264 main profile, and hopefully also high profile these days. (8x8 DCT is most useful for high resolutions like 1080p and especially 4k.) x264's default is high profile. Some obsolete mobile devices might only have hardware decode for h.264 baseline profile, but that's significantly worse quality per bitrate (no B-frames, and no CABAC, only the less efficient CAVLC for the final step of losslessly encoding structs into a bitstream.)

h.264 decode performance can vary some with number of reference frames, more having a larger memory footprint and thus maybe more cache misses for a CPU decoder. But often h.264 is decoded by hardware. As with many lossless compression schemes, big changes in decode performance are only had with totally different codecs (like h.265), not different options for the same codec. Extra encode time is spent searching for different ways to encode the same bits, but there's only one way to decode.

And yes, h.264 has a lossless mode, as part of the Hi444PP profile. No, you don't want to use it over the internet; many decoders other than FFmpeg lack support for that special feature, and the bitrate is enormous, like 100 to 200 Mbit/s for 1080p30 YUV 4:2:0 or RGB 4:4:4. How to create an uncompressed AVI from a series of 1000's of PNG images using FFMPEG has some test results from the Sintel trailer.

Decode compatibility is very good for h.264 main profile, and hopefully also high profile these days. (8x8 DCT is most useful for high resolutions like 1080p and especially 4k.) x264's default is high profile. Some obsolete mobile devices might only have hardware decode for h.264 baseline profile, but that's significantly worse quality per bitrate (no B-frames, and no CABAC, only the less efficient CAVLC for the final step of losslessly encoding structs into a bitstream.)