欢迎阅读第一份 OBS Studio 进度报告。我的名字是 Lain，OBS 一贯沉默的作者。22.0 版终于出来了，我写得很开心。

这将是一篇很长的文章，因为我平时几乎从不说话，所以请做好准备。

首先，我想说声谢谢

这个月是 2012 年 8 月第一次发布 OBS 六周年。那时候我能够回复论坛上的每一个帖子，与几乎所有来聊天的人互动，并回复每封电子邮件. 2014-2015 年左右的某个时候，论坛帖子、电子邮件和聊天变得如此活跃，以至于我每天要花 10 个小时来回答所有问题。最终，我不得不停下来，将该任务委派给其他人，并专注于该程序的工作。

截至今天，22.0 之前的上一个版本 21.1.2 在三个月内下载了 900 万次。

这让我大吃一惊。

该程序（连同其衍生产品）可以说已成为 Twitch、YouTube 和世界各地使用最广泛的直播和录制工具。我怎么强调我对这次机会的感激之情都不为过。在我制作这个程序之前，我处在一个非常糟糕的地方。现在，我获得了我从未想过会拥有的机会，以及一份独特、可靠的简历，这将使我长期吃饱。希望我能尽可能地继续这样做，因为我从中获得了很多乐趣。

因此，再次感谢使用我的程序并发现它有用的每一位：谢谢。你改变了我的生活；我希望我也能改变你的。我知道你们中的许多人在我们不起眼的工具的帮助下取得了相当大的成功，我希望你们继续取得成功。

现在，让我们快速回顾一下自 21.1 以来发生的最大发展。

浏览器源代码进行了重大重构，现在支持硬件加速

浏览器源代码可以说是该项目中最复杂和最重要的插件之一。将 Chrome 本身打包为可用作您可以添加到 OBS 的源，这听起来很复杂。幸运的是，感谢CEF 项目的优秀开发人员和贡献者，我们已经能够将浏览器的强大功能集成到项目中，用作合成工具。在 22.0 版中，我们终于实现了硬件加速的离屏浏览器表面，这要归功于 CEF 项目的优秀开发人员和贡献者。

以前，浏览器源代码的工作方式是以下两种方式之一：

• Chromium 使用硬件渲染（GPU 渲染）渲染浏览器表面 -> Chromium 下载表面到 RAM -> Surface 通过 RAM 从 Chromium 传递到 OBS -> 我们上传回 GPU 用作 OBS 的源

• Chromium 使用软件渲染（CPU 渲染）渲染浏览器表面 -> Surface 通过 RAM 从 Chromium 传递到 OBS -> 我们上传到 GPU 以用作 OBS 的源

不幸的是，在最长的时间里，前者比后者占用更多资源，并且在渲染时也会出现奇怪的问题，因此我们不得不对浏览器源使用软件渲染。然而，软件渲染也有其自身的问题，例如模糊的崩溃和无法使用 WebGL 进行高级叠加。无论哪种情况，我们都被迫始终将每一帧上传回 GPU 进行合成。因此，对于浏览器，我们一直进退两难。

今天，有人提议对 CEF 进行更改，这将允许将共享表面从 Chromium 渲染器直接传递到实现 CEF 的程序。这意味着管道现在看起来像这样：

• Chromium 使用硬件渲染（GPU 渲染）渲染浏览器表面 -> Chromium 与 OBS 共享该表面以用作源，而无需离开 GPU

这样做的性能和资源优势是惊人的。您最初可能会想“但是等等，现在它必须在 GPU 上渲染，这不是使用了更多的 GPU 吗？”，但事实证明情况恰恰相反：以前，当我们必须将浏览器表面上传到 GPU 时在每个浏览器框架中，仅上传框架的操作就需要比使用 GPU 实际渲染浏览器表面更多的 GPU 使用率。

为了了解必须将多少数据传输到 GPU，我们以最坏的情况为例：1920x1080 浏览器表面以每秒 60 帧的速度更新。一个 1920x1080 RGBA 帧大约是 8 兆字节，以每秒 60 帧的速度将其传输到 GPU 几乎是每秒 500 兆字节。这意味着我们不仅减少了 CPU 和 RAM 的使用，因为我们不再在 CPU 和 RAM 上渲染表面，而且我们还减少了 GPU 的使用，因为我们不再传输无数兆字节到显存！

对浏览器源代码的这一更改减少了其 CPU 使用率、RAM 使用率和 GPU 使用率。这是自创建游戏捕获以来该程序所见过的最重要的优化之一。

最重要的是，浏览器源代码总是一个极其复杂的插件。它本身就有数万行。在 22.0 版本中，它现在已经完全重构，超过 13,000 行代码被删减（您可以在此处查看提交）。任何有经验的程序员都可能感受到我说这些话时的喜悦。可以说，与添加新功能相比，修剪大量不必要代码的行为对程序的整体健康更有价值。所有内存泄漏都已修复，设计已大大简化，代码更具可读性。这是一项早该完成的伟大事业，我可以自豪地说，代码现在处于多年来最好的状态。

最终解决我们不得不面对的最大问题之一是绝对值得的。

来源分组

源分组一直是人们期待已久的功能——将多个源视为一个源的能力。我们最初添加了使用场景作为源的功能，这是此问题的临时解决方法（您仍然可以使用）。但是，场景始终与画布大小相同，要编辑源，您必须切换到那些场景来编辑元素。它有其优点和缺点，但以这种方式使用它们总是有点尴尬。

