One thing I noticed when comparing x264/x265 to Nvidia counterparts is the Nvidia encoder tended to get rather ugly in the chroma as you leaned towards smaller files a lot sooner than x264/x265 would, and not by a small margin. During tests where I was using VMAF results to compare I could get files from each encoder to have the same VMAF score but the Nvidia file would look much, much worse. Could even contain very nasty macroblocking that nobody would overlook, not even laymen with no video encoder knowledge at all because it was so bad and so obvious, but the x264/x265 file with the same VMAF score would look way better. Then I re-read the VMAF docs again and noticed that it only examined luma, and I was surprised I missed that the first time I had read through. So the Nvidia encoder seemed to be focused on luma quality a lot more than chroma, and the amount of corner-cutting they were doing in the chroma department was glaringly obvious. I think for video game streamers it is a very nice thing to have, an encoder that uses none of their CPU, but for nearly all other uses it is probably going to be better to spend a bit more time doing a CPU encode, as it is possible to get much better results with fewer bits.
On Sat, Aug 6, 2022 at 11:11 AM jatmvp ctf <[email protected]> wrote: > Thank you all for your responses!!! :) > > Thank you Gabri Shally, and I must say that I was both surprised and > astonished too, about those quality score and size output. > I thought quality goes in pair with size. I got quality 36 (higher is > better, yup?) on libx265 and it looks better when I watch it, and 19 > (lower) hevc_nvenc. The size is smaller when achieving higher quality... > Maybe this depends on many "static" scenes (where only little of picture is > having non-zero spatial differentiation of picture) and the encoding > algorithm indeed! Or CPU capabilities (I have quite decent CPU I think..) > If so, I would then stick and always use the CPU version because of this > 2-4x penalty of encoding time is nothing in comparison of output size and > quality I get :) Good job and kudos for everyone who was involved in > achieving this in ffmpeg code! :) Not only getting great output (metered > for quality and data density), but also while low latency preparation on > decoding is set up. > > It is probably related to some things Clayton Macleod said about encoders > are not standardized as well as decoders are (and as I understood, they do > not have to, so why :) ), the setup of nvidia encoder I not have made maybe > (or not available on Windows platform nowadays - would find ) with > comments from Mick Finn (would read doc, thanks!) & Harald Reindl, and some > issues about which David Stephen wanted to tell, but the response of the > last FFMPEG User I've mentioned is not yet understood by me well I think, > but still David thanks for your input and understood your emotions between > OSS and closed /proprietary one. > > I use the msi manufacturer RTX 3080, supplied from a stable power source > with 3 independent power lane sockets, so should be okey. Should I attach > the version of GPU always here? :) > Sorry for not mentioning it earlier, I read some messages here, but I have > a lot of knowledge to assess :) > > I take your point Clayton Macleod, and thanks for elaboration on this. I > think that was also what Harald Reindl wanted to tell me but I was not > knowing about nVidia encoder goal "in mind". Must rethink and would test + > query if have other ideas/results/benchmarks (maybe helpful for someone) to > share. > > Also, thanks Harald Reindl for sharing your look on my interpretation and > ease on my (not to-the-point) valid assumptions. > Of course, I agree implementation (code) is highly different as for CUDA > cores and the whole GPU ecosystem processing is done differently than on > CPU + RAM + MB, and they are different in architecture, silicon et al. > Would learn more before asking next things. > > btw. I seen many of you run it not with cuda nor dxva2. > Mine available are "Hardware acceleration methods: cuda dxva2 d3d11va" > Is that bad? I cannot find nvenc/nvdec there > > Any sources I should read from begin to end you think? Or some ffmpeg code > source part? > > Really appreciate any further and presented help! :) > > sob., 6 sie 2022 o 13:21 Gabri Shally <[email protected]> napisał(a): > > > on both command, you didn't give any option about bitrate or quality > > target, so the implementation may freely choose those. > > > > if you see output near the end, nvidia give quality of 19 while libx265 > > give 36, so the size would be different wildly. > > _______________________________________________ > > ffmpeg-user mailing list > > [email protected] > > https://ffmpeg.org/mailman/listinfo/ffmpeg-user > > > > To unsubscribe, visit link above, or email > > [email protected] with subject "unsubscribe". > > > _______________________________________________ > ffmpeg-user mailing list > [email protected] > https://ffmpeg.org/mailman/listinfo/ffmpeg-user > > To unsubscribe, visit link above, or email > [email protected] with subject "unsubscribe". > -- Clayton Macleod If no one comes from the future to stop you from doing it, then how bad of a decision can it really be? _______________________________________________ ffmpeg-user mailing list [email protected] https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email [email protected] with subject "unsubscribe".
