To fully understand hevc_nvenc, you need to google and research yourself, and additionally make many test recordings with different settings and observe different behavior with quality and resulting bitrate at vbr.įor test recordings, I recommend to not use OBS for this. The _hq variants of cbr and vbr are not deprecated, but are variants I didn't explore yet. I also didn't consider any rc modes that are marked as deprecated in current ffmpeg binary builds. I mainly discovered the difference between rc=vbr cq=(value) and rc=constqp qp=(value), which was unknown to me before (where I recommended constqp, which I don't recommend any more). I did research before posting to that other thread, and that posting contains my current knowledge. I cannot tell anything about your perceived difference between vbr and vbr_rc. With all other color formats, OBS needs to copy the frame buffer into CPU memory and copy it again to the input buffer of the encoder. Only with this color format the encoder pulls the raw image data directly from the GPU frame buffer and the raw data never leaves GPU memory. Nvenc is "zero CPU" (actually: zero copy) only, if you use color format NV12. So are these weird scales intentional? Are you supposed to get almost constant bitrates until you reach a certain threshold? Is there another setting besides rc=vbr and rc=vbr_hq that will allow more bitrate variation but without dropping frames? Is it worth trying rc=constqp? Overall rc=vbr_hq uses more CPU power and I get dropped frames just like with the higher vbr cq values. At cq=30 there's more variation, between 13Mbps and 20Mbps. At cq=1 you get 40Mbps and at cq=25 you get 20Mbps, but without much variation. I also did a bit of testing with rc=vbr_hq and the cq= scale is totally different. It still looks pretty good but is visually distinguishable from the higher quality settings.Īt cq=40 you get 4-6Mbps which is starting to look pretty bad but would be OK for some content. The quality is barely distinguishable but there's higher CPU load so with my old 4 core I get some dropped frames.Īt cq=35 it's 6Mbps to 9Mbps! A massive drop. cq=1 to cq=30 basically CBR that will reduce bitrate if there really is nothing to record.Īround cq=33 is where bitrate starts to vary more, it goes between about 12Mbps and 16Mbps, occasionally jumping to 18mbps. The still frame bitrate is what the cq value affects, but even then, the difference is like 5Mbps vs 8Mbps. You get 20 megabits pretty much all the time, and if the frame is totally motionless, bitrate drops. From experimenting recording the same 4K video clip, I've figured out that 1-30 basically produce the same results. 0 is Automatic and the other numbers are a scale where 1 is highest quality and 51 is lowest quality. Also, encoder settings have a big impact on CPU usage, despite the popular belief that Nvenc is totally handled by the GPU.įrom this forum I've learned the basic settings Rate Control Variable Bitrate and Constant Quality number
I figured out the usage by stopping recording and just letting the video play, and it would drop from 95% to half that.
Generally, nvenc hevc encoding uses about half of the CPU power of my 4 core E5-1620V2 Xeon. I have a Quadro T400 with the latest Nvenc chip. My settings are 4K 30fps I444 with 40000bps bitrate, but the encoder ignores that number. I've made some surprising discoveries and I have questions! I've been trying to figure out optimal NVENC HEVC settings for screen recording so I've done some experiments over the past few days with the settings in this doc that Koala posted in the RGB thread
0 kommentar(er)
