In other words, human eyes can perceive "better looking" an image with lower PSNR/SSIM than another with higher values. However, human (spectators) "good looking perception" is unfortunately not as simple as these PSNR and SSIM function. can be tweaked to minimise these "mathematical functions". Encoding goal is obviously to have the smallest encoded file, meanwhile staying the most identical to the source.Encoders like x264/265/etc. if PSNR = 100 or SSIM = 1, then the two images (source vs encoded) are identical. The following explanation is my own take, and does not pretend to be 100% accurate, educate yourself and do your own research.PSNR and SSIM, are, "mathematical quantifications" of how identical, two images/frames are. Thanks to Neon_Overload in comments, let's remind quickly some points. So first take out, is that SSIM, PSNR and VMAF are not consistent within each-others.For example, to get a same PSNR (~40.5) between x265 and NvEnc, you need to go from 4.84 to 8.86Mb/s (183%). So let's now have a look how quality change relative to bitrate, which is a bit more relevant: Any RF smaller than 20, won't give you any better quality, all SSIM PSNR and WMAF are unanimous on this point. On the other side, trying to increase quality with Nvidia encoder is not effective past RF ~20. What is your call for SSIM and PSNR? Do you have any specific target? It is consistent with what google tell us about VMAF:"Real Networks wrote a white paper in the subject and they found that VMAF 93 is a good value to target, but everything with an average over 90 will look good." Handbrake guidelines recommend an RF factor between 22 and 28 for UHD content (for x264/x265). For sure it will vary depending on your source file. So, these 3 graphs are more to target a proper quality depending on selected constant quality factor. Encoding quality vs handbrake RF factor.What we can otherwise learn is that RF factor has no incidence on encoding speed with NvEnc We already knew that NvEnc is quicker than x265, but we will need these numbers later. x265 is has a much wider range and progressivity. So as we can see, Nvidia h265 encoder tops around ~19Mb/s for a RF factor of about CQ=19.
No special encoder tune (none), neither profile (auto) or level (auto) for neither encoder (x265 as NvEnc). h.265 10-bits encoder was set at "Slow" preset as it is my current 'sweet-spot' for archiving with x265.This is what I took from Handbrake online documentation own data:įrom my perspective, marginal bit-rate increase (correlated to quality?) past \"Slow\" pre-set for x265 _ Samsung wonderland HDR, 3840 x 2160, 994 MB, 2m41sec, HEVC 51.4 Mb/s, 10 bits, 24fps.Īs attend is clean archiving, NvEnc is set to "Slowest" pre-set to give it the chance of best quality output. _ Win10, Handbrake 1.5.1, FFMetrics 1.3.1b2 (big respect!), vmaf_v0.6v1, mean pooling Question was, whenever I could trade some reasonable amount of space (bigger end file), with similar/comparable quality, but with much quicker encoding. Goal intended is family movies on NAS archiving, done so far by CPU x265. The following post is not intended to be seen as the absolute bible, just to give an idea for those who would be interested.
0 kommentar(er)
