Web 上的视频播放：视频交付最佳实践（第 2 部分）

在我之前的帖子中，我使用 HTTP 存档中的数据检查了今天网络上的视频趋势。 我发现许多网站在移动设备和桌面设备上提供相同的视频内容，而且许多视频流的传输比特率太高而无法在 3G 速度连接上播放。 我们还发现，网站可能会自动将视频下载到移动设备上，这会损害客户的数据计划、电池寿命，因为这些视频可能永远不会播放。

TL;DR ：在这篇文章中，我们着眼于优化视频速度和向客户交付的技术，并提供 9 种最佳实践列表来帮助您交付视频资产。

视频播放指标

目前使用的主要视频播放指标有 3 个：

1. 视频启动时间
2. 视频停顿
3. 视频质量

由于视频文件很大，将视频优化为尽可能小将导致更快的视频传输，加快视频启动，减少停顿的数量，并最大限度地减少传输视频质量的影响。 当然，我们需要平衡启动速度和停顿与第三个质量指标（更高质量的视频通常使用更多数据）。

视频启动

当用户在视频上按下播放键时，他们希望能够快速观看视频。 根据 Conviva（视频指标分析的领导者）的数据，在 2018 年第一季度，14% 的视频在用户按下播放后从未开始播放（即 24 亿次视频播放）。

2.3% 的视频（4 亿视频请求）在用户按下播放按钮后无法播放。 11.54%（2B 播放）在按下播放后被用户放弃。 让我们尝试分解可能导致这些问题的原因。

视频播放失败

视频播放失败占所有视频播放的 2.3%。 什么可能导致这种情况？ 在 HTTP 存档数据中，我们看到 0.3% 的视频请求会导致 4xx 或 5xx HTTP 响应——因此某些百分比的 URL 错误或服务器配置错误。 另一个潜在问题（在 HTTP 存档数据中未观察到）是被 Geolocation 阻止的视频（根据观看者的位置和提供者在该区域显示视频的许可而被阻止）。

视频播放放弃

Conviva 报告指出，所有视频播放中有 11.5%会播放，但客户在视频开始播放之前就放弃了播放。 这里的问题是视频没有足够快地交付给客户，他们放弃了。 有很多关于移动网络的研究，其中长时间的延迟会导致网页被放弃，而且似乎视频播放也会出现同样的效果。

Akamai 的研究表明，观众会等待 2 秒，但随后的每一秒，就有 5.8% 的观众放弃视频。

那么是什么导致了视频播放问题呢？ 一般来说，较大的文件需要较长的下载时间，因此会延迟播放。 让我们看一下可以加快视频播放速度的几种方法。 为了减少启动时放弃的视频数量，我们应该尽可能“精简”这些文件，以便它们快速下载（并开始播放）。

MP4：视频预加载

为了确保在网络上快速播放，一种选择是提前将视频预加载到设备上。 这样，当您的客户点击“播放”时，视频已经下载，播放速度会很快。 HTML 提供了一个带有 3 个可能选项的预加载属性： auto 、 metadata和none 。

preload = auto

当您的视频使用preload="auto"交付时，浏览器会下载整个视频文件并将其存储在本地。 这可以大大提高视频启动的性能，因为视频在设备本地可用，并且没有网络干扰会减慢启动速度。

但是，只有在视频被观看的可能性很高时才应该使用preload="auto" 。 如果视频只是驻留在您的网页上，并且每次都被下载，这将为您的移动用户增加大量数据损失，并增加您将整个视频交付给所有用户的服务器/CDN 成本。

该网站有一个名为“视频库”的部分，其中包含多个视频。 本节中的每个视频都将 preload 设置为auto ，我们可以将它们在 WebPageTest 瀑布中的下载可视化为绿色水平线：

有一个版块叫做“视频库”，网站这小块版块的文件占页面下载量的 1460 万（83%）。 播放一个（许多）视频的几率可能非常低，因此使用preload="auto"只会为网站产生大量数据流量。

在这种情况下，即使其中一个视频也不太可能被观看，但所有视频都已完全下载，从而为移动网站增加了 14.8MB 的内容（页面内容的 83%）。 对于播放概率很高的视频（可能 > 90% 的页面浏览量会导致视频播放）——预加载整个视频是一个非常好的主意。 但是对于不太可能播放的视频， preload="auto"只会通过您的服务器和客户的移动（和桌面）设备导致额外的内容吨位。

preload="metadata"

当使用preload="metadata"属性时，会下载视频的初始片段。 这使播放器可以知道视频窗口的大小，并可能下载一到两秒钟的视频以立即播放。 浏览器只是对视频内容进行 206（部分请求）。 通过在设备上存储少量视频数据，可以减少视频启动时间，而不会对传输的数据量产生很大影响。

