从0到1搭建一个直播平台(构建Myntra视频平台1)

分享来自 Myntra 的国外工程师 Shikhar Shrivastav 撰写的如何搭建一个直播平台的系列文章。本文是 “搭建 Myntra 视频平台 “系列的第一篇文章。

前言

全球人们消费内容的方式正在发生迅速变化。人们只满足于图片的时代已经一去不复返了。人们已经从图片过渡到了长视频、短视频和 GIF。通过 4G 上网的便捷性和低廉的数据成本使视频消费不再是奢侈品，而是必需品。而 5G 等技术将进一步推动这一行为。Netflix、Instagram、TikTok 和 Youtube 等互联网第一公司的成功主要依赖于其先进的视频功能。

根据 Youtube 的调查，”每两个 Z 世代和千禧一代中就有一人表示，如果没有视频，他们不知道该如何度过生活”。

作为有影响力内容的先驱和领跑者，Myntra 在几年前战略性地决定加强其视频功能，以更有效地吸引消费者。

Myntra 利用一流的产品和技术团队的才能，在内部建立了专有技术。为处理视频点播 (VOD) 和直播流使用案例而创建的系统被称为 Matrix。

去年年底，我们还推出了 M-live，进军实时流媒体领域。该功能允许用户在 Myntra 应用程序上观看最受追捧的有影响力人士的时尚和美容直播。

为什么要自己建造？

• 更好地控制整个用户体验
• 为我们的用户提供最佳性能
• 降低运行直播流的成本，因为随着我们不断扩大规模，成本只会不断增加。
• 最后，相信我们有能力、才能和实力完成这项工作。

让我们开始吧！

流媒体类型

有两种类型的流技术，即顺序流式传输和自适应比特率流。顺序流式传输最初很流行，后来被高效的自适应比特率流媒体（ABR）所取代。与顺序流式传输相比，ABR 具有许多优势。

顺序流式传输(Progressive Streaming)

在互联网的早期，MP4 等视频文件直接通过互联网提供。这被称为顺序流式传输。单个文件可在台式机、笔记本电脑、平板电脑和移动设备上播放。

主要问题是：

• 对于大屏幕来说，视频太小
• 如果网络速度不够快，尤其是移动设备，视频可能会偶尔停滞和缓冲
• 单个文件意味着在质量或体验上的妥协

自适应比特率流

自适应比特率流媒体（ABR）旨在解决渐进式流媒体无法解决的所有问题。ABR 不采用一刀切的方法，而是根据所用设备的屏幕尺寸和网络质量提供不同的视频质量。此外，单个设备不会受限于特定的配置，而是可以根据网络条件在不同的视频质量之间切换。这就实现了无缝和连续播放。

因此，如果有人在旅行，网络质量发生变化，视频质量也会相应改变。如果网络质量较低，则会选择较低的质量；如果网络质量提高，则会选择较高的质量。

流媒体协议

RTMP（实时消息传输协议）

Macromedia 在 2000 年代中期开发了 RTMP（实时消息传输协议）。该协议专为流式传输音频和视频而设计，许多人将其简称为 Flash。Macromedia 后来与 Adobe 合并，后者现在将 RTMP 作为半开放标准进行开发。

在过去十年的大部分时间里，RTMP 是互联网上默认的视频流方式。但随着最近 HLS 的兴起，我们看到 RTMP 的使用率在下降。即使在今天，大多数流媒体视频托管服务仍使用 RTMP 摄取。换句话说，广播公司以 RTMP 流格式向其选择的在线视频平台传输流媒体。然后，在线视频平台通常通过 HLS 将这些流媒体传输给观众。

RTSP（实时流协议）

与 RTMP 类似，RTSP/RTP 也是一种有状态协议，用于视频贡献而非多设备传输。其延迟时间很短，约为 2 秒，但并没有对体验进行优化。

安卓和 iOS 设备没有开箱即用的 RTSP 兼容播放器，因此其采用率更低。

Adobe HDS（HTTP 动态流）

HDS 由 Adob​​e 制作。它是一种基于 ABR 的技术，旨在与 Flash 播放器配合使用。由于 Flash Player 本身已被弃用，因此不再使用它。

Microsoft Smooth Streaming（MSS）

Microsoft Smooth Streaming（MSS）是微软版本的实时流媒体协议。平滑流还使用自适应比特率方法，在任何给定时间提供最佳质量。

MSS 于 2008 年首次推出，是最早进入公共领域的自适应比特率方法之一。MSS 广受欢迎的原因之一是，2008 年夏季奥运会正是由微软使用这一平台转播的。目前使用最广泛的 MSS 平台是 Xbox One。不过，MSS 是目前不太流行的流媒体协议之一。

Apple HLS（HTTP 直播）

HLS从2009年就出现了，经历了多个版本。HLS 是自适应流媒体中最流行的技术。

MPEG-DASH

与HLS类似，由MPEG组大力推动。由于 Apple 的冷落，缺乏 iOS 支持。

WebRTC

WebRTC 非常适合双向通信，但在尝试扩展到几百个客户端时却存在严重问题。由于 WebRTC 的设计原因，要扩展到数千个客户端是一个巨大的问题。关于这一点，我们将在后面的章节中详细介绍。

选择协议的标准

选择一种或多种协议的标准取决于一系列参数。

