从0到1搭建一个直播平台之编解码、播放器及延迟篇(构建Myntra视频平台2)

这是 “构建 Myntra 视频平台 “系列的第二篇文章。在上一篇文章中，我们介绍了流媒体的类型和现有的各种技术，以及最适合当今时代的技术。在本文中，我们将深入探讨编码器和解码器、客户端播放器的种类、玻璃到玻璃的延迟、流安全性以及可用于摄取的协议等方面的问题。

视频点播 (VOD) 与直播

了解视频点播（VOD）与直播体之间的区别非常重要。通俗地说，VOD 就像预先录制的内容，它允许用户随时随地观看视频内容。直播允许用户实时观看内容创作者的内容。

VOD 和直播体验都可以通过 HLS 实现。两者的清单文件略有不同。主播放列表继续保持不变，但媒体播放列表略有不同。

VOD 的媒体播放列表有一个 #EXT-X-ENDLIST 标签。同样，对于直播流，媒体播放列表文件也会不断变化。媒体播放列表描述了当前活动的视频片段。它有一个称为 “播放列表长度 “的东西。播放列表长度被定义为媒体播放列表可包含的最大片段或条目数量。随着直播流的继续，新的片段会不断加入，直到播放列表的长度被突破，此时旧的片段会不断被删除。点播播放列表的长度不适用，它包含所有片段的条目。

EXT-X-MEDIA-SEQUENCE 属性在直播中不断变化。该属性表示从直播流开始的媒体片段索引。

Segment Alignment(段对齐)

为了让直播流正常运行，必须确保各片段之间完全对齐，以便玩家可以在流之间移动。

Bitrate Ladder(比特率阶梯)

正如我们在上一篇文章中所讨论的，在 ABR 中，客户端会根据网络质量、视频类型和大小等在不同比特率之间切换。在 HLS 中，比特率梯与主播放列表相对应。每种比特率都定义了网络质量、视频大小等，客户端可根据需要进行选择。详情请参阅上一篇文章中的主播放列表部分。

网上有很多可以立即使用的比特率梯形示例。虽然这些比特率梯子效果不错，但用户的体验可能并不理想。

需要注意的一些重要事项包括：

提供的内容

在定义比特率阶梯时，内容起着非常重要的作用，例如，体育内容会有很多关键帧的快速运动，可能需要较高的比特率，而没有太多运动的脱口秀节目也可能需要较低的比特率。因此，对于给定的视频尺寸（如 480p、720p、1080p 等），如果是后者，则可以用更低的比特率来包装视频。

目标受众

了解用户使用的设备和互联网类型非常重要。您可以提供 4K 质量，但如果您的大多数用户使用的是慢速 4G 网络，他们可能无法从中获益。在生成比特率和存储时也会浪费 CPU。如果目标受众的网络速度较慢，那么您可能需要在较低的速度范围内提供更多的比特率，这样他们就能从切换中获益。

内容空间

此外，如果您希望视频显示在应用程序或网站的一小部分内容中，并且没有启用全屏等功能，那么您可能需要在比特率上坚持使用较低的视频分辨率，因为在较小的空间中，客户不会从较高分辨率中受益。有些客户很聪明，他们会根据需要播放视频的空间来选择视频质量，但有些客户可能不是这样。在这种情况下，客户端最终会浪费带宽。因此，勤奋点是有帮助的。

除上述内容外，还需注意以下几点

• 比特率过高也没有用，比特率越高，转码器需要处理的内容就越多。可能需要根据需求进行详细评估，但通常可以保留 4-5 种比特率。
• 另外需要注意的是，音频或视频参数在整个过程中需要保持一致，例如 480p 的视频不能突然改变音频格式等，需要在整个过程中保持一致。

基于以上所述，我们根据平台上提供的不同内容定义了自定义比特率阶梯。

编码器和解码器

编码是将包含大量数据的原始视频压缩成较小格式的过程，从而减小体积。解码本质上与编码相反。解码器将编码后的视频转换成客户端播放器可以使用的格式。

视频编解码器

视频编解码器是压缩和解压缩数字视频的软件或硬件。

在 VOD 和直播流中，最常用的编解码器包括：

• H264 / AVC
• H265 / HEVC
• VP8
• VP9
• AV1
• VVC

目前支持最多的是 H264。H265 的视频编码时间几乎是 H264 的 4 倍。VP9 也是如此。由于 CPU 负载更大，它不太适合用于实时流。VP9 也一样。

AV1 是谷歌推出的新编解码器。其 CPU 负载比 VP9 和 H265 高得多，几乎是它们的 10 倍。编码器仍在构建中，随着编码器的成熟和设备中开始使用 HW 编码器，这一数字可能会下降。就目前的数字而言，这绝对不适合用于实时流，因为编码时间最终可能远远超过视频段的持续时间。VVC 是另一种新的编解码器。Netflix 已经在有限的范围内为一些影片尝试使用 AV1 编解码器。

