x264 offers a very wide set of parameters and therefore an accurate control over compression. In this third part we will look more closely at the parameters you need to know to encode to H.264.įFmpeg uses x264 library to encode to H.264. PART IV – FFmpeg for streaming (revised 0)

Constrained CRF is not a poor idea at all, but attempting to run 2-pass encoding with it is.PART II – Parameters and recipes (revised 0) If file size is your top priority, you need to move away from H.264 and choose a more recent codec library optimized for compression (such as h.265/HEVC or VP9, possibly AV1). Best case scenario, they will look the same. It's a time waster and you'd likely end up with worse quality versus the first pass result. The 2nd pass will almost undoubtedly take longer to process than the first pass, because of how the 2-pass process works in ffmpeg, and the fact you'll be compressing already compressed images again.

The target file size will still have the same maximum possible size it had before. First, how would you constitute the 2nd pass? If you repeat the first pass logic, you'll likely attain a smaller target file, but you'll also likely dilute the overall image quality to some extent. Running 2-pass on capped CRF (aka Constrained CRF) is redundant and a waste of time. Now, take that concept and think about applying ffmpeg's 2-pass model to it. This forcibly limits the freedom of the CRF algorithm with respect to its upper limit of bits-per-frame. The purpose of which is to constrain/limit the overall file size to a pre-defined maximum.

The author's point was to describe 'capping' or constraining the CRF setting by creating a bandwidth ceiling per frame. I'm not sure you gathered the spirit of that article as intended.

Ffmpeg crf not used for any stream