2022 年 10 月 25 日（美国时刻）支撑 HEVC 硬解功用的 Chrome 107 已正式开端全量推送给一切用户。10 月 21 日 Chrome 官方在更新日志中做了正式阐明。
这个作业的背面离不开一位来自字节的开源奉献者的尽力，ByteTech 了解到了相关背景，特意邀请了斯杰同学对整件事的来龙去脉作了整理，以飨读者。
为什么说 HEVC 很重要
咱们活在高清时代
HD，蓝光，4K，8K！这些词频频出现在咱们日子中，新型手机拍摄的高清视频，在西瓜，抖音，VR 上观看高清视频和直播，家里的高清监控设备 24 小时录制，这些视频内容的存储和分发都离不开视频编码技能，虽然当前现已 2022 年，可是 Web 渠道干流的编码技能仍然是落后的 H.264 / MPEG-4 AVC(zh.wikipedia.org/wiki/H.264/…) 格局，这种编码方法，假定限制存储 2 个小时的 1080P 视频需求 10 G 左右，而到达相同清晰度的 HEVC 编码只需求 H.264 约一半的体积，那为什么咱们不都用更先进的编码技能？
原因是专利之争！HEVC 视频专利扑朔迷离，不在本文关注重点，可是用户及视频厂商苦之久宜，尤其是作为市场占有率 67% 的 Chrome 浏览器，一直无法在 PC / Android 上支撑 HEVC 视频的播映，作为用户需求忍耐视频加载卡顿抑或是下载运用专门的客户端。
HEVC 即使有专利费用的各种问题，可是在其优异的压缩率下，也取得了较多的进展，尤其是在硬件编解码支撑度上(www.infoq.cn/article/s65…) ，是仅次于 H.264 的编码格局。假如应用运用硬解，由于硬件厂商现已对专利付费是不会有专利危险的。
预期对行业有什么影响？
Chrome 107 这次支撑的硬解是全渠道开箱即用的，由于 Chrome 在国际范围 67% 的市场占有率，以及有许多根据 Chromium 的浏览器，往后，网站能够做到 “有效布置” HEVC 视频内容。
首要是：更低的布置本钱。 关于像 Web 端的西瓜，Bilibili，Netflix 等视频站点来说，包含 CDN 流量费用和转码的费用。HEVC 预期比较 H.264 最多能够节约 50% 的 CDN 流量，关于像直播等场景，也能够削减由于实时转码导致的高额本钱和推迟的问题。
其次是：更好的用户体会。 使 Web “全渠道” + “老机型” 流通播映 8K、HDR 视频成为或许。以 B 站为例，其流量大头的移动端主推 HEVC，不管是杜比视界，8K，HDR 真彩，这些高档特性都根据 HEVC 完成。在之前，由于 Web 端产品没办法操控浏览器内核，即使有十分厉害的 WasmPlayer 软件，可是原理层面就决议了这种计划处理不了超高清视频 CPU 占用高，HDR 支撑差(www.oschina.net/news/189974…
有了 Chromium HEVC 硬解支撑，视频网站在 HEVC 内容布置上会有巨大的提高。
伟人肩上的探究者
为何 Chrome 的 HEVC 缓不济急
倘若如本文所说，HEVC 如此重要 Google 怎么会意识不到，是不是技能完成过分杂乱？大约用脚想了一下答案非也，有部分原因是 Google 在 HEVC 专利之争中没有占有到一席之地，主推 VP9 编码格局，并在 YouTube 中许多运用，以此 “对抗” HEVC，个人猜想 Google 在本身产品中一直把 HEVC 放在低优的战略方位。看 Chrome Release Note 中许多笔者觉得无关紧要的更新，以及众多为支撑 Web HEVC 播映折腾坏了的程序员和公司，有一种在伟人肩上随之摇晃的无力感。
在日子中咱们觉得不合理的作业举目皆是，在这个作业之后，我更意识到了敢想敢做的重要性。
探究者是一名Web 工程师
到此总算要引出咱们本文的主角，Chromium HEVC 硬解功用的首要代码奉献者朱思达。
简略介绍一下作者，2020 年毕业于西安电子科技大学，作为 Web 前端入职字节跳动的内容安全团队，担任桌面端开发，现在在飞书技能团队参加框架跨端开发。而笔者其时作为内容安全团队担任人，正好了解整件作业发展，到 2022 年 10 月，思达在过去的半年多时刻，给 Chrome 奉献了 37 个 HEVC 硬解相关的 Commit，提交了 Caniuse(caniuse.com/?search=hev…) 的修正，并把整个完成进程完好记录了到了 Github(github.com/StaZhu/enab…) 中，一同也撰写了十分详尽的技能文档《8K HDR!｜为 Chromium 完成 HEVC 硬解 – 原理/实测指南》(zhuanlan.zhihu.com/p/541082191…
相同作为技能从业者，觉得这个文章过于硬核，便想到做一个访谈类的文章吧，让更多人了解这件风趣的作业。
思达自述，从事务到开源那些事
是在什么时分开端，有做 HEVC 硬解的想法的？
受限于一些众所周知的原因，从 2015 年到 2022 年今年，Chromium 一直不支撑 HEVC 这个编码格局，咱们有一个桌面端 App 运用 Electron 完成，需求有播映 HEVC 视频的才能。
在 2021 年末的时分，我在其他工区做调研，发现部分同学电脑常常卡顿，CPU 占用到达 100%，快进快退缓慢，体会十分差，叫苦不跌。查验后发现，这部分 1080P 的视频均为 HEVC 编码，由于大部分是直播切片，需求高实时性，无法接受转码，因而一时之间没有办法能够处理卡顿问题（除非换电脑）。
所以我便在网上查资料，发现 H.264 由于是硬解，所以从来没有人觉得卡，而这部分 HEVC 的问题大略是与软解功用差有联系，一同也发现许多业内同行比方 B 站，有遇到与咱们相似的问题，进一步查验发现，PC 渠道只要 Edge 支撑 HEVC 硬解，Mac 渠道只要 Safari 支撑 HEVC 硬解。考虑到 Edge 是闭源的，而 Safari 又是根据 Webkit 内核的，开源国际缺乏根据 Chromium 内核的 HEVC 硬解才能，这厌恶了一切需求用到这个格局的用户、开发者，因而觉得有必要做点什么，让咱们的用户运用体会更好，哪怕代码合不进 Chromium，也必定要分享到 Github，协助用户、开发者处理这个痛点，十分有意义。
怎么平衡事务，假如做不成功会咋样？
最开端做的时分确实压力比较大，也觉得这个东西不太或许做出来，一同由于咱们项目总共大约只要3 ~ 4 个前端做 PC 端（Electron），之前咱们没做过媒体相关的开发，也没做过浏览器开发，其时全体看也觉得这个事比较虚。
虽然如此，可是咱们项目由于一直运用自定义编译的 Electron，因而在编译浏览器这块有必定经历，一同也由于我的搭档斯杰在 19 年时就探究过软解的计划《修正 Chromium 源码，完成 HEVC/H.265 4K 视频播映》(www.infoq.cn/article/s65…) ，他和我的另一搭档光宇都觉得这个事是有技能挑战的作业，没理由不让这个事做的更极致，十分支撑咱们去做，所以就准备做了。
在忙完了手头一些作业后，我计划花 2 ~ 4 周时刻把它搞出来，假如搞不出来就抛弃。所以花了 1 周时刻恶补了下 HEVC，音视频相关的基础知识，然后发现作业量十分大，因而准备先测验点稍微简略但必要的功用，比方给 HTMLMediaElement 扩充了一个几个新的办法《为Chromium完成MediaConfig API – 进程分享》(mp.weixin.qq.com/s/xvz6gJkhp…) ，又花了一周，把这个 Feature 做完之后，客户端新版别上线，也拿到了预期的数据。
知道了 HEVC 的数据，下一步就是测验完成硬解，我和咱们组内的另一个还在实习的搭档豪爽一同测验做这个事，豪爽从魔改 FFMPEGVideoDecoder 方向入手，又花了 2 周左右时刻，发现这个东西能够调到硬解模块，可是由于浏览器沙箱限制，终究魔改失利。
我觉得咱们现已投入的人力虽然暂时没做出来，可是这个进程积累了不少经历，没理由抛弃，然后我就计划模仿 macOS H.264 完成硬解的方法完成 HEVC 的硬解，然后又花了 1 个月时刻，持续掉头发，阅览 VLC 和 FFMPEG 的源码，参阅各种能查找到的文章，靠着各种线索，最终把 macOS 的硬解搞出来了。
功用的开发进程是怎么样的？
首要十分感谢英特尔的 Jianlin Qiu 老哥（注：Windows 渠道 HEVC 硬解奉献者）， 咱们两个究竟是归于 “非官方开发者”，也是有许多的摸索和沟通，这个进程我也和 Jianlin 学到了许多。
在 2020 年末，Chrome 的 Jeffrey 就现已把 Chrome OS 的 VAAPI 硬解完成好了，因而 H265 Decoder 和 H265 Parser 开始根本都是 Jeffrey 写的，可是一直没默许启用，状况也比较不明朗，没啥人用，没经受过群众的验证，这部分代码就这么放在了 Chromium 库房大约 1 年半。
方才也说到，我是在一月份就开端测验完成 macOS 硬解的，macOS 的搞好了又测验按照 Edge 插件的方法去完成 Windows 硬解，可是遇到了些大坑没处理。
然后在 2 月份发现 Jianlin 把 D3D11VA 硬解的才能合进去了，Jianlin 算是第一个吃螃蟹的人，作为这次 Windows 渠道 HEVC 硬解的开发者，Windows 渠道的 H265 Accelerator 代码是他 1 月底提交到 Chromium 的，其时 Media Team 的情绪是，这个能够合，可是：代码不能包含在 Chrome 内；默许也不允许启用。没有人知道这个功用究竟有没有或许在未来问世，但我都觉得这现已很好了。
究竟自己编译代码 + 手动启用开关仍是能够能用这个功用的，至少未来不用处理抵触了，所以看到 Jianlin 的提交后也有决心了，在 3 月初把手头写好的 macOS 渠道的代码也提交了上去，然后就是不断完善，到了 4 月份，这个功用根本能用了，我就在 Github 建了个库房(github.com/StaZhu/enab…) ，用来做一些注意事项和状况同步的作业，期望协助到开发者和需求这个功用的用户。
到了 5 月份，得到了个大好音讯，允许代码被包含到 Chrome 内了，这里我的猜想是 Media 团队也看到了 2022 年这个格局越来越占有重要作用，众多开发者被逼的力不从心（许多开发者在用 WASM 计划，Chrome 其实也在推 WebCodec 计划，期望把 WASM 的场景替换掉），以及既然咱们都把代码完成了，也没什么理由不让他面向群众。另一方面是咱们的完成是纯硬解，无软解部分，也就是说没有什么版权危险，究竟解码才能是操作体系提供的，硬件现已交过专利费了。
虽然默许是禁用的，可是用户能够手动传发动参数发动，因而后面咱们在 8 月份用的 104 正式版，测验这个功用都是经过手动传发动参数搞定的。
然后在咱们搞完这三个渠道后，Chrome 的 Ted 老哥把 Android 的也搞了，由于 Linux 和 Chrome OS 共用的 VAAPI 代码，所以就这么把全渠道都支撑了。
有了群众基础 + 许多网友（大多数都是真发烧友！）参加测验，提供了许多宝贵的反应建议，在测验进程也发现了不少小问题，并一一处理了（包含 WebCodec 支撑，开始遗漏了这个 API，107 才补上，PS: Jianlin 奉献这块的代码），一同反向处理了 Edge HDR 颜色反常的问题，因而网友也是开发进程的一个首要部分。
整个 8 – 10 月份，我俩根本都是各种为 Windows，macOS 这两个渠道搞了一些修修补补的作业，为终究问世去完善，包含怎么让检测是否支撑硬解，最大分辨率是多少的接口 (navigator.mediaCapabilities) 更准确，怎么让 HEVC with Alpha 作业，怎么处理 Intel 12 代核显开 HDR 溃散，怎么处理 HDR10 元数据提取不到等问题。
遇到的最困难的问题是什么？
最大的困难或许是功用前期的测验阶段的痛苦。为了验证功用的安稳性，咱们在内部有一个 200 人左右的群，由于硬解哪怕有一块逻辑，或字段传错，轻则视频花屏，不能播映，重则 GPU 进程溃散，因而在测验前期遇到了部分用户溃散的问题。
咱们就遇到了一个问题，那个视频存在分辨率突变的状况，然后这种状况在初版完成是处理不当的，没有从头创立解码器，终究导致了 GPU 进程溃散，用户会质疑为什么他们之前用的好好的，现在要切过来当小白鼠，我只能给他们暂时切回旧版，再许诺新版修好，总有种对不起用户的感觉。
还遇到过一个躲藏十分深的 Bug，问题源于对 ref_pic_list0, ref_pic_list1 这两个字段的了解不正确 ，终究视频解码的具体表现就是花屏，花屏与咱们平常的 Debug 逻辑不相同的是，它不会产生任何报错信息，其时是把一切 h265_parser, h265_decoder, h265_accelerator 的逻辑都重复看 N 遍，没有什么好办法，后来一点点对照着 FFMPEG 写好的 D3D11 解码逻辑看（D3D 加速的参数传递是共同的），由于二者的解码逻辑没什么相似之处，字段名也不太共同，这个问题看了接连 3 天，终究处理了这个问题。
在内部实验进程中还发现，关于硬解来说，需求占用必定量的显存，咱们在写逻辑时，假如一个 video 标签在完毕播映后没有将 src 重置空，直接移除 video 标签，会导致显存不开释，这关于 N 卡来说不会有问题，N 卡有兜底处理，可是到了 I 卡这块，显存用多了会导致 Context Lost，进而使 GPU 进程溃散，其时一度以为是咱们自己的代码写的有问题，结果后来发现是 GPU Driver 鸿沟 Case 处理的问题。
其他的问题，比方咱们之前的完成是用 JS 库，或许在一些当地处理的不是很好，由于软解具有比较高的容错才能，所以 JS 库在之前软解版别是没啥问题的，但由于硬解对数据内容的要求更高，相似的问题在初期担任 JS 库开发的搭档处理了 3-4 个后，才逐渐安稳，让 JS 库与 Native 硬解磨合本身也是个杂乱的进程。
另一个稍微有点痛的点是由于和美国有时差，常常要深夜起来和 Reviewer 处理 Code Review 的问题，改代码。当然也能够拖到第二天再回复，但那样一个 Commit 或许来来回回要 3-7 天才能合入，为了提高功率，常常深夜起床回音讯改代码，好在我睡觉质量十分好，Review 完能够很快持续睡着，就这样，这个进程持续了大半年。
在完成上自己比较满意的点？
根本不输给 Edge 和 Safari，各项目标和安稳性都到达了预期的水平，并在格局支撑上比他们更好。
终究效果上，与 Edge 首要的不同点是不需求装 HEVC 视频扩展插件，由于 Windows 是直接用的体系 D3D11 的才能，而 HEVC 视频扩展（Media Foundation）不是每个人都会装，且在微软官方商店是收费的，许多小白用户各种不会装，具体能够到网上查找相似的教程，十分多，这个十分不利于视频网站大规模布置 HEVC 视频。另一方面是 HDR 视频的显现，Chrome 比较 Edge 在处理 PQ 和 HLG HDR 时，不管在 SDK 显现器或 HDR 显现器都能很好的进行色调映射。
与 Safari 的不同点或许是比较少的，由于 macOS 的硬解框架就一个 VideoToolbox。在才能上平分秋色，Safari 还支撑杜比视界 Profile 5，咱们还不支撑，但 Safari 现在十分 “挑格局”，许多 mp4 视频无法直接播映，且还不支撑 WebCodec API，而 Chromium 现已能够支撑的很好了。除此之外，二者都能够很好的以 EDR 方法显现 HDR 视频内容，且都能够支撑杜比视界 Profile 8，HEVC with Alpha。
这次的版别还有哪些其他风趣的才能？
- 在 Chrome 107 版别，支撑了 HEVC Rext Profile，换句话说就是在支撑硬解 Rext 的渠道：比方运用 Apple Silicion 的 macOS，运用 Intel 11 代及以上核显的 Windows 渠道，使 Web 渠道做 HEVC 10Bit 422 剪辑至少现已成为了或许！
- 在 Chrome 107 版别，首次为 WebCodec 支撑了 HEVC 8Bit 的解码！ ****这能够给开发者许多空间去运用 HEVC 硬解做许多灵活的才能。
- 在 Chrome 108 版别，支撑了 10Bit 以上 HEVC WebCodec 解码，至此 WebCodec 可用功用够到达与 MSE API 根本共同的程度（虽然现在Canvas HDR 支撑的还不够好） 。
- 在 Chrome 108 版别，macOS 渠道支撑了 HEVC with Alpha， 假如想烘托带透明度图层的视频，之前是只能选择 VP9 with Alpha 的方法，HEVC with Alpha 比较 VP9 with Alpha 有两个首要优势：支撑硬解，功用更好；支撑在 WebCodecAPI解码时保存 Alpha 图层，是 WebCodec API 下首个支撑保存 Alpha 图层的编码格局（VP9 不支撑），关于 Web 动画广告场景，HEVC with Alpha 或许是个好主意。
Chromium 开发有哪些感受能够分享？
Chromium 成为国际范围最受欢迎的浏览器内核不是没有原因的，这里按我的了解，首要是 Chromium 开源的机制，一切的第三方开发者与 Google Chromium 员工相同，都能够享用良好且安稳的开发体会，比方代码编译，查找，提交，这是其成功的最首要基石 – 群众基础。当第三方开发者提交 Commit 数大于 10 今后还能够申请成为 Committer，并具有 CQ Dry Run，Code Review +2 ，Assign Crbug 等其他 Project Member 权利。
然后是完善的版别发布策略，Chromium 以 Milestone xxx 作为版别号，大致上一个月新增一个版别，开发版别与线上版别有大约 1 个半月的代差，也就是说开发者有足够的时刻在浏览器问世前处理遗留的 Bug，并以 Cherry Pick 的方法将 Hot Fix 说到 Branch Cut 后的 Milestone 版别上。
其次是完善 + 极端严苛的 Code Review 机制，Chromium 的 Code Review 全体上十分严厉，Chromium 开发者大部分都十分严谨，为 Chromium 项目作业 10 年以上的 Google 员工举目皆是，大都经历充沛，仔细担任，对技能有极致追求，为我 Review 代码的 Dan Sanders, Dale Curtis 都十分仔细，且为 Chromium 作业至少 10 年了，他们对 Web Media API 的透彻了解令人震惊。
最终是 Chromium 的测验机制，Chromium 没有 QA，大部分测验均依赖研制自己的写 Unit Test，咱们都能很好的恪守其机制，根本上每一块逻辑都有 Unit Test 掩盖，Chromium 每个操作体系的不同版别都有许多 Test Runner，24 小时不间断定时跑测验用例，Chromium 会有 Sheriff(www.chromium.org/developers/…) 来监控测验用例失利的状况，并及时Revert 掉导致 Unit Test 失利的代码。Chromium 相同要求有 Fuzzer Test 掩盖，以及有许多内存自动监控的测验 Case，会自动创立 Crbug，将有溃散或功用退化或许的 Commit 通知到开发者，全体看 Chromium 的开发流程十分的完善 + 标准。
后面有什么计划？
- 现在 HEVC with Alpha 渠道的完成，运用 RGBA format 烘托，还不是他能到达的最佳功用状况（存在 YUVA 到 RGBA 的转换损耗），因而近期会为他完成 NV12A (NV12 + Alpha)支撑，这样大约还能提高 66% 左右的功用，到达与 Safari 共同的功用水平。
- 持续为 Windows 渠道做 HEVC with Alpha 完成，虽然 D3D11 现在的设计完成这个功用或许会比较杂乱，可是理论上仍是能够依靠调度去做这个作业的。
- 持续提高 HDR Tone Mapping 的功用，一个是现在 Windows 渠道的代码途径还不是 Zero Copy，解码时显存会占用比较多，Zero Copy 支撑后 HDR -> SDR 会降低大约 50% 显存占用，再一个是现在 Canvas 绘制 HDR 内容颜色仍是存在问题。
- 背靠 Jianlin 大神，把 macOS WebCodec 编码也搞上去，至少让 WebCodec 在干流 PC 渠道 HEVC 编码成为或许。背景：Jianlin 最近一直在做 Windows MF HEVC 硬件编码的作业（现在代码现已合入 M109，Windows 渠道编码经过 Chrome Switch 的方法现已能够运用了）。
有必要一同做点什么
经历并目击了整件作业，从事务的问题处理，到技能攻关，开源奉献代码，最终在更大范围内给社区带来了便当，这里边个人才能固然十分重要，除此之外也有几个感悟给咱们分享。
- 决心很重要。思达在作业中有许多打破，这些逐渐累积起来的决心，在进程中起到了强烈的心思暗示协助打破一层又一层的困难。在决心之上，是对细节完美追求执着的情绪。笔者在这两点上也经常做自我暗示并受益匪浅：在一个劳累的晚上本想偷个懒，但另一个声音告知自己，你写的啥玩意自己都看不上，优化优化吧，而后者正好是协助成为更好自己并建立决心的一个途径。
- 第一性原理。与现状是什么样比较，这个作业理应怎么更为重要，咱们应该朝着理应怎么的这个方向前进，这决议了咱们的天花板。笔者团队的客户端小组当初对打破 Chromium 内核完成硬解的计划是十分共同和清晰的，所以咱们敢顶住事务压力去投入（首要仍是思达说了这事能够~）。更为保险的是网上常见的 WASM 软解计划，或许不会有人质疑你的决议计划，但我觉得在一个过错方向去折腾太无趣。
- 但行好事，莫问前程。找到方向尽量试试看，失利了也没关系。尤其对团队的管理者而言。就这件作业，产生在笔者所在的团队，咱们不是 Chrome 的 Media Team，不是公司里边视频架构团队，没有资深的视频编解码和 C++ 范畴的大神，凭什么就打破了，我觉有一点就是敢做。
从概率上看，咱们在日常作业中大部分精力和时刻，或疲于应对常态化岗位职责，或处在庞大杂乱的体系架构中找不到关键的打破口。相似 HEVC 硬解完成这种跨范畴推进的作业还会产生更多，找到确定或感兴趣的方向，及时行动起来，找到更多志同道合的人一同前进，有必要能够一同做点什么的。
