写在最后，放在最前
我们为什么这么做？
答案很简单，因为中国大陆还有很多行星边际2的玩家，也有很多在九城代理的国服关闭后就弃坑的玩家，但更重要的是我们缺少新玩家。我们热爱这个游戏，我们想做的事情也不止这一件，我们想让玩家群体壮大和团结起来。在规划这件事的过程中，我们也意识到，这不是中文玩家群体面临的问题，而是所有玩家都在面临的问题。
我们为什么选择公开了这篇文档？
事实上，我们在组建直播团队的那一刻起，就已经决定会向所有人公开这份文档。我们想做的是推广这款游戏，持续运营了如此之久且依然富有生命力的游戏本就凤毛麟角，但如果没有新玩家加入，最终会难以避免地走向衰败。
我们认为，军团战这样规模的赛事，对于行星边际2整个玩家群体来说都是一个大事件，甚至本可以成为 DBG 增加收入和提高玩家凝聚力与成就感的重要环节。但曝光量的不足却只能让如此重大的事件沦为“玩家们的自娱自乐”，并且没能利用好宣传和推广这款游戏的巨大机会，我们觉得十分可惜和不可理解。我们甚至听到一些索泰克服务器放弃军团战的军团吐槽道“只奖励这么一个边框有什么好打的”，也有军团成员建议道“如果军团战胜利者可以定制一个自己军团命名的迷彩上架销售，那会多么开心”。DBG 本可以让自己的辛勤付出获得更多地积极评价和收入，可为什么就在迈向更进一步的成功之前停下了脚步呢？
我们希望的是，DBG 能够意识到军团战对于整个游戏和玩家群体的重要性，他们有能力也有动力将军团战打造成一个可以定期举办的常态化赛事。除此以外，能有一个像 ESL 和 Blast 那样，由自己或授权的组织出面，对赛事的直播进行一个标准化的制作，并分发纯净的直播流画面给授权的直播主，让更多玩家和直播主参与到内容的分发和讨论中无论如何都不是一件坏事，这甚至可以成为 DBG 的一个新盈利点。
我们可能不太了解 DBG 是如何看待军团战的，但我们能看到的是，PSB、Honu 社区和大量希望参与到军团战直播中的直播主为代表的很多社区组织和个人，为这项赛事贡献了大量的时间和精力，他们利用手头捉襟见肘的资源做了许多努力来推广和呈现游戏内的精彩时刻，但他们也在面临着资源和支持不足的问题。以我们为例，索泰克服务器的 API 无法正常工作的状态持续了几个月却迟迟得不到修复，导致我们在最初甚至无法像海外其他直播主那样使用社区制作的赛事插件，而其他社区也因此无法采集一些关键数据。幸好在不久之前，索泰克 API 终于恢复了正常，但这也让我们意识到，玩家和社区开展活动的重要前提是，DBG 有能力提供给社区这些资源。我们在这里并不是想指责 DBG 的不作为，我们只是希望，DBG 可以多听听社区的意见和建议，提供更多的资源和便利，这可能不会让你们花费许多金钱和精力，但是却可以让社区和玩家群体更加壮大。
简而言之，我们的目的有以下三点：
希望 DBG 能更加认识到军团战的商业价值和品牌影响力，这对于游戏的推广至关重要。
我们非常严肃地认为，在直接发放OB账号以外，DBG 应该通过组织官方媒体团队、或者向媒体团队发放授权的方式制作高制作水平的比赛纯净流，并通过自己认为合理的方式向官方认可的媒体或玩家提供赛事画面，方便他们进行赛事直播。并且我们非常严肃地认为，这是官方应该做的事。我们已经证明了低成本制作的可行性，但我们没有资金和专业技术支撑我们做出高质量的赛事直播，但你们可以，有更多专业人员和资金支持的组织也可以。
希望官方在运营方面能更多地与玩家社区进行交流，听听他们的需求和反馈，甚至可以将一些媒体运营的想法交给玩家社区试错。如果他们走出了一条可持续发展的路，官方是否可以认可他们的努力并给他们支持。让社区和猎人服、测试服作为策划和社区意见交流碰撞的试验田，甚至可以促进行星边际2的电子竞技方向转型等各种未知的可能。
确实，我们都不是所谓的“专业人员”，我们之所以能做到这样的事情，是大大小小所有相关社区的微小贡献集合而成的结果。
在这里我们真的非常感谢那些为我们提供过资金、技术和精神支持的朋友和陌生人。没有你们的话，我们只靠单纯的热爱是无法做到现在这些事情的。
如果我们这篇文章和我们遇到的各种奇怪问题能帮助你们少走一些弯路，那我们也会感到非常高兴。
写在前面
这是 PS2CPC 直播团队在组织 行星边际2 Nexus 2022 军团战 直播的相关技术平台搭建工作时整理的资料。
这篇文章的目的，一方面是记录我们的直播团队搭建过程，另一方面是向 PSB 等其他军团战赛事直播人员解释我们的工作方法，希望对他们的多机位直播团队搭建提供帮助。
我们并没有十分充裕的资金来源，也不是专业的导播、直播主、开发人员和直播行业相关从业人员。由于我们所有技术团队人员都没有很强的专业背景，并且绝大多数工作人员（包括写下这篇文章的我）的英语水平并不高，所以我们获取的资料和技术方案大多来源于网络上的公开资料。我们确定的技术方案可能不是最合理的，但这是经过我们的测试和实际使用后认为可以满足我们使用需求的技术方案。
基于以上原因，我们的直播技术方案所关注的重点如下：
尽可能地压缩开支，使用我们手头的软硬件资源。
我们不是一个本地团队，要求所有的工作都必须能够完全通过线上的方式进行。
每次直播的工作人员（如解说、OB机位、军团机位提供者）的流动性非常大，所以要求对他们所要进行的必要配置尽可能地简化。
文中提到的方案，可能永远不是我们一劳永逸的最终方案。事实上，我们一直在发现问题、解决问题和向问题妥协的三点之间不断游走。而我们能做的，只能是在我们有精力和有必要的情况下去尝试完善方案，而这个方案完善过程会是缓慢而持续的。
直播方案
直播方案简述
PS2CPC 的直播方案不同于绝大多数个人直播主。这里将对我们的方案进行简要的介绍，以便于读者理解我们一些看似奇怪，实则我们认为有必要的做法。
直播人员配置
我们的直播团队的人员配置如下
1. 军团战 OB 账号操作者
很好理解，这是直接提供战场画面的操作人员。
目前的方案中，最佳实践是使用 3 名军团战 OB 账号的操作者。他们并不都用于战场画面的追踪，而是有以下两种分工：
机位：2 人，他们会用于追踪战场上的焦点战斗画面。
地图 OB 位：他不直接追踪战场上的战斗画面，而是始终打开地图界面。一方面，他会为导播和解说们提供一个清晰的、包含战场局势和实时战斗热点的地图，另一方面，他可以通过下达小队指令的方式引导两个机位更快地捕捉当前的热点战斗。
在一些精简人员的直播方案里，这个位置可以同时担任解说。但我们没有采用这样的方案，我们会安排独立的解说。
我们知道，有其他的社区组织（如 honu），他们提供了一个 web app 可以显示地图据点占领态势。他们的插件提供的击杀数量对比信息和地图态势信息，弥补了官方显示内容的缺失。我们非常敬仰他们能做到这么了不起的事，也非常乐于使用它。但我们最终选择关闭了该插件的地图输出，原因也很简单：游戏内地图的实时性和信息丰富度更高。
2. 解说
很好理解，不再赘述。
在一些精简人员的直播方案里，这个位置可以同时是 OB 账号的操作者。但我们没有采用这样的方案，我们会安排独立的 OB 账号操作者。
3. 军团战参赛双方的第一视角机位
这些机位用来填补 OB 账号操作者在进行调度时的内容空白，同时也可以更好地提供当前进行的战斗画面，为观众提供更丰富的战斗画面。
一般来讲，参与战斗的双方都会分配三个机位。最佳实践是分别提供给指挥、经验丰富的空战玩家和经验丰富的步战玩家，或者分配给空军、坦克驾驶员和步兵。
因为沟通的问题，可能参赛的一方（甚至双方）都不会向我们提供这些第一视角画面，但这是可以接受的。
4. 导播
导播所拥有的是画面调度的最高权限。他负责的是监测上述的视频流，并决定切换到哪个画面。
与此同时，导播还需要监听解说们的语音内容，对他们提出的画面调度要求，向 OB 账号操作者下达相关的调度指令。
5. 副导播
首先说明，这个名字可能没有很清晰地描述这个人的工作职责，事实上我们也不知道该怎么称呼他。
他的职责是，根据导播下达的画面切换命令进行实际操作。
这个职位是在我们直播过程中为了解决非技术问题而新增的，作用是降低导播的工作压力。
6. 其他工作人员
这些工作人员的工作是处理直播前的人员协调和设备准备工作，在实际直播工作开始时并不承担实际工作。
但他们非常重要，因为我们所有的工作流都是线上的，并且人员流动性很强，所以非常需要他们的耐心和热情去进行人员协调和赛前软件配置。
直播技术架构
大致了解了我们的人员分工后，接下来就是介绍我们目前所使用的技术架构。
我们需要解决的问题
我们需要解决的问题大致有以下几点：
如何让导播可以稳定地获取到 9 条原始信息流？（3 个 OB 的视频流，6 个军团第一视角机位）
我们该如何让解说能稳定地看到低延迟的导播输出画面？
我们该如何把最终的画面推送到多个直播平台？
我们认为这些问题的答案
事先说明，我们并不是有专业技术背景的人员，也并没有对所有技术细节进行深入研究。这些东西都是我们经过粗略的网络搜索和简单的实验验证的，可能不准确或不全面，但我们认为是够用的。
1. 如何让导播可以稳定地获取到 9 条原始信息流？
答案很简单，我们需要一个实时视频服务器来做这件事。
由于中国大陆地区的网络条件限制颇多，并且跨运营商的网络连接也不够稳定，我们使用的是普通的家庭宽带来处理这件事就变得比较困难。如果你并不是中国大陆地区的读者，可能你有更多的选择，甚至可以考虑在本地自行搭建一个实时视频服务来解决这个问题。
我们经过测试之后，最终选择了两个实时视频服务器的解决方案。
付费的腾讯云直播。
我们选择它的原因如下：腾讯云拥有多个运营商的接入和完善的 CDN 支持，可以帮助我们获取和分发稳定的视频流。
腾讯云也拥有云录制、流管理等有助于我们管理和调试的相关功能，这比我们自行解决的时间成本更低。
对不在中国大陆地区的读者来说，腾讯云直播的类似替代品可能有 Amazon AWS Live Streaming或更多，这需要读者自行寻找和测试。
开源且免费的 SRS。
我们选择它的原因如下：它的开源社区虽然规模较小，但提供了比较清晰的使用案例，对于我们这些没有专业技术背景的人来说更容易部署和使用
他的性能表现很好，有助于我们降低使用成本。
事实上，SRS 和腾讯云直播成为了我们整个工作流的基石，尤其是 SRS，它的易用性和功能的完备令我们印象深刻，这也是我们在直播中推广（并感谢）这个开源项目的原因。
2. 我们该如何让解说能稳定地看到低延迟的导播输出画面？
我们认为的答案是，使用 SRT协议。根据我们从公开网络搜索到的资料，SRT 协议的延迟表现要比 RTMP 协议好得多。
经过我们的实际测试，我们最终选的的方案是：在导播机所在的内网中架设 SRS 服务，让解说们直接使用 FFPlay 拉取 SRT 流进行观看。
这个方案的代价是，它会占用一些我们本就不怎么宽裕的上行带宽，但因为这种方式完全满足了我们的需要，同时顺带解决了一些奇怪的附带问题，所以我们暂时没有更改的必要。
在一次军团战直播中，其中一名解说末童（Motong，他也是我们直播团队与 PSB 交流的核心人员）从澳大利亚拉取了我们位于中国福建的视频画面参与了解说工作。虽然在过程中遇到了更高频率的画面卡顿问题，但它优秀的解说能力成功弥补了这个问题，同时位于中国大陆的解说人员没有报告画面的严重问题。总体来讲，我们认为这是可以接受的。
3. 我们该如何把最终的画面推送到多个直播平台？
答案是，我们需要足够大的上行带宽，还有 FFMPEG。
上面我们提到过，我们使用的只是普通的家庭宽带，虽然拥有很不错的下行速度（1000Mbps），但上行带宽却“少得可怜”，只有 30 Mbps左右。所以在这里我们不得不做一下简单的数学题。
两条提供给解说的 SRT 流，每条为 8 Mbps，混流机输出的也是 8 Mbps的视频流，这样我们能做的，就只能推送 1 条视频流出去。
就是这个简单的数学题，却给我们造成了非常大的麻烦。事实上，我们在直播中因为预料之外的其他设备占用了珍贵的上行带宽，导致这核心的 1 条视频推流出现问题，最终导致所有直播平台出现了持续几分钟的卡顿。在这种情况下，本地的多推流已经是不可能的事情了。
为了解决这个严重的问题，我们把目光放到了 SRS 身上。
我们之前提到过，为了解决解说流的问题，我们在内网部署了一台 SRS 服务器。这次，我们将利用它的 Edge 集群特性，在外部部署了一台 SRS 服务器，并将我们之前部署的内网 SRS 服务器作为源站。
相关的技术细节，读者可以阅读文档详细了解。这里为了便于没有看过文档的大家快速理解，我们把内网的 SRS 服务器称为【源站】，外部部署的新 SRS 服务器称为【中国大陆地区的分发站】。
SRS 的 Edge 集群有一个显著的优点：我们不需要对内网的 SRS 服务器做任何配置上的修改，并且【中国大陆地区的分发站】对视频流会进行相应的复制和缓存操作，这样的好处就是对于同样的一条视频流来说，不管【中国大陆地区的分发站】这里有多少客户端请求这条流，【中国大陆地区的分发站】只会从【源站】获取一条流进行分发。
这个特性正好解决了我们“只能提供一条视频推送，但我们希望多平台直播”的目的，所以我们在这台【中国大陆地区的分发站】服务器购买足够大的上行带宽，并启动多个 FFMPEG，拉取这条 RMTP 流之后推送到其他平台就可以了。
特殊的一点在于，由于我们身处中国大陆，没有办法使用中国大陆的服务器直接推送到 Twitch 和 YouTube，也没有办法从位于中国大陆以外地区的服务器上推送到 Bilibili、斗鱼、微博、QQ 频道和抖音（抖音和 TikTok 虽然都属于字节跳动公司的产品，功能也高度类似，但他们是互相独立运营的）。所以我们额外增加了一个【美国硅谷的分发站】，它的源站就是我们上面提到的【中国大陆地区的分发站】。我似乎描述得有点不清晰，但他们就像一条链或者贪吃蛇一样，数据流动方向是【源站】->【中国大陆地区的分发站】->【美国硅谷的分发站】。
但之后我们在一次网络波动中意识到，在跨国的数据传输上，我们中国大陆地区特殊的网络传输会有潜在的风险。所以我们最后为了短时间内解决该问题，将方案变更为成了【源站】->【中国大陆地区的分发站】->【腾讯云直播】->【美国硅谷的分发站】。
我知道，理清了我们架构的读者肯定会问这样一个问题:
“为什么你们没有选择【源站】->【腾讯云直播】->【美国硅谷的分发站】 和 【源站】->【腾讯云直播】->【美国硅谷的分发站】并行的策略呢？”
我们的答案是：因为我们担心以下两个问题：
当我们意识到这个问题的时候，我们距离第四周的军团战开始已经不足两个小时了，当时能够进行设置的技术人员（也就是写下这篇文章的我）既要负责检查所有直播服务器的工作状况，又要去协调 3 个 OB 操作者和 6 个军团第一人称机位的设置检查工作，实在是没有足够的时间去验证这样的工作流程会不会出现各种配置错误导致的严重直播事故。
我们在之前的测试中曾经遇到过这样一个问题：当我们【源站】的视频流通过 FFMPEG 推送到腾讯云直播后，再通过 FFMPEG 拉取，并经过混流和更多视频处理流程最终播出后，会出现更高频率的下半部画面花屏问题。这个问题成为了我们非常大的担忧。
基于以上原因，我们做出的决定是：把海外平台的花屏作为“赌注”，优先保证中国大陆平台的顺利播出。所以最后我们选择只改变【美国硅谷的分发站】的相关配置，同时在【中国大陆地区的分发站】所在的服务器增加一个 FFMPEG 实例，将画面推送到腾讯云直播服务器后，让【美国硅谷的分发站】使用 SRS 的 Ingest 功能缓存和分发更多的流。
最后的结果是：我们确实观察到了海外直播平台会出现偶发的花屏问题。但我们讨论后得出的结论是，除了付出更高的成本购买更好的服务器以外，没有办法改善这个问题。
但这个问题对于海外的直播主来说可能并不会特别严重，我们也认为画面还是“可接受的”。
我们的直播方案
我们的架构演进过程
这些图是我短时间内赶工画出来的，而我也并不是一个逻辑十分清晰的人，可能绝大多数人都不能很好地理解我想表达什么。但我只能先给出这张图。
之后我会尝试通过描述我们的架构调整和写一些 Q&A 的方式来尝试将整个系统讲清楚。
首先，我想特别指出一些重要的点，这有助于解释我们的一些操作：
对比来看，我们浅显地认为 SRT 协议是优于 RTMP 协议的选择，在可以选择 SRT 协议的地方请优先选择使用 SRT 协议。
在 SRS 4.0 版本中，你可以向一个 SRS 服务器推送一条 SRT 协议的视频流，也可以从这台服务器拉取一条 SRT 协议的视频流。但是，当 SRS 使用 Edge 集群 和 Ingest 功能的时候，它【似乎】不能直接传递 SRT 协议的流，而是会在 SRS 内部将其转换为一条 RTMP 协议的流进行分发和传递。
基于上一条的原因，分发流程中我们没有使用 SRT 协议的原因是 SRS 服务器目前只提供了 RTMP 协议的流，而不是我们不想用。我们联系过 SRS 开源社区和 SRS 项目的核心开发者，他们都提到了未来版本会进行相关改进，但这些版本目前没有进入“生产可用”状态，我们也没有时间和精力去“冒险”。
最终画面的分发过程中，延迟额外增大了几秒我们认为是可以接受的，因为 PS2CPC 的直播为了避免泄露战术导致的不公平对抗问题，延迟设置为 7 分钟。
1. 最初的方案
这是我们在最初设计的方案。很显然，这个方案与绝大多数个人直播主的方案相似度非常高。唯一的特别之处，就是增加了一个内网视频流中继服务器（SRS），他的作用我们在上面谈到过了，就是为了解决解说们获取低延迟的视频流的问题。
用语言描述该方案，大致内容如下：
两个 OB 账户的操作者 使用 OBS 采集游戏画面，直接推送到导播所在的内网 SRS 服务器。
导播机上的 OBS 从 内网的 SRS 服务器拉取画面，并进行适当的调度编辑后，将解说和观众应该看到的画面推送到内网 SRS 服务器。
此时，解说通过 SRT 协议 拉取导播输出的画面进行解说。
与此同时，使用 OBS 的 NDI插件，直接向推流机推送该画面，用来混合解说们的音频信息。
推流机将混合了解说音频的视频流推送到目标直播平台。
相信如果读者认真看过上面的部分的话，应该比较容易理解这个直播过程。
这里比较核心的问题是以下几个方面：
我们上面提到过，SRT 协议的延迟足够低，以至于我们可以认为解说麦克风传回的音频与实际画面情况是“同步”的，所以我们不需要在推流机上进行笨拙的人工对时，即可获得一个可以接受的音画同步视频流。
OBS 的 NDI 插件实现了关键的流程。
但是，我们在使用这套方案的时候发现了严重的问题：
由于 OBS NDI 插件的问题，导致导播机的 CPU 占用率 持续接近 100%，最严重时 OBS 都出现了短暂的无响应。要知道这台导播机使用的是 AMD Ryzen 5800x，绝对是一颗性能强悍的 CPU。我们无法解释 NDI 为什么导致了这样的问题，也无法解决。
由于我们使用的是家用宽带，OB 操作者直接向我们的内网 SRS 推流可靠性是比较低的，可能导致画面出现问题甚至断开。
2. 改进方案 1
为了解决最初方案里的问题，我们对方案进行了简单的修改。
我们的改进点针对性很强：
为了解决问题 1， 我们直接放弃了 OBS 的 NDI 插件，只使用 OBS 自带的推送功能。通过内网的 SRS 服务器进行中转，成功解决了 CPU严重超负荷的问题。
为了解决问题 2，我们不再直接推送到自己的 内网 SRS 服务器，而是使用腾讯云直播进行原始画面的采集工作，这样不仅解决了不稳定的问题，而且我们可以更放心地支持更多的原始视频流输入。
这样的方案已经可以满足绝大多数人推送单一平台的需求了，这在技术上应该可以解决大多数人遇到的问题。
但是，我们在直播过程中遇到了非技术方面的问题需要解决：
我们要进行多平台的推流，而不是单一平台。
因为解说和 OB 操作者分离的设计，外加当时索泰克服务器的API没有修复，我们可以呈现的信息非常少，观众和解说完全没有办法掌握全场局势和突发的战场转换，导致最终呈现的直播效果不理想。
3. 改进方案 2
为了解决这些非技术问题，我们对方案进习惯了进一步的修改。这些修改绝大多数都是工作流程上的，而不是承载业务本身的技术方案调整。
我们的改进点主要是在以下两个方面：
我们使用上面提到过的方案，基于 SRS 构建了视频推送的【贪吃蛇】服务器。
我们多申请了一个 OB 账号，这个账号作为 地图 OB 使用。他的具体作用我们在上面已经提到过了。在技术上，它向腾讯云推送了一条地图流，直接提供给导播和解说。对于导播来说，这个延迟与其他机位没有什么区别；对于解说来说，地图流甚至略微超前于纯净流，但是基于观察战场态势的目的来讲是足够用的。
4. 目前我们在使用的方案
这个图所展示的，就是上面 改进方案 2 的详细架构，也是我们目前使用的架构。
图中不同颜色的实心线和箭头表示了不同协议的视频流的流向，虚线和箭头表示了音频流的流向。
读者可能需要一点耐心去结合前面的图片理解我们所想表达的内容。
这套方案目前可以满足我们的需求，并且短时间内不会进行大的变动。但是，他也是存在一些可改善的点的：
我们自始至终没有变更过解说观看的低延迟流的处理方法，所以根据我们的计算，目前我们 30 Mbps 的上行网络条件下，只能提供两条解说流。
我们正在考虑但没有测试的方向是，在内网 SRS 服务器上 额外运行一个 FFMpeg，把这条低延迟的视频流 以 SRT 协议的方式推送到 用于国内直播平台推流的 SRS 服务器上，利用这台服务器的高下行带宽提供更多的解说流数量。这个改进方向我们没有进行测试，也不打算短期内进行测试，因为我们每个人的时间很有限。这里包含了我们上面谈到的【链/贪吃蛇】推送服务器的妥协方案。事实上，我个人认为如果我们的两台推流服务器网络连接质量足够好的情况下，直接使用 Edge 集群的链应该不会有什么问题。但是，我们没有精力和资金去进行测试了。
这个方案我们认为有非常良好的扩展性。SRS 服务器提供的录制功能和转码功能是个很不错的功能扩展点，可以实现本地的视频切片录制功能，以及 FFMPEG 所能支持的转码、水印等大量额外功能。与此同时，混流机也可以增加一个操作者进行 OBS 的相关操作。这样看来，如果导播团队有足够的设备和人员，你甚至可以做到实时剪辑比赛中的精彩画面用于赛后回顾环节。而你需要做的改变，只是在内网 SRS 中配置 Ingest 获取所有的原始流、为这台 SRS 配置适当的计算能力和更大的硬盘（甚至可以是云存储）。简而言之，阻碍你的只有钱和人员。
