Hacktoberfest 2026:维护者为十月标记出来的 issue,仍然开放、适合新手。 浏览 Hacktoberfest issue

Update Performance article with new codecs like AV1 and observations on newer hardware.

未关闭
#154 2 条评论 0 个 reaction 已指派 1 人 在 GitHub 查看

@bradleysepos 已经在做这个了。

开始于 2026年9月29日。

评估

难度
5/5
预计耗时
一周以上
新手友好度
35/100
Issue 类型
文档
描述清晰度
基本清楚
活跃度
停滞
技术栈
markdown

调研方向

首先阅读 performance.markdown,并将其中的质量比较表和硬件编码器指南与提供的 VMAF 结果、Netflix VMAF 项目以及链接的报告进行比较。完成的标准是就刷新范围达成一致,并更新文档中的比较内容以及关于硬件加速编码的表述。

由索引模型根据 Issue 内容生成。

描述

Improvement

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 min[^1] VMAF max[^1] VMAF mean[^1] VMAF harmonic mean[^1] 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 min[^1] VMAF max[^1] VMAF mean[^1] VMAF harmonic mean[^1] file size
00:29 min 84.678945 100.000000 98.965836 98.947771 490'314'770 Bytes

[^1]: higher number is better. Maximum value is 100.

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.

主要语言
Shell
星标
268
派生
103
平均合并
9 天 5 小时
30 天内合并 PR
1

环境准备

  • 没有 Dockerfile 或 Docker Compose 文件
  • 没有 Pull Request 模板
  • 阅读贡献指南

从这里开始

  1. 先读完整个 Issue,再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库,在一个分支上完成修改。
  4. 提交 Pull Request,并在描述里引用这个 Issue 编号。

HandBrake/HandBrake-docs 的其他 Issue

查看 HandBrake/HandBrake-docs 的全部 Issue

相似的 Issue

更多 Shell/Bash Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。