I’ll update and see. I did try cq in a previous iteration of my profile. The ffmpeg documentation is not exactly clear, but the NVidia documentation for their extension did mention crf vs cq for constant quality. Regardless, for most encodes, I can do an hour long show in about 10 minutes
You can query ffmpeg for the list of available options for each encoder, here’s what shows for h264_nvenc
As you can see there are 2 options -cq (which is what we want, constant quality) and -qp (which is NOT what we want as that’s a constant quantizer which is pretty useless).
You may need to set
-rc vbr also but it you can try it out with and without it and let me know how it goes.
-rc E…V… Override the preset rate-control (from -1 to INT_MAX) (default -1)
constqp E…V… Constant QP mode
vbr E…V… Variable bitrate mode
cbr E…V… Constant bitrate mode
vbr_minqp E…V… Variable bitrate mode with MinQP
ll_2pass_quality E…V… Multi-pass optimized for image quality (only for low-latency presets)
ll_2pass_size E…V… Multi-pass optimized for constant frame size (only for low-latency presets)
vbr_2pass E…V… Multi-pass variable bitrate mode
-rc-lookahead E…V… Number of frames to look ahead for rate-control (from -1 to INT_MAX) (default -1)
-surfaces E…V… Number of concurrent surfaces (from 0 to 64) (default 32)
-cbr E…V… Use cbr encoding mode (default false)
-2pass E…V… Use 2pass encoding mode (default auto)
-gpu E…V… Selects which NVENC capable GPU to use. First GPU is 0, second is 1, and so on. (from -2 to INT_MAX) (default any)
any E…V… Pick the first device available
list E…V… List the available devices
-delay E…V… Delay frame output by the given amount of frames (from 0 to INT_MAX) (default INT_MAX)
-no-scenecut E…V… When lookahead is enabled, set this to 1 to disable adaptive I-frame insertion at scene cuts (default false)
-forced-idr E…V… If forcing keyframes, force them as IDR frames. (default false)
-b_adapt E…V… When lookahead is enabled, set this to 0 to disable adaptive B-frame decision (default true)
-spatial-aq E…V… set to 1 to enable Spatial AQ (default false)
-temporal-aq E…V… set to 1 to enable Temporal AQ (default false)
-zerolatency E…V… Set 1 to indicate zero latency operation (no reordering delay) (default false)
-nonref_p E…V… Set this to 1 to enable automatic insertion of non-reference P-frames (default false)
-strict_gop E…V… Set 1 to minimize GOP-to-GOP rate fluctuations (default false)
-aq-strength E…V… When Spatial AQ is enabled, this field is used to specify AQ strength. AQ strength scale is from 1 (low) - 15 (aggressive) (from 1 to 15) (default 8)
-cq E…V… Set target quality level (0 to 51, 0 means automatic) for constant quality mode in VBR rate control (from 0 to 51) (default 0)
-aud E…V… Use access unit delimiters (default false)
-bluray-compat E…V… Bluray compatibility workarounds (default false)
-init_qpP E…V… Initial QP value for P frame (from -1 to 51) (default -1)
-init_qpB E…V… Initial QP value for B frame (from -1 to 51) (default -1)
-init_qpI E…V… Initial QP value for I frame (from -1 to 51) (default -1)
-qp E…V… Constant quantization parameter rate control method (from -1 to 51) (default -1)
Thanks for the above - I was pulling the commands from NVidia’s developer site - it seemed like it exposed a subset vs FFMPEG overall - I also noticed from some of the logs that hevc_nvenc is the new name for the encoder and that nvenc_hevc has been deprecated.
So I’ll try this modification to the encoding profile:
[----------------------] [MKV HVEC Constant Quality] Description=WARNING: Handbrake Constant Quality encoding (25) with Nvidia HVEC. order=ffmpeg, handbrake AllowH264CopyRemuxing=true FixedResolution=true AutoDeinterlace=true ffmpeg-UsingHardwareEncoding=True ffmpeg-general=-threads 0 -hwaccel auto ffmpeg-video=-ss 9 -c:v hevc_nvenc -cq 25 -rc vbr -map 0:v ffmpeg-audio=-acodec ac3 -ab 192k -map 0:a ffmpeg-audioac3=-acodec ac3 -ab 384k -map 0:a ffmpeg-ext=.mkv ffmpeg-audiodelay=skip handbrake-UsingHardwareEncoding=true handbrake-general=--decomb --denoise="weak" --loose-anamorphic --verbose=2 -T -O handbrake-video=--start-at duration:3 -e x265 -q 18 handbrake-audio=-E ffac3 -R auto -B 192 -D 0 -a 1,2,3,4,5 handbrake-audioac3=-E ffac3 -R auto -B 384 -D 0 -a 1,2,3,4,5 handbrake-ext=.mkv handbrake-audiodelay=skip PreConversionCommercialRemover=true
H265 way faster than MP4 normal
Vary the -cq numbers and see if the quality changes.
I did. I pushed it from 25 to 23. Marginally better. I think the vbr makes as much difference as the rest.
via Newton Mail
Try extremes like 5 or 40
I tried 18 and down - at that point there’s a very marginal savings in compression (300 megs on a 1.3gig file). 23 seems to be the right sweet spot for HEVC CQ.
If I understand the concepts here correctly with the last profile listed.
If I make -cq a larger integer, the compression is less efficient (i.e. larger file).
Does it make the encode any faster or degrade the video quality per se?
Yes. That’s right. It’s also a non-linear scale. The bigger the number, the bigger the file. If you know anything about handbrake or h264, cq20 is equivalent to cq23 in hevc. Thanks! Will.
The file is less complex, so it’s marginally easier to encode / decode. That said, you will notice a difference in video quality. If you record a lot of sports, or other fast motion content, you should skew lower. Good luck!