如何为类似 Twitch 的应用程序构建 WebRTC 媒体服务器

Question

我正在尝试构建一个类似 twitch 的应用程序（即多对多实时视频流）。我想使用 WebRTC，因为我想让应用程序可以从所有平台访问（我打算使用 Nativescript 或 PWA 道路）。我的计划是将摄像机从人 A 流式传输到媒体服务器。以多种质量等方式对 WebRTC 流进行转码，并将其发送给所有订阅用户，这些用户也可以播放 WebRTC 流。在理想情况下，将有数千个主播，每个主播都有数千个实时订阅者。

然而，如何做到这一点呢？我需要某种媒体服务器，它负责接收流、转码并转发它。MVP 将只是转发流，而不对其进行转码，但是，将来应该可以添加该优化。

我应该去买 Kurento、Jitsi 之类的东西吗？或者我自己搭建这个服务器可行吗？

这种架构是一个好主意，还是我应该重新考虑一切？我不使用 RTMP 或类似的东西的原因是因为必须投入大量的代码和工作来开发本机应用程序（iOS、Android、任何浏览器）的不同客户端代码。如果我可以使用 WebRTC，这将使客户端代码更容易，并使应用程序可在所有平台上访问。

非常感谢！

Answer 1

一个雄心勃勃的项目，将会很复杂

首先：如果您计划编写大型应用程序，媒体服务器是一个不错的（甚至是必要的）选择。转录或让发送者发送多个视频流质量将改善您的用户体验。

现在到媒体服务器：您只对转发媒体、基于 sfu 的服务器或类似服务器感兴趣。Jitsi 和 Kurento 都可以做到这一点（但 Kurento 更多时候被关联为混合服务器）。我无法为您提供使用其中哪一个的建议，因为我对它们没有足够的经验。

SFU 方法可扩展性很好，可能足以满足您的应用程序的需求，但对于像 twitch 这样的大规模服务，您还可以看看 CDN 支持的技术。传统上，这是 DASH 或 HLS。两者都会增加延迟，但由于您没有两个或多个用户实时相互交谈，而是只有一个人进行广播，因此这可能是可以忍受的。

我自己研究过这个问题，并在这里找到了一些相关的内容，可能会对您有所帮助。基本思想是通过 webrtc 将视频发送到服务器（低延迟，但当达到 sfu 的限制时不一定能很好地扩展），然后对视频进行 DASH（或更优化的 CMAF）编码。然后，您的内容可以通过 CDN 提供服务，这可以让您扩大服务规模。

但为什么不看看 twitch 对自己的评价呢？在这篇文章中，他们列出了他们的服务并简要介绍了他们的工作方式： twitch Engineering - 简介和概述