视频的工作原理

看起来似乎很明显，但是“播放”一词中却包含了很多内容！视频播放器的用户界面是大多数人与播放相关联的第一件事，因为它是每当他们在网站或平台上观看视频时，他们看到的内容最多并与之互动最多的内容。播放器控件中使用的图标和颜色对于最终用户来说可能是最可见的，但这只是回放冰山一角。

播放器控制或显示播放的其他重要方面，而不仅仅是控件本身。它的功能包括字幕和字幕，用于控制播放的程序化API，用于钩挂客户端分析，广告等功能的功能。

也许最重要的是，现代视频平台将使用所谓的自适应比特率流传输，这意味着它们提供了几种不同版本的视频（也称为演绎）供播放器选择。这些不同的版本在显示大小（分辨率）和文件大小（比特率）方面有所不同，并且播放器选择了它认为可以流畅播放而不需要暂停的最佳版本，从而可以加载更多视频（缓冲）。关于如何以及何时切换到不同版本，不同的播放器会做出不同的决定，因此播放器可以对观众的体验产生很大的影响！

您可能会记得在Netflix或Youtube上观看视频，并注意到有时在视频中间，质量会在几分钟内变差，然后突然变好。这就是当质量发生变化时您正在经历的自适应比特率流式传输。如果您正在通过Internet进行任何类型的视频流传输，则您的解决方案必须支持此功能，否则，该功能可能会导致大量观众无法流传输您的内容。

虽然这个概念（和整个规范）可能令人生畏，但HLS背后的基本概念却非常简单。即使该术语代表“ HTTP实时流”，该技术也已被用作按需播放视频的标准方式。您将一个大视频文件分成小段，可以在2到12秒之间的任何时间。因此，如果您有一个两小时长的视频，分成10秒的片段，那么您将有720个片段。

每个段都是一个以.ts结尾的文件。它们通常是按顺序编号的，因此您将获得一个如下所示的目录：

播放器将在用户流式传输时下载并播放每个片段。并且播放器将保留分段的缓冲区，以防以后丢失网络连接。

现在，让我们将这个简单的HLS想法更进一步。我们在这里可以做的是以不同的形式创建段文件。在上面的示例中，使用2小时长的视频和10秒的片段，我们可以创建：

现在，这种情况开始变得很酷，正在播放我们的HLS文件的播放器可以自行决定它要消耗哪种音色。为此，播放器将尝试估算可用的带宽量，然后将对其要下载并向您显示的演绎形式做出最佳猜测。

最酷的部分是，如果播放器可用的带宽量发生变化，则播放器可以快速适应，这称为自适应比特率流传输。

由于各个片段文件是分解成小块的实际内容，因此清单文件（也称为播放列表文件）的工作就是告诉播放器在哪里可以找到该片段文件。

有两种不同的清单文件。对于单个视频，有一个主清单和多个移交清单。主清单文件是播放器的第一个联系点。对于浏览器中的HTML播放器，主清单是作为播放器上的src =属性加载的内容。主清单将告诉玩家每一次演绎。例如，它可能会说：

我有一个1080p复制，每秒使用2,300,000位带宽。它使用的是这些特定的编解码器，该清单文件的相对路径为＆＃34; manifests / rendition_1.m3u8”。

我有一个720p复制，每秒使用1,700,000位带宽。它使用的是这些特定的编解码器，该清单文件的相对路径为＆＃34; manifests / rendition_2.m3u8”。

我有一个360p复制，每秒使用900,000位带宽。它使用的是这些特定的编解码器，该清单文件的相对路径为＆＃34; manifests / rendition_3.m3u8”。

当玩家加载主清单时，它会观察所有可用的演绎并选择最佳的。继续此示例，假设我们的播放器选择了1080p分辨率，因为该播放器有足够的可用带宽。因此，现在该加载再现清单了（＆＃34; manifests / rendition_1.m3u8＆＃34;）

演绎清单看起来与母版有很大不同。它将具有一些元数据和指向每个单独段的链接。请记住，从上至上的片段是视频内容的实际片段。在我们的2小时长视频示例中，该视频分为720个片段，每个片段10秒。 rendition_1.m3u8清单将具有720段文件的有序列表。如人们所料，对于较长的视频，此文件可能会变得很大：

找出可用的演绎形式，然后选择最佳的演绎形式（基于可用带宽）

DASH采用与HLS相同的策略。一个视频文件分为不同分辨率的小段。 DASH播放列表文件的格式是XML，而不是HLS中的纯文本。 DASH清单如何告知播放器在哪里可以找到每个段文件的细节有些不同。 DASH清单提供了一个＆＃34; SegmentTemplate“值，而不是专门链接到每个段，该值告诉玩家如何为每个段计算特定的链接。

无论使用HLS还是DASH，它们都带给表的最大好处是清单文件和段都是通过标准HTTP传递的。具有可在标准HTTP上运行的流格式，意味着所有这些内容都可以在经过尝试的真实HTTP服务器上提供，并且可以缓存现有的CDN基础结构。移动所有这些视频内容就像发送和接收HTTP请求一样简单。