音频编解码器

最流行的包括：

• AAC
• Opus
• Vorbis
• MP3

AAC 是最流行的格式，支持范围最大。Opus 是最优化的编码器，但支持范围较小。

编码器的选择取决于客户端的解码器。

HLS 支持 H264 和 H265。H265 虽然压缩率更高，但并非完全免费，因此我们选择使用前者。在音频编解码器方面，我们选择了 AAC。

硬件与软件

编码器

硬件编码器经过优化，运行速度极快。好的硬件编码器通常非常昂贵。如果要改变编解码器的选择，就需要购买另一个硬件。如果编解码器的规格或更新版本发生变化，而新的变化又不被硬件所支持，则可能需要更换硬件。软件编码器可以经常更新。功能强大的硬件编码器可用于对性能要求极高且不考虑价格的特殊应用场合。

在编码器方面，我们使用的是软件编码器，我们计划将来也尝试使用硬件编码器。

解码器

移动设备、笔记本电脑和台式机都装有硬件解码器。如果有编码解码器的硬件解码器，应首选硬件解码器，而不是基于软件的解码器。硬件解码器可以减轻设备 CPU 的负担。它能提供更好的性能。大多数安卓设备都内置了 AVC、HEVC、VP8 和 VP9 硬件解码器。不过，在某些情况下，例如 AV1，由于它是一种新的编解码器，目前的设备中还没有硬件解码器。安卓 10 以后的设备都有软件解码器。因此，AV1 CPU 将使用软件解码器。

软件工具

• FFmpeg

FFmpeg 是一款根据 GPL 许可的免费开源工具。它是目前最流行的工具。

• Bento

另一种选择，缺乏像 Ffmpeg 这样的社区支持，功能有限。

我们使用 ffmpeg。

播放器

• 在安卓系统上，ExoPlayer 是事实上的播放器。https://exoplayer.dev/
• 在 iOS 上，AVPlayer 是事实上的标准。https://developer.apple.com/documentation/avfoundation/avplayer。

Web堆栈上有多种播放器：

• Safari 浏览器在 iOS 和 macOS 中提供 HLS 本机播放功能。
• Windows 也支持 HLS。
• VideoJs、hls.js 和 Shaka 播放器是其中一些流行的播放器，而 Video.js 是最流行的播放器。

客户端如何播放播放列表

客户端将获得主播放列表的链接。主播放列表中的第一个媒体播放列表条目是要播放的默认播放列表。如果播放列表开头的视频质量较低，则意味着视频加载时间较短，但提供的视频质量可能不是最好的。

客户端从媒体播放列表的开头开始。

在获取资源时，客户端会不断测量网络速度。这有助于决定从哪个播放列表继续获取内容。如果客户端发现网速下降，且网速低于播放列表中提到的带宽参数，它就会选择另一个播放列表。当条件发生变化时，它就会更改播放列表。客户端要确保填满一定的缓冲区。即使出现暂时的网络中断等情况，缓冲区也能让它继续播放视频。

特定平台的细微差别

对于实时流，存在特定平台的细微差别，这可能随播放器版本的不同而变化。

• 在安卓平台上，ExoPlayer 会在变化的媒体播放列表中选择倒数第 3 个条目。这曾是苹果的旧建议，他们建议有 3 段缓冲区。
• 而 AVPlayer 则会选择倒数第 2 个元素。
• Exoplayer 和 AVPlayer 都会根据媒体片段的目标持续时间来选择播放列表。

在后端方面，应尽一切努力确保具有恢复能力，并正确进行故障切换。这将在后续文章中介绍。

客户端可能会看到一些错误，如：

播放列表未更新

• 每个媒体播放列表都应根据所定义的媒体分段时间频繁更新。
• 客户端播放器会轮询并填充其缓存。轮询频率视上述情况而定。
• 如果播放器发现媒体播放列表没有更新，它会重试几次，然后抛出错误提示播放列表未更新。

播放列表重置

• HLS 建议媒体序列应始终按递增顺序排列，播放列表中的媒体序列号也不应减少。
• 由于某些故障或其他原因，媒体播放列表被重新生成或播放列表中的媒体序列号意外更新为较低的数字时，播放器可能会出现一些错误。

直播流程

在典型的实时流中，不同的步骤包括输入、流分割、转码、分发和最后的客户端回放。

步骤顺序如下：