在 22.0 中，我们现在有了源分组。我考虑通过自动组合多个子项的选择矩形并始终将它们视为“一个”来实现这一点，这本来是最简单的解决方案。但是，如果我在内部将组实现为可调整大小的场景，我们就能够将过滤器应用于组，并且能够更轻松地在其他场景中引用组。它有点复杂，但我决定选择后者，因为它给用户带来了最大的好处和功能。

我还想确保您可以在列表框中看到组的子项、选择/修改这些子项以及展开和折叠该列表，因此必须完全重写源列表的小部件。

该计划的下一步是什么

使程序更简单，并改善用户体验

如果最近发生的事件教会了我们什么，那就是 OBS 对新用户并不是特别友好。自动配置工具（用户可以在第一次启动程序时使用，或者在工具菜单中访问）对此有很大帮助；这是非常好的第一步。它可以让主播开始使用他们的编码设置并让程序输出到流媒体，但它不能帮助他们设置他们的流媒体的其他部分，比如捕获、覆盖、相机、警报，以及所有需要的东西如今对于主播来说越来越重要。

接下来几个版本的重点之一是让新用户更轻松，让人们更容易上手；不仅能够设置他们的编码/视频设置，还能帮助他们开始使用叠加、捕获和其他内容。

用户体验也有很长的路要走：拥有设计良好的用户界面，具有流畅、直观的流程和设计。可悲的是，该程序在该领域也不是最理想的。有些功能是有些人没有意识到的；一些隐藏在菜单中的功能。或者有时，用户不知道某个功能的含义或功能，因此他们从不使用它。用户问我们为什么丢帧的次数几乎是愚蠢的，这可能应该在程序中得到更好的解释。状态栏不能很好地传达信息，设置窗口可能需要大量工作，上下文菜单有无穷无尽的选项——这个列表还在继续。

这些都是可以改进的，让程序的体验更好。减少界面中任何一种“笨拙”的感觉，让事情感觉更好、更容易掌握是另一个重点。

我希望添加的另一件好事是能够从程序中登录 Twitch/Youtube，这将引导我进入下一个部分：

从程序中访问服务 API

我们从一开始就应该做的一件事是在程序中实现服务 API：Twitch、YouTube 的 API，甚至可能是流式警报服务的 API。这将很有用，不仅因为我们希望避免让用户复制和粘贴他们的流密钥，而且因为它允许程序添加各种各样的其他功能，例如能够看到观众人数、频道关注者、频道订阅者、他们使用的任何提醒服务的提醒，以及越来越成为流媒体不可或缺的一部分的各种事物。当然，这都是可选的——如果用户不想使用这个功能，他们应该总是被允许按照他们以前的方式使用这个程序，而只是输入一个流密钥。

实施这些 API 后，这不仅有助于让初次使用流媒体的人更容易使用该程序，还可以提供用户可以利用的强大新功能，并为公司提供工具来改善用户流量并更好地适应他们的用户.

我原本打算让它成为 22.0 版本的一部分，但我们的设置窗口需要大量工作来适应这一点，所以我决定只发布 22.0 版本而不是原样。

在分叉和插件上

最近围绕 OBS 有一些有趣的发展。其中一个是某公司对我们自己项目的一个fork；它有我们的核心，但不同的前端。我认为用户有选择总是一件好事；即使这给我带来了很大的表演压力，即使有时对我来说压力很大。它让行业保持健康，让用户受益最大，因为每个人都在努力改进和创新。

然而，不管它的名字，我想明确一点，这个分支与我本人或 OBS 团队无关。我想非常明确地声明，我没有与任何警报服务公司签订任何合同协议。我提出的唯一真实要求是人们遵守 GPL。

我从来没有也永远不会做出任何最终会剥夺用户使用该程序的自由的合同协议。对我来说，这个程序是而且永远是用户的，为用户服务的。这是我个人的理想。尽管有时对 GPL 许可证有很多狂热，但我完全相信其预期的自由理想。

从根本上说，如果我缺少行业需要的东西，那么我想努力提供给行业。那是我关注的事情；使程序不仅对用户更好，而且对行业更好，并有助于为行业提供增长。使程序更易于新用户使用，改善用户体验，并为行业内的用户和公司提供更好的工具。

但是，我想确保用户始终是控制者。

贡献、组织和前进

该程序现在是一个相当大的项目。它现在有几十万行代码，每月大约有 30-50 个拉取请求。与此同时，我仍在添加改进、修复和我自己的功能，同时管理所有这些。在这一点上，组织和委派越来越有必要满足每个人的需求。我现在意识到这不是我一个人能做的事情，所以可能很快就需要建立某种官方组织。

幸运的是，该项目的出色贡献者一直在添加请求的功能、改进项目、修复错误、进行翻译、维护网站、在论坛和聊天中提供支持，并以多种方式提供帮助，这让我大吃一惊。

我对参与该项目的每个人都非常感激。每个做出贡献的人，每个帮助提供支持的人，每个帮助管理项目不同方面的人，每个捐赠过的人，每个报告错误或功能请求的人，尤其是所有使用过并喜欢我们的用户卑微的节目。

这个项目拥有任何人都可以要求的最好的社区。

我绝不是完美的，也不是我所做的每一个决定都是完美的；但我会尽我所能使这个项目成为最好的。

如果您想为该项目做出贡献，请阅读我的关于如何为开源项目做出贡献的指南。

感谢您的阅读！