对于HLS和DASH而言，由于我们正在创建内容的所有这些不同格式，因此播放器可以逐段实时地适应不同格式。

例如，开始时，播放器可能具有很大的带宽，因此它将以可用的最高分辨率（1080p）开始流式传输。在开始的5分钟内，串流运作顺利。在最初的5分钟结束时，互联网连接可能会开始受到影响，现在可用的带宽越来越少，因此，只要需要，播放器就会降级为360p。然后，当更多带宽再次可用时，播放器将逐渐变回更高的分辨率。

所有这些分辨率切换完全取决于播放器。使用合适的球员可以带来巨大的变化。

让我们举一个真实的例子。您在移动设备上打开Netflix，并决定连续第11次观看The Office。滚动并选择自己喜欢的剧集（第2季第4集）并点击播放后。

现在玩家开始游戏，您会看到一个红色的微调器。看到红色微调框时，场景背后的情况是播放器正在向Netflix的服务器发出HTTP请求，以确定该视频可用的分辨率。接下来，播放器将运行带宽估计算法，以了解您的互联网连接的强度。现在，您处于良好的wifi连接状态，因此播放器将以屏幕尺寸可用的最高再现率开始播放。

当您观看23分钟的《办公室》剧集时，播放器正在后台努力工作，以跟上您的流媒体播放。假设您去散散步并离开WiFi，现在您正在使用蜂窝网络，并且信号不强。您可能会注意到，有时视频会变得模糊一些，然后恢复。在视频变得模糊之前，播放器确定没有足够的带宽来保持高再现流，因此它有两个选择（1）缓冲区，即暂停视频并显示加载微调框，让您在下载时等待细分更多（2）降低分辨率，以便您继续观看。一个好的玩家会选择2号：最好给您一个较低的分辨率，而不是让您等待。

玩家的目标始终是为您提供尽可能高的翻译效果，而无需您等待。

MP4和WebM格式就是我们所说的伪流或“渐进式下载”。这些格式不支持自适应比特率流传输。如果您曾经使用过HTML＆lt; video＆gt;元素，并添加了一个直接指向mp4的＆＃34; src“属性，而不是您正在执行的操作。当直接链接到文件时，大多数播放器将逐步下载该文件。关于渐进式下载的好处是，您无需等待播放器就可以下载整个文件，然后再开始观看。您可以在后台下载文件的同时单击播放并开始观看。大多数播放器还将允许您将播放头拖到视频时间轴中的特定位置，并且播放器将使用字节范围请求来估计文件的哪一部分与您尝试查找的视频中的位置相对应。

使MP4和WebM播放出现问题的原因是缺乏自适应比特率支持。每个观看您内容的用户都必须有足够的带宽来下载文件，而不是播放文件。使用这些格式时，您经常需要在提供需要更多带宽的高分辨率文件（从而以较低带宽锁定用户）与提供更低分辨率文件且需要较少带宽（因此不必要地降低带宽）之间进行权衡高带宽用户的质量）。随着越来越多的用户通过蜂窝连接从移动设备流式传输视频，这正变得尤为重要。众所周知，蜂窝连接不稳定且不稳定，向这些设备可靠传输的方式是通过支持自适应比特率流传输的格式进行的。

市场上几乎可以选择HLS和DASH的播放器。有些是免费和开源的，有些是付费的，并且需要适当的许可才能使用。每个播放器都支持不同的功能，例如字幕，DRM，广告注入和缩略图预览。选择播放器时，您需要确保它支持所需的功能，并允许您自定义UI元素以足以控制外观。这些都是您在浏览器中进行基于Web的播放，在iOS和Android或将要传输内容的任何其他操作系统上进行本机应用播放时需要做出的所有决定。

对于视频交付，目标始终保持不变：尽可能快地交付视频片段，以避免缓冲并确保不间断的观看体验。

正如我们在“播放”部分了解到的那样，任何支持自适应比特率（ABR）的视频播放器都旨在提供最高质量的视频而不会受到干扰。为了实现此目标，存储视频内容的系统必须尽可能快地交付它。

视频内容可以包括分段的传送文件，例如TS分段（用于较旧的HLS传送），MP4片段或用于DASH和现代HLS的CMAF块。至于负责交付内容的系统，有两个主要组件：原始服务器和内容交付网络（CDN）。

作为视频开发人员，起源就是您的真理之源。在这里，您可以上传原始视频文件，并在其中下载CDN等其他系统组件，以帮助您更快地交付视频内容。

您可以直接从原籍交付视频内容，但是如果观众众多且分散，这不是一个好主意。在这种情况下，CDN可以帮助您扩展服务范围，从而将视频更快地分发给许多观众。

下面，我们将讨论CDN和其他系统组件，这些组件负责我们所有人都期望的流畅流媒体体验。

在深入探讨有关CDN和视频流的更多技术细节之前，让我们将CDN概念分解为一个简单的类比。