在 Chrome 上，如果未选择任何属性，则元数据是默认选择。

注意：如果视频很大，这仍然会导致要下载大量视频。

例如，在一个视频设置为preload="metadata"的移动网站上，我们只看到一个视频请求：

并且请求是部分下载，但它仍然导致要下载 2.7 MB 的视频，因为完整的视频是 1080p、150 秒长和 97 MB（我们将在下一节中讨论优化视频大小）。

因此，我建议preload="metadata"仅在用户观看视频的可能性很高或视频很小的情况下才使用。

preload="none"

最经济的视频下载选项，因为加载页面时不会下载视频文件。 这可能会增加播放延迟，但会导致初始页面加载速度更快最终用户明确要求。 在按下播放按钮之前，嵌入网站的所有 YouTube 视频都不会下载任何视频内容，本质上就像preload="none"一样。

预加载最佳实践：仅当视频被观看的可能性很高时才使用preload="auto" 。 通常，使用preload="metadata"可以在数据使用与启动时间之间提供良好的平衡，但应监控是否存在过多的数据使用。

MP4 视频播放技巧

既然视频已经开始播放，我们如何才能保证视频播放可以优化到不卡顿并继续播放。 同样，诀窍是确保视频尽可能小。

让我们看一些优化视频下载大小的技巧。 有几个视频维度可以优化以减小视频的大小：

声音的

视频文件被分成不同的“流”——最常见的是视频流。 第二个最常见的流是与视频同步的音轨。 在一些视频播放应用中，音频流是分开交付的； 这允许以无缝方式交付不同的语言。

如果您的视频以静音方式播放（如循环播放的 GIF 或背景视频），则从视频中删除音频流是减小文件大小的一种快速简便的方法。 在背景视频的一个示例中，完整文件为 5.3 MB，但音轨（从未听过）接近 300 KB（文件的 5%） 通过简单地消除音频，文件将快速传递，不会浪费字节。

在 HTTP 存档中找到的 42% 的 MP4 文件没有音频流。

最佳实践：从无声播放的视频中删除音轨。

视频编码

对视频进行编码时，可以选择降低视频质量（每帧的像素数，或每秒的帧数）。 将高质量视频缩减为适用于网络很容易，并且通常不会影响交付给最终用户的质量。 本文不够长，无法深入讨论可用于视频的所有各种压缩技术。 在x264和x265编码器中，有一个术语称为恒定速率因子 (CRF)。 使用 23-28 的 CRF 通常会提供良好的压缩/质量折衷，并且是进入视频压缩领域的良好开端

视频大小

视频大小会受到许多维度的影响：长度、宽度和高度（您可能也可以在此处包含音频）。

视频时长

视频的长度通常不是 Web 开发人员可以调整的功能。 如果视频要播放三分钟，那么它将播放三分钟。 在视频特别长的情况下，诸如preload="none"或流式传输视频之类的工具可以允许最初下载的数据量较少，以减少页面加载时间。

视频尺寸

在 HTTP 存档中找到的所有视频中有 18% 在移动设备和桌面设备上是相同的。 那些使用响应式网页设计的人知道如何针对不同的视口优化图像可以大大减少加载时间，因为对于较小的屏幕，图像的尺寸要小得多。

视频也是如此。 具有 30 MB 2560×1226 背景视频的网站将很难在移动设备上下载视频（也可能在桌面设备上！）。 调整视频大小会大大减小文件大小，甚至可能允许提供三个或四个不同的背景视频：

现在，不幸的是，浏览器不支持对 HTML 视频的媒体查询，这意味着这不起作用：

 <video preload="auto" autoplay muted controls source src="large.mp4" </video>

因此，我们需要创建一个小的 JS 包装器来将我们想要的视频传送到不同的屏幕尺寸。 但在我们去那里之前……

下载视频，但将其隐藏

对早期响应式网络的另一个回归是下载全尺寸图像，但将它们隐藏在移动设备上。 您的客户在下载大图像时会遇到所有延迟（并会影响移动数据计划，以及额外的电池消耗等），而实际看到图像并没有任何好处。 这种情况经常发生在移动设备上的视频中。 因此，当我们编写脚本时，我们可以确保较小的屏幕永远不会请求一开始就不会出现的视频。

视网膜质量视频

对于不同的设备屏幕密度，您可能有不同的视频。 这可能会导致将视频下载给您的移动客户的时间增加。 您可能希望阻止在较小屏幕设备或网络带宽有限的设备上播放 Retina 视频，从而回退到这些设备的标准质量视频。 网络信息 API 等工具可以为您提供网络吞吐量，并帮助您决定要为客户提供的视频质量。

根据设备大小和网络质量下载不同的视频类型

我们刚刚介绍了一些优化将电影传送到小屏幕的方法，并且还注意到视频标签无法在视频类型之间进行选择，所以这里有一个快速的 JS 片段，它将使用屏幕宽度来：

