完美的交互式广播架构

虽然我们有时会泛泛地谈论低延迟或交互式广播，但重要的是要注意，实际上有两种不同类型的流媒体用例，需要不同程度的交互性。

对话式用例，即多个参与者在一起交谈，并将该对话流传给许多其他观众。这些观众有可能在某些时候也成为发言者。

单流用例，即只有一个人将他们的视频源（可以是他们的相机，他们的屏幕，或两者的组合）传输给其他观众，他们可以以不同的方式进行互动。最明显的方式是通过聊天信息，但也可以包括表情符号的反应，甚至对正在流传的拍卖进行竞价。

对话用例有特定的要求。例如，它要求有效地同步多个流，只在说话的用户之间有超低的延迟（小于250ms），以及在转发给观众之前对所有流进行视频合成的元素。有多种方法来实现这一点，每种方法都有自己的优点和缺点，像Streamyard这样的顶级产品或Twitch流媒体人用来将Discord整合到他们的流媒体中的方式就是例证。

这篇文章主要关注的是第二类，即与单一流媒体使用案例有关的。这个特殊用例引人注目的地方在于：

如果没有网络限制，该单一流媒体需要以完美的质量进行传输。如果有网络限制，它应该以最佳的实时质量进行传输，并在后台/后期发送额外的质量层，以获得至少是最佳质量的录音。
有一个单一的流被发送，所以不需要多个来源的同步。
你通常不需要<250ms的延迟，可以优先提供更高的质量和 1-2 秒的延迟。

这些用例的一个潜在要求是支持各种终端，如浏览器、移动设备、智能电视、游戏机和移动电话。这些设备在网络、协议和编解码方面有不同的能力。

对于这种类型的场景，在质量和灵活性方面，什么才是完美的解决方案？(假设有无限的时间来开发它和运行它的金钱)

Ingestion

考虑到设备能力和状态（如电池负荷），为终端使用最佳的可用编解码器。在许多情况下，这可能是AV1视频编解码器和高质量的Opus音频配置。

如果可能的话，以完美的质量发送一个单一的流。然而，如果发送方的上行链路存在网络问题，则发送两层视频代替。一层应保持低延迟的要求，而另一层可以根据需要在后台发送，延迟程度不限。这确保了服务器最终会得到一个质量完美的层。

为了在网络中存在数据包丢失的情况下提供低延迟的传输，请使用基于UDP的传输方式。有不同的选择，如SRT、WebRTC、RUSH和自定义协议。让我们用RTS（实时流）作为其通用名称。如果该协议也需要被浏览器支持，那么WebRTC或自定义的QUIC/WebTransport协议似乎是合理的候选方案。然而，在WebRTC的情况下，可能更难实现以前的想法，即在后台总是有一个具有完美质量的层，可能需要一些变通办法。

Processing

有多种音频和视频处理算法越来越受欢迎，如音频和视频去噪和超分辨率。然而，这些算法中有一些过于耗费资源，无法在许多客户端设备上运行。

此外，发送方最合适的编解码器不一定是最好的，也不一定被所有接收方支持。

由于这些原因，包括解码、处理和重新编码的服务器处理管道可能是非常有利的。也有其他任务可以纳入这个管道，如生成字幕或为视频添加水印。

这是系统中最昂贵的部分，对于某些应用来说，它可能是过度的，应该被取消或只应用于最重要的流。如果服务器中没有处理层，那么解决方案就会变得更加简单，发送方生成多种质量的视频流，而服务器只需转发这些视频，无需重新编码。

Delivery

不同的设备需要不同的质量和编解码。此外，一些设备可能仅限于支持HLS，所以可能需要不同的协议。

在大多数情况下，服务器端的录制也是必要的。

对于需要实时功能的用例，可以使用RTS协议。这个协议可以提供不同的媒体版本，包括各种分辨率、比特率和编解码器，可以使用实时CDN来分发。例如，WebRTC可以使用该协议的SFU基础设施。

对于需要互动性，但不需要实时功能的用例，或者需要与传统设备兼容的用例，可以使用LL-HLS协议。像RTS协议一样，LL-HLS提供了不同的媒体版本，可以使用传统的CDN进行分发。

这就是为交互式用例提出的可能的 “完美 “广播架构的建议。你怎么看？像往常一样，我们非常你的反馈。

作者：Gustavo Garcia
编译自medium.com。