单个视频服务器（即原始服务器）响应来自多个区域的流式传输设备的大量请求，就像单个收银员响应多个服务线中来自客户的大量购买请求一样。就像收银员承受压力一样，视频服务器也是如此。当事情承受压力时，它们往往会放慢速度或完全关闭。 CDN阻止了这种情况的发生，特别是对于在分散的受众群体中流行的视频内容而言。

用更多的技术术语来说，CDN是遍布全球的互连服务器系统，该系统使用地理邻近性作为向观看者分发缓存内容（例如分段视频文件）的主要标准。当观看者从其设备请求内容（即单击视频播放按钮）时，该请求将被路由到内容交付网络中最近的服务器。

如果这是对该CDN服务器的第一个视频片段请求，则服务器会将请求转发到存储原始文件的原始服务器。原始服务器将使用请求的文件响应CDN服务器，并且除了将文件传递给查看器之外，CDN服务器还将在本地缓存（即存储）该文件的副本。现在，当将来的观众请求相同的文件时，将绕过原始服务器，并立即从本地CDN服务器提供视频。

考虑到Internet主要由埋在地下和水下的光纤组成，因此视频服务器的位置为什么很重要是有道理的。例如，亚洲的观看者想要从位于美国的原始服务器流式传输内容，则由于该请求必须跨越大洋和大陆旅行，因此会遇到较差的加载时间。但是通过CDN，视频几乎总是从亚洲的CDN服务器提供的。这些存储缓存的视频内容的位置称为存在点（PoP）。

此时，通过CDN改善观看者体验的商业案例应该很有意义。通过从本地缓存中获取视频，观看者不必等待数百毫秒即可观看要开始播放的视频。如此长的响应时间实际上是不明显的，它创造了一种鼓励观众留在视频播放平台上的体验。

从成本角度来看，从成本角度来说，提供带有CDN的视频可显着降低带宽成本，因为内容不必走得太远。从本地缓存交付内容所需的网络压力较小，与数据传输效率相关的较低成本也传递给了视频提供商。想象一下，如果从一台服务器处理来自世界各地的请求，那么所有的网络开销！

另一个业务案例涉及正常运行时间和可靠性。 CDN的流量容量超过大多数普通企业网络功能。如果由于意外的流量高峰而无法提供自托管视频，则CDN分布更广，在流量高峰期间保持稳定。因此，内容交付网络也称为内容分发网络。

在谈论内容的传播方式（以及互联网的运行方式）时，通常使用术语“第一英里”，“中英里”和“最后一英里”。

第一英里：当内容从原点传播到CDN时。例如，当观众首次请求位于Amazon S3之类的原始服务器上的视频内容时，会将其发送到StackPath之类的CDN。此内容使用Internet骨干网作为高速公路从源头传播到CDN。该骨干网由不同公司拥有的各种网络组成，这些网络使用称为对等协议进行链接。

中英里：内容从CDN传输到ISP时。将视频内容缓存在CDN中之后，它可以直接连接到观众用来连接到Internet的Internet服务提供商（ISP）。通过与Veriszon和Comcast等1级网络运营商的直接连接，CDN可以提供企业级的性能，并在公共互联网常见的网络拥塞和天气原因中断的情况下路由流量。

最后一英里：当内容从ISP传播到最终用户时。此时，视频内容正在通过地下光纤，电话线或蜂窝塔传输，以将其传输到观看者的设备。

关于互联网的这些各个部分如何通信，最常用的语言是HTTP协议。这被定义为GET方法下的无状态协议，这意味着内容在旅行时不会改变。

考虑到这一点，具有数十个甚至数百个位置的CDN不需要这些位置的服务器相互通信以确保其具有正确的视频内容。只要每个服务器都从源中获取视频内容，每个观看者都会收到相同的视频，无论他们在世界上的位置如何。

在多CDN环境中，目标是在两个或多个CDN之间分配负载。多CDN使您可以根据业务需求将用户请求定向到最佳CDN。

在下图中，有三个CDN提供程序A，B和C。CDN提供程序A为用户1和2提供了出色的服务，而CDN提供程序C为用户3提供了更好的体验。在多CDN环境中，用户1和2的请求可以定向到CDN A，用户3的请求可以定向到CDNC。

取决于技术，选择最佳CDN可以基于许多标准：可用性，地理位置，流量类型，容量，成本，性能或上述各项的组合。诸如NS1之类的服务使这种类型的路由成为可能。

多CDN是Mux自己使用的东西。例如，在2019年6月，Verizon做出了错误的路由公告更新，该更新通过宾夕法尼亚州的一家小型ISP引导了大部分互联网流量。对于多CDN设置中的某些大型CDN，这会导致严重的网络拥塞并降低性能。通过使用CDN切换，Mux能够将大多数视频流量转移到StackPath的CDN，并在停机期间继续提供最佳的观看性能。

通过使用各种内容交付网络，Mux正在将HTTP实时流（HLS）延迟降低到可能的最低水平，并且在交付每英里的过程中与最佳服务合作对于支持这一持续目标至关重要。