Peter Cordes suggested the following explanation as a part of his answer at Video Production Stack Exchange to ' Why processor is 'better' for encoding than GPU?': (That is, they require a higher bitrate to make output with the same perceptual quality, or they make output with a lower perceptual quality at the same bitrate.) Hardware encoders typically generate output of significantly lower quality than good software encoders like x264, but are generally faster and do not use much CPU resource. …įfmpeg wiki asserts that this is typical for hardware accelerated encoding: It does this by taking motion into account. It will compress different frames by different amounts, thus varying the QP as necessary to maintain a certain level of perceived quality.

This typically leads to a hugely varying bitrate over the entire sequence.Ĭonstant Rate Factor is a little more sophisticated than that. … The quantization parameter defines how much information to discard from a given block of pixels (a Macroblock). Werner Robitza explaining why CRF still allows to save bits in comparison to setting constant QP: It worth noting that this is still different from CRF because constant quality, as it is determined by -cq, sets constant quantization parameter (CQP) instead. You probably want to consider that to help in your case. Dennis Mungai's detailed answer to ' How can I use CRF encoding with nvenc in ffmpeg?' at Superuser suggests to use -cq:v 19 and -rc:v vbr parameters instead to get constant quality with variable bitrate.

with ffmpeg -h encoder=hevc_nvenc -hide_banner. You can check what the encoder supports, e.g. The hardware accelerated encoders do not support Constant Rate Factor (CRF, -crf) to determine size/quality ratio.

Cuda ffmpeg linux