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=trueVary the -cq numbers and see if the quality changes.
Det gjorde jeg. Jeg skubbede det fra 25 til 23. Lidt bedre. Jeg tror, at vbr gør lige så stor en forskel som resten.
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!
Så først og fremmest, fantastisk H265-profil – den klarer sig rigtig flot med et Quadro-kort som hardware-koderkilde!
Dernæst har jeg leget lidt med denne profil og forsøgt at lave en H264-udgave af den dedikerede encoder ved hjælp af ffmpeg, men jeg har haft nogle syntaksproblemer med at få den til at køre. Er der nogen som helst chance for, at du/en anden har eksperimenteret med det?
Baggrunden for ønsket er at skabe en hurtigere profil med konstant kvalitet til udsendelser, der ikke kræver langtidsopbevaring – som sport, Jeopardy osv. – som kun skal ses én gang, måske to, og derefter forsvinder for det meste. Det skal spare tid på den daglige omkodning i forhold til langtidsopbevarede filer som tv-serier, film osv.
Tak – jeg forstår fuldt ud frustrationen ved at forsøge at dekode ffmpeg-kommandoerne – dokumentationen er… knap.
Du skal erstatte HEVC_nvenc med h264_nvenc. Husk, at den konstante kvalitet er forskellig mellem 265 og 264. Standardværdien for 265 er 23, mens den for 264 er 20.
Håber det hjælper! WIll.
Tak, makker, jeg prøvede det, men det faldt tilbage til handbrake-cli-muligheden uanset hvordan jeg vred syntaksen. Jeg læste en masse i den, som du siger, knappe dokumentation – hvilket bestemt passer! – og fandt en masse info om mulighederne for h264_nvenc-koderen, som viste sig at være anderledes end dem for HEVC-koderen i de nuværende version(er) af ffmpeg.
Jeg kan smide en kopi af nogle test-profiler op i morgen, når jeg får tid, hvis du har lyst til at hjælpe med fejlfinding for at få profilen til at virke. Lige nu er jeg afhængig af ændringer af de indbyggede h264-profiler baseret på libx264-koderen, som bestemt kan bruge HW-acceleration, men jeg vil gerne bygge én udelukkende på HW-koderen – à la den du lavede til HEVC.
Vil gerne forsøge at hjælpe. En ting at starte med er at åbne en kommandolinje og køre “FFMpeg.exe -codecs”. Det vil vise, hvilke codecs der er tilgængelige for dig i FFMpeg.
For Handbrake-fallbacket ved jeg, at nyere versioner af Handbrake understøtter nvenc, men jeg er ikke sikker på, om handbrakecli.exe bare kan udskiftes. Vil grave lidt mere i det.
Tak! Will.
Tak skal du have, sætter pris på det,
Angående Handbrake-fallback’en, så understøtter den nyeste version af GUI-versionen faktisk NVENC – med rigtig god performance, skal jeg hilse og sige! – men fallback’en henviser til ren CPU-baseret x264-kodning uden nogen form for hardware-acceleration.
Jeg henter flere detaljer i morgen og tester også nogle kommandolinjeindstillinger.
Tak!
Opdateret: (må ikke skrive mere end tre svar i samme tråd som ny bruger 
)
Så jeg fik syntaksen til at virke; tror, jeg var for træt til at få den rigtig på plads fra start. Men sådan her fik jeg det til at køre ved simpelthen at gøre, som du sagde: erstatte HEVC med h264 og lade resten stå uændret:
[MKV H264 NVENC Constant Quality]
Description=nVidia H264 NVENC Constant quality, varible bitrate
order=ffmpeg, handbrake
AllowH264CopyRemuxing=true
FixedResolution=true
AutoDeinterlace=true
ffmpeg-UsingHardwareEncoding=True
ffmpeg-general=-threads 0 -hwaccel auto
ffmpeg-video=-ss 9 -c:v h264_nvenc -cq 27 -rc vbr -map 0:v
ffmpeg-audio=-acodec libfdk_aac -ab 128k -map 0:a
ffmpeg-audioac3=-acodec libfdk_aac -ab 320k -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
Det kører glat med NVENC som primær encoder.
Et spørgsmål: kender du syntaksændringen for konstant bitrate i stedet for VBR og kvalitetsbaseret analyse? Jeg har et par scenarier, hvor jeg gerne vil styre bitraten manuelt.
Du kan downloade version 1.2 af handbrakecli her: HandBrake
Den integrerer nvenc_h264 og nvenc_h265. Prøv måske at få Handbrake til at gøre det samme…
Så jeg har testet HandBrakeCli med den opdaterede version, og det virker med NVENC – har du nogen viden om mulighederne eller om det er muligt at henvise til en eksporteret .json-fil til konfiguration via MCEBuddy-profilerne?
Du skulle kunne give den en eksporteret json-profil fra Handbrake. Jeg ville justere de indstillinger, du ønsker, og derefter prøve den forudindstilling.
Det ser ud til, der er en mulighed for --preset-import-gui, som netop burde gøre det 
Hey mand, dokumentationen til HandBrakeCli er så meget bedre og lettere at arbejde med end for ffmpeg
Jeg har leget med indstillingerne og opnået ret gode resultater med H265.
Da jeg skal håndtere mange interlaced video-kilder fra vores kabelkanaler, har jeg været nødt til at tweake det til decomb’ing og finde den rette balance for NVENC-motorerne på mine forskellige kort og CPU’er.
Denne profil giver mig cirka 90 % motorydelse på en I7-8700K med et nVidia 1060 GPU, hvor CPU’en tager sig af decoming og NVENC-motoren står for al videoencoding mellem 240 og 300 fps med fuld CPU-belastning til filtre; fjernes filtrene, kan den skubbe frameraten op over 400
Samme profil på en I5-8400 med nVidia Quadro P400 encoder omkring 190-250 fps; uden filtre når den op på 300+
[Handbrake Cli 1.2.0 H265 - Quality 28] Description=nVidia NVENC HW (H265) Quality Setting 28 + Decomb order=handbrake FixedResolution=true PreConversionCommercialRemover=false UniversalCommercialRemover=false handbrake-general=--loose-anamorphic --comb-detect=fast --decomb=mode=7 --verbose=2 --format av_mkv --subtitle 1,2,3 handbrake-video=--start-at duration:0 --encoder nvenc_h265 --encoder-preset slow --encoder-level 4.1 --quality 28 --vfr handbrake-audio=--aencoder copy:aac --audio 1,2,3 handbrake-audioac3=--aencoder copy:ac3 --audio 1,2,3 handbrake-ext=.mkv handbrake-audiodelay=skip
Skubber du NVENC-presetten til medium, vinder du kun lidt fart med filtre slået til, fordi CPU-belastningen er flaskehalsen; teoretisk kunne du køre en separat encoding uden decomb’ing for at udnytte den ledige encoder-kapacitet; fjernes filtrene skubber 1060 frameraten op over 550, P400 op over 400
Overvejer at udstyre I5-8400’eren (Plex-serveren, som på sigt skal klare alt arbejdet) med et P2000-kort for de ubegrænsede encoder-streams til live-transcoding af live-TV samtidig med, at MCEBuddy klarer backend-encoding.
Hej Anders,
Jeg opnår omtrent samme ydelse på mit udstyr, selvom din processor er lidt nyere. Jeg vil lege med det Handbrake-profil, du delte – tak!
Jeg kører MCEBuddy og Plex Server på samme maskine – en i7 7700 med 16 GB RAM, et GTX 1060 og en SSD. Den eneste eksterne ressource er NAS’en, hvor jeg gemmer alle mine Plex-optagelser og -medier. Den opsætning fungerer fint for mig – i HD tager det cirka 10 minutter at kode en times program med den profil, jeg delte. Pladsbesparelsen med H265 er fantastisk.
Jeg brugte en Core i5 førhen – men opdagede, at hyperthreading havde ret stor indflydelse på den samlede ydeevne. Det sagt, var det før PMS havde HW-acceleration indbygget – det kan være muligt at bruge en svagere CPU nu, på nær ved deinterlacing/decombing.
Tak for delingen!
Will
Mail](Outlook) til Windows 10