Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

performance.markdown should get a refresh (Rework? Retry?) #154

Open
boessu opened this issue Jan 11, 2022 · 2 comments
Open

performance.markdown should get a refresh (Rework? Retry?) #154

boessu opened this issue Jan 11, 2022 · 2 comments

Comments

@boessu
Copy link

boessu commented Jan 11, 2022

First things first: The handbrake site about performance is the most serious and best site I know which deals with this subject quality vs. performance. It should be keeped alive. It just seems to me it should get a rework in 2022 as there happened something serious in this area in the meantime.

Issues:

Quality comparison:

Netflix gave us all a tool into our hands to make a serious and comparable assessment of the results: https://github.com/Netflix/vmaf. The tests should be compared with that, resulting in comparing numbers instead of visual opinions with magnifiers. So the site should add a column to all tables, just to show how far or near the result is from the source material.
That could be even very easily included in Handbrake as a library, but that would be an enhancement I'm not sure if it would be useful in the sense of the Handbrake as transcoder or not.

Hardware accelerated rendering:

That part seems to be fairly actual (e.g. GTX 1060), but it seems that at least the nvenc part should get another try with a Turing chip (RTX) in 2022. Beside of the marketing yaddayadda by Nvidia you'll find too, this report here has some surprises in it: https://youtu.be/ccoOGfX9qxg

Handbrake is not streaming. So what does that mean for Handbrake transcoding and is that worth a serious try? A short check of tears_of_steel_720p.mov with my RTX 2070 Super gives me the following results:

CPU: HQ 720p30 Surround (Modified: BpS same as source with x.264):

render time VMAF min1 VMAF max1 VMAF mean1 VMAF harmonic mean1 file size
2:41 min 83.984472 100.000000 98.063116 98.020935 276'968'288 Bytes

GPU: HQ 720p30 Surround (Modified: BpS same as source and H264 nvenc):

render time VMAF min1 VMAF max1 VMAF mean1 VMAF harmonic mean1 file size
00:29 min 84.678945 100.000000 98.965836 98.947771 490'314'770 Bytes

It seems as Nvidia did something very serious in the quality apartment of the Turing chips. Mainly for the streamers, but we also get some benefits here. The sentence "Hardware encoders are typically much faster than software encoders, at the expense of some loss in quality and/or larger file sizes." should be more precise: the file size of x.264 is still remarkably smaller (that part keeps true, as it seems) but the quality outcome of x.264 is even a bit less than the result of nvenc with the same quality settings. Nothing on the page actually goes in that direction. I think, to be fair for Nvidias effort to get better there (and maybe other hardware accelerated solutions too): You do not have to expect a loss of quality if you have the right hardware. You get bigger files, that seems to be always true.

Footnotes

  1. higher number is better. Maximum value is 100. 2 3 4 5 6 7 8

@sr55
Copy link
Contributor

sr55 commented Jan 11, 2022

A lot of the documentation pages need a refresh. It's on the to-do list along with a million other requests :)

with the same quality settings.

x264 RF 20 != CQ 20 NVEnc
Different encoders, different rate control and other capabilities.
It's non-trivial to control quality for stats purposes.

While this will vary source to source, in the above example, you might find that the delta filesize isn't as large as you've shown when quality is better controlled.

@bradleysepos
Copy link
Contributor

Thanks for the kind words. Indeed, it's on my list to revise the performance doc with more data and newer hardware as well.

I hadn't previously considered using vmaf but it's a possibility. Despite being in the technical section of the documentation, the docs as a whole are intended to be accessible to normal humans, so visual comparisons can often be helpful.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

3 participants