来源：Global Video Tech Meetup：SF
主讲人：Jordi Cenzano
内容整理：付一兵
本文来自 Global Video Tech Meetup，作者展示了一个系统，它允许流式传输 SRT（h264 + AAC），并以完全分布式的方式创建实时 ABR。这个实现使用 AWS Lambdas 来执行分段式无服务器转码，使我们能够立即扩展到任何类型的渲染和转码设置，经测试最高可达 2160p@60fps（h264 - AAC）。Demo 开源链接：https://github.com/jordicenzano/serverless-distributed-live-platform
目录
动机
传统实时转码模型
分布实时转码模型
分布实时转码的实施
Demo 演示
挑战
总结
动机
我们的生活中通常需要编码，那为什么我们需要自适应码率或 ABR？因为我们的观众是庞大的来自全球的，有各种设备，为了给所有这些设备和网络连接提供最佳的体验，我们需要能够提供不同的副本，不同的分辨率和比特率的编码，然后让设备将选择最合适的。
传统实时转码模型
如今，对于直播来说，最常用的架构是使用单一主机来创建分发所需的 ABR 阶梯。这是一个简单而良好的方法，但它存在一些问题：可扩展性、灵活性、可靠性。
线性转码的可扩展性问题
当我们要求转码机提供更多它能处理的内容时，机器开始转码的速度就会变慢，这对直播来说是个定时炸弹。播放器会开始停滞不前，而且（取决于实现方式）该机器会出现 OOM 或丢弃数据。简而言之：糟糕的用户体验。
线性转码的灵活性问题
当流开始时，我们可以评估什么是每个通道的最佳编码参数，但在这一点上，重新评估这些编码参数可能是相当困难的。想象一下这样的情况：当流开始时，我们的资源有限，我们决定应用快速编码预设（所以质量低）以节省一些 CPU 容量，但几分钟后我们就有了大量的空闲资源，在这种情况下，更新这些编码参数是相当困难的。
线性转码的可靠性问题
我们有一台机器管理所有的流媒体转码，如果这台机器坏了，我们就会失去流媒体。重复转码阶段可以减轻这种风险，但有一些同步的挑战。
分布实时转码模型
在这种方法中，转码是以小的时间块进行的。第一步是将连续的输入流切成小块（可播放），然后我们可以将这些小块发送给无状态转码器，最后这些转码器可以为每个单独的小块产生渲染。
分布式实时转码的优势有以下几点：
可靠性。如果任何转码器机器发生故障，流媒体不会受到影响。该块是可以重试的，或者我们可以对重要的流进行双重转码。 可扩展性。你不需要购买更大的机器来使用更复杂的编解码器/更高的分辨率 - 帧率，只需使用更多的编解码器（实时转码的水平缩放）。 灵活性。你可以每隔几秒钟重新评估你的决定，所以你可以在任何时候更新编码设置以满足任何标准。 可部署性。你可以在任何时候部署任何转码机而不影响流媒体，这种能力是蕴含在架构中的。
分布式实时转码的问题在于：
VBV 的解码器缓冲区大小：你需要管理解码器的缓冲区大小，因为当你开始编码的时候，你不会有之前的数据。 GOP 大小。转码时间将与此成正比，所以如果你有兴趣提供一些目标延迟，你需要能够控制（限制）输入 GOP 大小。记住最短的可播放单位是 GOP。此外，你还需要封闭的 GOPs。 音频启动。在一些音频编解码器中，你需要前一个片段的最后一个样本，以便能够正确地解码当前片段的音频。 延迟。如果你打算使用你的转码机不能实时处理的编码器/分辨率（例如 AV1 4K），那么你应该期待增加延迟。但在这种情况下，我认为是完全可以的，因为你不能在线性方法中做到这一点，现在你完全可以做到这一点，付出的代价是“只是”延迟。
分布实时转码的实施
第三个橙色块的功能就是终止安全协议，我们使用特定的协议。所有这些操作在计算上都很简单，按照前面的编码配置将原始更改转码为不同的质量。
挑战
编码器速率控制 下一个数据块 N 不知道上一个数据块（N-1），那么我们需要对编码器速率-控制算法施加一些限制，以确保解码缓冲区的大小在控制范围内。 可变场景复杂性 不同复杂度的场景需要不同的编码时间，在这种方法中我们需要可预测的（或有限的）编码时间。 可变的输入 GOP 大小 可变的输入 GOP 大小是这个方法的巨大问题，因为大块的转码时间应该是可预测的（或有限的）。 音频提示 为了正确地解码音频，在一些编解码器中，我们需要来自前几块的样本。
总结
分布式是很好的选择； 需要可靠的基础工具来，如存储、可靠的提示； 只是概念证明，目前不可商用。
文章来源：媒矿工厂