OBS 27.2 发生了什么：传奇修补程序的故事

那是疯狂的一周。让我们谈谈 27.2 发生的事情以及过去一周我们必须做的事情。

在 Windows 版本 27.2 中，我们更新了所有依赖项。依赖项是由外部源代码构成的库；不是 OBS 源代码，但 OBS 依赖于主要功能和特性的东西。有时这可能是软件 H.264 编码之类的功能，它依赖于 x264 编码器库，或者是浏览器源之类的功能，它依赖于更大的依赖项：Chromium（为 Google Chrome 提供支持的浏览器引擎）。更具体地说，浏览器源利用 Chromium Embedded Framework (CEF) 将网页呈现为源，或将网页呈现为 OBS 内部的面板。

在 Windows 上，在 OBS 27.2 之前，我们的浏览器卡在 Chromium 版本 75 上，因为我们必须使用复杂的自定义 Chromium 补丁才能以合理的性能使用它，并且该补丁与新版本不兼容。Chromium 75 到 27.2 已经快三年了，从那时起，Chromium 中添加了许多重要的功能和变化；流叠加和高级制作显示等现代制作组件所必需的功能和更改。它变得非常过时，所以不用说，我们将 Chromium 作为依赖项进行更新是当务之急，这要感谢 OBS 项目成员 Pat、Dillon、Matt、pkv 以及一些出色的贡献者的努力Chromium Embedded Framework，我们终于能够将其更新到版本 95。

然而，更新依赖项，尤其是大型依赖项，可能会带来一些挑战：在 27.2 版本期间，我们开始收到零星的报告，称人们的整个计算机都死机了，需要完全重启系统。我们立即开始调查，起初我放慢了速度，然后随着更多报告确认该问题，最终恢复了 27.2 的发布。在 27.2 之后的第一天，我们疯狂地试图找到受影响的用户，他们有耐心让我们检查并了解发生了什么。幸运的是，我们找到了一些非常善良的用户，他们能够在系统冻结期间强制蓝屏并生成系统内核的调试转储文件。这让我们得到了正在发生的事情的第一个提示：这很可能是图形驱动程序中的错误。我们注意到它以图形操作为中心，而且只发生在一家图形卡制造商身上。幸运的是，我们与所有主要的显卡制造商都有联系，因此我们立即与他们联系以提交驱动程序错误报告。

由于我们无法指望显卡制造商及时调试和修复可疑的驱动程序错误，更不用说用户在发布后的任何合理时间内更新到这些驱动程序，我们别无选择：要么找到很快就会有一个解决方法，或者将 Chromium 恢复到版本 75。考虑到在这个更新中花费了很多精力来更新 Chromium 以改善用户的流生产功能，将 Chromium 恢复到 75 不是我想要的选择。我必须做点什么，很快，因为 Twitch 在两周内弃用了他们的 v5 API，这意味着旧版本的 OBS 将无法再使用 Twitch 的“连接帐户”功能。

OBS 的贡献者 R1CH 找到了重现系统冻结的方法：添加一堆非常活跃的浏览器源，并以 1300/1 分数帧速率（即每秒 1300 帧）运行 OBS。这成功了，我们现在能够自己重现问题并更轻松地调试它。在调试蓝屏内核转储时，我立即怀疑问题可能是由 IDXGIKeyedMutex API 触发的。该 API 用于锁定和同步系统上两个不同进程或线程之间的共享图形内存；我们最新的 Chromium 更新已经过修改以使用它，这与 Chromium 75 的功能相比发生了很大变化。因为我非常固执，而且我已经讨厌那个 API，在 27.2 发布后大约两三天，我决定我必须找出这是否是触发因素。在那之后的第二天左右，我修改并编译了 Chromium，以删除几乎所有我能看到的 IDXGIKeyedMutex。因为 Chromium 是一个涉及数千万行代码的巨大项目，而且因为它使用了如此多的抽象层和进程间通信，所以我怀疑我是否能够完成它；我们的一些贡献者建议我们应该放手并恢复到 Chromium 75。但是非常顽固，在学习了几天 Chromium 的内部工作原理之后，我设法删除了几乎所有键控互斥体的使用。因为 Chromium 是一个涉及数千万行代码的巨大项目，而且因为它使用了如此多的抽象层和进程间通信，所以我怀疑我是否能够完成它；我们的一些贡献者建议我们应该放手并恢复到 Chromium 75。但是非常顽固，在学习了几天 Chromium 的内部工作原理之后，我设法删除了几乎所有键控互斥体的使用。因为 Chromium 是一个涉及数千万行代码的巨大项目，而且因为它使用了如此多的抽象层和进程间通信，所以我怀疑我是否能够完成它；我们的一些贡献者建议我们应该放手并恢复到 Chromium 75。但是非常顽固，在学习了几天 Chromium 的内部工作原理之后，我设法删除了几乎所有键控互斥体的使用。

我简直不敢相信：它解决了系统冻结问题。它成功了！在死星的垃圾压实机停用后，我感觉就像卢克·天行者。

然而，它引入了一个新问题：虽然它解决了系统冻结问题，但在渲染浏览器源代码时，取消同步不可避免地会导致帧卡顿和帧同步问题。很明显，我知道我的工作还没有完成。在那之后接下来的一两天不眠之夜，为了解决这个问题，我开始努力寻找其他方法来同步 Chromium 和 OBS 之间共享的纹理。再加上 Chromium 代码非常抽象并且依赖于许多不同的独立进程间部分一起工作，这使得这项任务变得异常困难。在一两天没有成功之后，另一位贡献者建议我放弃它，它已经足够好了，而且我们有 v5 API 的最后期限。本来我认输了，算了吧，

洗完澡后，我告诉其他贡献者，我将在那天晚上尝试最后一件事，如果我不能在晚上结束前完成，我就会放弃。在孤注一掷的最后一搏中，我花了整晚的时间对 Chromium 的几个关键部分进行了重新编程，以与 OBS 共享一个纹理，该纹理将通过后台缓冲区纹理的简单复制操作自动更新：与版本 75 的补丁完全相同的方式完成它。

我的努力被证明是富有成效的，它不仅解决了帧卡顿问题，而且还极大地提高了 Chromium 95 构建的性能。我们不仅修复了系统冻结和帧卡顿问题，还大大提高了浏览器源代码性能！

言语无法描述那种感觉有多好。我的兴高采烈从简单地离开死星上的垃圾压实机到一举炸毁整个死星。我们尽可能地与每个人一起对其进行了测试：每个人都确认他们所有的问题都已解决，并且浏览器源代码的性能比以往任何时候都好。经过整整一周的不眠之夜，我们现在推出了 27.2.1，这是一个传奇的修补程序。这是我生命中最糟糕的一周，却以某种方式变成了我生命中最美好的一周。

我想向那些故意让他们的 PC 崩溃以获取内核转储的非常耐心的用户大声疾呼，向 R1CH 大声疾呼以找出可靠地重现系统冻结的方法，并向 Matt、pkv 大声疾呼、Flaeri、Shaolin、RytoEX、Ace 以及其他所有花时间在不同系统上测试不同构建的人。谢谢你们。如果没有我们所有优秀的贡献者一起工作，这一切都不可能实现。

多么疯狂的一周啊。我终于可以再次入睡了。