用户体验和可靠性

如果不能提供良好的用户体验这一首要标准，那么所有的研究都无济于事。在这方面，RTMP 和 RTSP 等顺序式流媒体技术往往会失败。因此，我们需要采用基于 ABR 的技术，这样无论用户的消费平台、设备或网络状态如何，我们都能为用户提供良好的体验。

支持的编解码器

不支持流行编解码器的协议毫无意义。协议定义了共享视频或音频的方式，而实际的多媒体内容需要使用这些编解码器进行编码并发送。目前最流行的编解码器是 H264、H265、VP8 和 VP9。除此以外，AV1、VVC 和新发布的 MPEG-5 EVC 和 LCEVC 等编解码器也很有前途，尽管它们缺乏硬件解码器支持。因此，如果一个协议不支持流行协议中的一种或多种编解码器，显然是不能使用的。

支持不同平台

协议需要支持所有流行平台，如 Android、iOS 和 Web。如果一个协议与某一平台相匹配，而不能在其他平台上提供良好的支持，那么它就没有机会进行整体扩展。

CDN 合作伙伴的支持

CDN 是为用户提供多媒体内容的网络。它们具有良好的扩展性，协议需要得到主要 CDN 播放器的支持。

支持的延迟

大多数 ABR 技术都会在直播流中引入大量延迟。对于某些用例来说，延迟可能并不十分重要，但如果可能的话，我们应始终提供低延迟的直播流。

安全和 DRM 支持

应提供 AES 等安全机制和 DRM 支持。由于 Myntra 可能会与外部内容提供商合作，因此我们必须能够支持流行的 DRM。如果要建立合作伙伴关系，可能必须支持 DRM。

成本

运行直播的成本必须合理。

考虑到所有这些方面，在所有这些参数上运行良好的 2 个协议是 HLS 和 DASH。

HLS 和 DASH

相似之处：

• 两者都基于 ABR，都能提供良好的体验
• 支持主要编解码器
• HLS 支持视频编解码器： H264、H265
• DASH 与编解码器无关，支持所有主要编解码器
• 所有主要 CDN 提供商均支持
• 支持正常和低延迟
• 安全和 DRM 支持
• 两者均支持加密
• HLS 支持 Fairplay
• DASH 支持 Widevine，播放器目前不支持 Fairplay
• 成本：两者的成本都比较合理

差异：

• 主要区别在于 HLS 比 DASH 获得更多支持。
• HLS 在 iOS 设备上拥有原生/开箱即用的支持。
• 在 Android 和网络上，播放器也能正常播放内容。
• 在 iOS 上不支持 DASH，这是一个很大的遗憾。
• 在 Android 和 Web 上，播放器可以正常播放。
• DASH 比 HLS 支持更好的编解码器
• H264 是免费的，但压缩率更高的 H265 在 10 万台设备之前是免费的，超过 10 万台设备则需要支付版权费。大多数人坚持使用 H264
• DASH 使用谷歌流行的 VP8 和 VP9 编解码器。与 H265 相对应的 VP9 可免费使用。

由于 HLS 支持所有 3 个平台，因此得到了更广泛的采用。一些 OTT 平台同时提供 HLS 和 DASH，以支持更广泛的覆盖范围，并在支持的平台上通过 DASH 和 VP9 提供更好的视频压缩。预计 HLS 可能支持 AV1 或 VVC。我们尚未得到确认。

HLS 和 DASH 概念

让我们来了解一下这两个协议的基本概念：

HLS 的最初版本仅支持 MPEG-2 TS 容器。从 2016 年起，苹果开始支持片段式 mp4 (fMP4)。DASH 依赖于 fMP4。

有 3 种主要结构：主播放列表、媒体播放列表和媒体段

媒体段(Media segments)

输入视频流会被分割成更小的视频段。这些小段也可以单独播放。这些片段被传送到客户端。另一种方法是只使用一个文件，并将该文件的字节范围定义为片段。与后者相比，Ts 和 fMP4 的前一种方法更受欢迎，支持也更好。

媒体播放列表中的 #EXT-INF 属性传达了片段内容的持续时间。片段大小会导致延迟。后续章节将对此进行详细介绍。多年来，苹果公司对片段大小的建议已从 10 秒变为 8 秒，最后变为目前的 6 秒。

主播放列表(Master Playlist)

主播放列表文件就像一个注册表，它告诉客户端播放器根据多个参数（如视频大小和推荐的网络质量等）选择内容的一个变体。该条目包含指向另一个称为媒体播放列表的播放列表文件的指针。

在 HLS 中，这些播放列表文件被称为 M3U/M3U8 清单文件，而在 DASH 中则被称为 MPD 文件。它们还包含基于音频语言轨道或字幕的多种变化。

主播放列表中的第一个播放列表条目被视为播放开始时的默认播放列表。一般情况下，第一个条目被保留为比特率最低的播放列表。这样做是为了缩短加载时间。

媒体播放列表(Media Playlist)

如前所述，这些文件是从主播放列表中引用的。每个版本都有自己的媒体播放列表。这些媒体播放列表文件通常包含按顺序排列的文件条目。这些条目通常会提及文件的持续时间。

本系列第一部分到此结束。在第二部分中，我们将围绕 VOD、直播、编码器等话题展开讨论。