• 不在 500 像素以下的屏幕上投放视频；
• 为 500-1400 屏幕提供小视频；
• 向所有其他设备提供更大尺寸的视频。

 <html><body> <div> </div> <div></div> <script> //get screen width and pixel ratio var width = screen.width; var dpr = window.devicePixelRatio; //initialise 2 videos — //“small” is 960 pixels wide (2.6 MB), large is 1920 pixels wide (10 MB) var smallVideo="https://res.cloudinary.com/dougsillars/video/upload/w_960/v1534228645/30s4kbbb_oblsgc.mp4"; var bigVideo = "https://res.cloudinary.com/dougsillars/video/upload/w_1920/v1534228645/30s4kbbb_oblsgc.mp4"; //TODO add logic on adding retina videos if (width<500){ console.log("this is a very small screen, no video will be requested"); } else if (width< 1400){ console.log("let's call this mobile sized"); var videoTag = "\<video preload=\"auto\" width=\"100%\" autoplay muted controls src=\"" +smallVideo +"\"/\>"; console.log(videoTag); document.getElementById('video').innerHTML = videoTag; document.getElementById('text').innerHTML = "This is a small video."; } else{ var videoTag = "\<video preload=\"auto\" width=\"100%\" autoplay muted controls src=\"" +bigVideo +"\"/\>"; document.getElementById('video').innerHTML = videoTag; document.getElementById('text').innerHTML = "This is a big video."; } </script> </html></body>

该脚本将用户的屏幕分为三个选项：

1. 低于 500 像素，不显示视频。
2. 在 500 到 1400 之间，我们有一个较小的视频。
3. 对于大于 1400 像素宽的屏幕，我们有更大的视频。

我们的页面有一个具有两种不同尺寸的响应式视频：一种用于移动设备，另一种用于桌面尺寸的屏幕。 移动用户可以获得出色的视频质量，但文件只有 2.6 MB，而桌面视频则为 10MB。

动画 GIF

动画 GIF 是大文件。 虽然 aGIF 和视频文件都通过宽度和高度维度压缩数据，但只有视频文件具有压缩（通常更大）时间轴。 aGIF 本质上是快速“翻阅”静态 GIF 图像。 这种缺乏压缩会增加大量数据。 值得庆幸的是，可以用循环视频替换 aGIF，从而为每个请求节省 MB 的数据。

 <video loop autoplay muted playsinline src="pseudoGif.mp4">

在 Safari 中，有一种更奇特的方法：您可以在图片标签中放置一个循环播放的 mp4，如下所示：

 <picture> <source type="video/mp4" loop autoplay> <source type="image/webp"> <src="animated.gif"> </picture>

在这种情况下，Safari 将播放动画 GIF，而 Chrome（和其他支持 WebP 的浏览器）将播放动画 WebP，并回退到动画 GIF。 您可以在 Colin Bendell 的精彩文章中了解有关此方法的更多信息。

第三方视频

将视频添加到您的网站的最简单方法之一是简单地从视频共享服务复制/粘贴代码并将其放在您的网站上。 但是，就像将任何第三方添加到您的网站一样，您需要警惕将哪种内容添加到您的页面，以及这将如何影响页面加载。 其中许多“简单地将其粘贴到您的 HTML”小部件中添加了 100 KB 的 JavaScript。 其他人会下载整部电影（想想preload="auto" ），有些人会两者兼而有之。

第三方视频最佳实践：信任但验证。 检查添加了多少内容，以及它对页面加载时间的影响程度。 此外，行为可能会发生变化，因此请定期跟踪您的分析。

流媒体启动

当请求视频流时，服务器向播放器提供一个清单文件，列出每个可用的流（带有尺寸和比特率信息）。 在 HLS 流中，播放器通常选择列表中的第一个流开始播放。 因此，清单文件中首先定位的流应该针对移动设备和桌面设备上的视频启动进行优化（或者可能替代清单文件应该传送到移动设备和桌面设备）。

在大多数情况下，通过使用较低质量的流开始播放来优化启动。 一旦播放器下载了几个片段，它就会更好地了解可用吞吐量，并且可以为后面的片段选择更高质量的流。 作为用户，您可能已经看到了这种情况——视频的前几秒看起来非常像素化，但在播放几秒钟后，视频会变得清晰。

在检查从 HTTP 存档传送到移动设备的 1,065 个清单文件时，我们发现 59% 的视频具有低于 1.2 MBPS 的初始比特率 - 并且很可能以 1.6 MBPS 的 3G 数据速率开始流式传输而没有任何延迟。 11% 使用 1.2 和 1.6 MBPS 之间的比特率 - 这可能会减慢 3G 的启动速度，30% 的比特率高于 1.6 MBPS - 并且无法在 3G 连接上以该比特率播放。 根据这些数据，似乎有 41% 的视频将无法在移动设备上维持初始比特率——这会增加启动延迟，并且可能会增加播放期间的停顿次数。