• 第一步是从输入源获取视频。该视频被送入流分割步骤。
• 流分割步骤将连续的视频流分割成较小的视频段。然后将这些小的视频段输入转码器。
• 转码器根据系统中定义的比特率阶梯，将这些小的视频段转换成不同的视频质量。
• 然后将转码后的视频片段推送到 CDN 摄录服务器上。
• 根据 CDN 基础设施的不同，摄取服务器会将内容推送到多个服务器，一直到边缘服务器。
• 边缘服务器将内容提供给客户端。

玻璃到玻璃的延迟

玻璃到玻璃延迟是指从拍摄内容到观众在设备上观看内容的总延迟时间。第一块玻璃是摄像机镜头，另一块玻璃是观看者的设备，因此称为玻璃到玻璃延迟。

• 输入

一帧的最小延迟始终存在，但这个数字非常小。例如，在 30fps 的视频中，单帧的延迟数为 1/30。如果在捕捉视频时使用了任何软件或硬件，则可能会引入延迟。如果芯片运行一些图像优化/视频稳定滤波器，也可能会增加一些延迟。

• 段生成

如果输入是连续的数据流，在进行转码之前，可以将获得的输入分割成多个片段。延迟时间等于分段的持续时间。分段越大，延迟越大。1 秒以下的分段尺寸需要不同的技术。我们将在超低延迟部分进行讨论。

• 转码

这是将单个视频段转换为多个比特率的 ABR 流的过程。这种延迟可能取决于系统的快慢。如果延迟超过持续时间的大小，那么就会出现问题，因为播放列表在客户端的更新速度不会太快，从而导致播放器在等待内容更新时出现错误或显示缓冲图标。

• 网络

完成转码步骤后，转码后的片段需要发送到 CDN 主摄取服务器。这会增加延迟。

• CDN 传播：主服务器到边缘服务器

主 CDN 服务器将片段传播到所有边缘服务器。客户端与边缘服务器交互。

• 播放器缓冲

播放器缓冲 2-3 段大小的内容。这一步是增加延迟的主要原因。对于 HLS，很多播放器会选择播放列表中倒数第 3 个片段。这意味着会出现 3 * 片段大小的延迟。如今，一些播放器会选择倒数第 2 个片段，即 2 * 片段延迟。

超低延迟技术

对于大多数用户来说，传统的 HLS 运行良好，可以在上述各个方面进行改进，以控制延迟。但在某些情况下，可能需要非常低的玻璃到玻璃延迟，在这种情况下可以使用下面提到的技术。我们的使用案例没有这样的要求，因此使用了前者。

CMAF

通用媒体应用格式（CMAF）于 2017 年苹果和微软联手推出。CMAF 依赖于片段式 MP4，MPEG-DASH 曾使用过片段式 MP4，后来的 HLS 版本也增加了对片段式 MP4 的支持。CMAF 建立在 HLS 和 DASH 的基础之上。CMAF 片段可同时通过 HLS 和 DASH 提供，即可以进行跨复用。

共有 3 个结构：

• CMAF 轨道
• CMAF 片段
• CMAF 块

CMAF 片段是 CMAF 轨道的一部分。 CMAF 块是 CMAF 轨道的一部分。连续的 CMAF 块流通过线路发送到客户端播放器。在此模式下，与延迟是段长度的倍数的常规 HLS 或基于 DASH 的方法不同，这里的延迟是 CMAF 块的倍数。一般块持续时间从 0.5 秒到 1 秒不等。理论上，一个块可以小到单帧，即 30fps 相当于 33ms 的块。

苹果LLHLS (ALLHS)

部分片段

现在，播放器可以在片段播放完毕前获取部分片段。这些片段的时长约为 250-300ms。这些片段将包含许多视频和音频帧。要实现这一点，需要支持 HLS 规范第 9 版。

HTTP/2 推送片段

在 HLS 和其他 ABR 技术中，播放器一直在轮询播放列表和媒体片段。为了获取媒体片段，播放器首先会获取播放列表，然后在发现内容已更新时，会对媒体片段进行第二次网络调用。苹果建议，每当客户端获取媒体播放列表时，任何新添加的内容都可以与更新的播放列表一起推送。

阻止请求/延迟响应

客户端可以选择在内容生成之前请求播放列表和内容（并等待）。在这里，Http 请求被保留在服务器端。因此，如果客户端正在播放一个媒体片段，并试图获取播放列表以查看是否有更新的内容。服务器会保留请求并等待新内容生成和存储。一旦内容准备就绪，服务器就会发送播放列表和内容。

Delta 更新

HLS 播放列表可能非常庞大。为了获取最新内容而反复多次获取播放列表及其内容是一种浪费。为了缓解这一问题，Apple 引入了 Delta 更新。在这里，客户端只需获取一次完整的播放列表。之后，玩家就可以申请 Delta 播放列表。Delta 播放列表包含完整播放列表的一些最新片段和片块。