流式启动最佳实践：确保清单文件中的初始比特率适用于大多数客户。 如果播放器在启动期间必须更改流，播放将延迟，您将失去视频观看次数。

那么，当视频的比特率接近（或高于）可用吞吐量时会发生什么？ 下载几秒钟后，没有完整的视频片段可供播放，播放器停止下载并选择较低质量的比特率视频，然后再次开始该过程。 下载视频片段然后放弃的动作会导致额外的启动延迟，这将导致视频放弃。

我们可以通过构建具有不同初始比特率的视频清单来可视化这一点。 我们测试了 3 种不同的场景：从最低 (215 KBPS)、中等 (600 KBPS) 和最高比特率 (2.6 MBPS) 开始。

从最低质量的视频开始播放时，从 11 秒开始播放。 几秒钟后，播放器开始请求更高质量的流，画面锐化。

当以最高比特率开始时（在 1.6 MBPS 的 3G 连接上测试），播放器很快意识到无法播放，并切换到最低比特率视频 (215 KBPS)。 视频在 17 秒开始播放。 有 6 秒的延迟，视频质量与第一次测试中交付的低质量相同。

使用中等质量的视频需要进行一些折衷，视频以 13 秒（慢 2 秒）开始播放，但从一开始就是高质量的 - 并且没有从像素化视频跳转到更高质量的视频。

视频启动的最佳实践：为了获得最快的播放速度，请从最低质量的流开始。 对于较长的视频，您可以考虑在开始时使用“中等质量”流以在启动时提供清晰的视频（延迟稍长）。

WebPageTest 结果：初始视频流低、中、高（从上到下）。 视频以最低质量的视频开始最快。 需要注意的是，17s 的高质量开始视频与 11s 的低质量开始的质量相同。

流媒体：继续播放

当视频播放器可以确定播放的最佳视频流并且流低于可用网络速度时，视频将正常播放。 有一些技巧可以帮助确保视频以最佳方式交付。 如果我们检查以下清单条目：

 #EXT-X-STREAM-INF:BANDWIDTH=912912,PROGRAM-ID=1,CODECS="avc1.42c01e,mp4a.40.2",RESOLUTION=640x360,SUBTITLES="subs" video/600k.m3u8

信息行报告该流具有 913 KBPS 比特率和 640×360 分辨率。 如果我们查看该行指向的 URL，我们会看到它引用了一个 600k 的视频。 检查视频文件显示视频为 600 KBPS，并且清单夸大了比特率。

夸大视频比特率

• 专业版
  夸大比特率将确保当播放器选择流时，视频下载速度比预期快，缓冲区填充速度比预期快，减少卡顿的可能性。
• CON
  通过夸大比特率，传输的视频将是质量较低的流。 如果我们查看报告的比特率与实际比特率的完整列表：

对于 1.6 MBPS 连接的用户，播放器将选择 913 KBPS 比特率，为客户提供 600 KBPS 视频。 但是，如果准确报告了比特率，则将使用 950 KBPS 比特率，并且可能会毫无问题地进行流式传输。 虽然这里的选择可以防止停顿，但它们也降低了向消费者提供的视频的质量。

最佳实践：稍微夸大视频比特率可能有助于减少播放中的停顿次数。 但是，太大的值会导致播放质量下降。

在浏览器中测试尼尔森视频，看看能不能让它来回跳转。

结论

在这篇文章中，我们介绍了多种方法来优化您在网站上展示的视频。 通过遵循本文中说明的最佳实践：

1. preload="auto"
   仅在您的客户很可能会观看此视频时使用。
2. preload="metadata"
   Chrome 中的默认设置，但仍会导致大型视频文件下载。 谨慎使用。
3. 无声视频（循环 GIF 或背景视频）
   剥离音频通道
4. 视频尺寸
   考虑通过桌面向移动设备提供不同大小的视频。 视频会更小，下载速度更快，并且您的用户不太可能看到差异（您的服务器负载也会下降！）
5. 视频压缩
   不要忘记压缩视频以确保交付
6. 不要“隐藏”视频
   如果视频不会显示 - 不要下载它。
7. 定期审核您的第三方视频
8. 流媒体
   从较低质量的流开始，以确保快速启动。 （对于播放时间较长的视频，请考虑使用中等比特率以获得更好的启动质量）
9. 流媒体
   可以在比特率上保持保守以防止失速，但如果走得太远，流将提供质量较低的视频。

您会发现页面上的视频经过精简以实现最佳交付，并且您的客户不仅会喜欢您展示的视频，而且总体上会享受更快的页面加载时间。