更快的比特率切换

在获取播放列表时，客户端也可以选择请求其他媒体播放列表。这样，客户端就可以在不请求其他播放列表的情况下切换到其他播放列表。这对于超低延迟的情况尤其有用。

低延迟 HLS (LHLS)

这项技术在 ALLHLS 之前就已存在。不过，这是一种非正式的规范，采用的人很少，而且并非所有地方都支持，尤其是 iOS 系统不支持这种技术。它与 CMAF 类似。

流安全性

• 来源屏蔽（Origin、CORS、Referrer）

为了确保我们的视频不会被放到其他网站上，我们需要确保请求来源的 Referrer 或域是正确的。CORS 策略在这方面会有所帮助。只有某些域名可以被列入白名单，因为我们相信这些域名会显示或共享视频。

• iFrame 阻止

另一个可能出现的问题是，人们使用 iFrame 嵌入我们的视频，从而规避了起源屏蔽。可以使用基于 Javascript 的代码和标题选项（如 X-Frame-Options）来阻止这种情况。

• 基本令牌

基本上不允许直接访问资源。url 中的令牌决定我们是否可以访问资源

index.m3u8? token=SOME_TOKEN_HERE&expiry=EXPIRY_TIME

• 用户专用令牌

每个用户都有一个特定的令牌。该令牌用于验证。令牌可以在标头、查询中提供，也可以作为路径参数提供。有些客户端播放器（如 iOS）不提供在标头中添加这些属性的简便方法，因此其他两个选项可能更受欢迎。

• 流加密

媒体段使用 AES 加密。一般情况下，流解密密钥会在播放列表中提供。不过，一个能使其更安全的改变是使用安全 API 单独提供解密密钥。这样，只访问媒体播放列表将无济于事，而且还多了一层安全保障。

• DRM （数字版权管理）

DRM 由外部系统维护。解密密钥单独保存。一些流行的解决方案包括 Widevine、Fairplay 等。DRM 解决方案通常成本较高。安卓系统的 Exoplayer 对 Widevine 有很好的支持，但目前缺乏对 Fairplay 的支持，而 iOS 系统则相反。根据使用情况，您可能需要也可能不需要。

编码器的视频输入

目前流行的两种格式是 WebRTC 和 RTMP。

RTMP 是一种流媒体协议，在整个播放过程中，播放器和服务器之间保持着持久的 TCP 连接。与 HLS 不同，RTMP 采用推送模式。服务器不需要播放器请求每个片段，而是持续发送视频和音频数据。客户端仍可在播放者提出请求或播放器不可见时发出暂停和恢复命令。在 RTMP 中，广播被分成两个流：视频流和音频流。流被分成 4 KB 的块，可在 TCP 连接中复用，即视频和音频块交错。在视频比特率为 500 Kbps 的情况下，每个片段的长度仅为 64 毫秒，与每段 3 秒的 HLS 片段相比，所有组件的流媒体传输都更加流畅。广播公司可以在对 64 毫秒的视频数据进行编码后立即发送数据；转码服务器可以处理该数据块并产生多种输出比特率。然后，该数据块通过代理转发，直至到达播放器。推送模式加上小块传输，可将广播公司和观众之间的延迟时间缩短 5 倍，从而带来流畅的互动体验。大多数直播流产品都使用 HLS，因为它基于 HTTP，易于与所有现有的 CDN 集成。

RTMP

优点

• 围绕它有很多工具、实施方案和生态系统
• 广泛的平台支持
• 用于直播摄取

缺点

• 这是由 Macromedia 开发的一个非常古老的协议，后被 Adobe 收购，主要用于 Flash 应用程序中
• 延迟约为 4 秒
• 技术过时，正在被淘汰
• RTMP 不支持现代浏览器

WebRTC

优点

• 这是一个新的协议，比较普及
• 可有多个参与者
• 在过去两三年中已在主要浏览器中实现
• 支持 UDP 和 TCP
• 还实现了基于 Websockets 的低延迟消息传递系统。
• 我们实际上可以称之为实时或超低延迟。小于 200 毫秒
• 默认支持加密
• 为Android、Web和 iOS 提供本地官方 SDK。

缺点

• 过去，每个浏览器都有自己的应用程序接口，但不幸的是，这些应用程序接口并不遵循 W3C 标准。但现在已经逐渐标准化了。

WebRTC 还允许我们举办有多位发言人参加的视频会议，并使直播脱口秀成为可能，这是 RTMP 无法提供的。

综上所述，我们决定继续使用 WebRTC。

本系列文章的第二部分到此结束。在下一篇文章中，我们将更详细地介绍 WebRTC。

作者：Shikhar Shrivastav