优化视频的大小和质量

在过去的几年里，越来越多的项目将视频作为应用程序的一个组成部分。 这是一个很好的方向，因为视频比静态照片更具吸引力（视频可以使转化率翻倍并增加在网站上花费的时间），因此可以真正吸引客户探索产品和服务的细节。 但是，当出现与视频播放相关的问题时，这一切都会发生。

视频播放问题与视频的大小和比特率直接相关。 大尺寸或高比特率的视频下载时间会更长，并且需要更高速度的网络才能流畅播放。 这会导致更长的启动时间，如果网络不能足够快地提供视频，视频将在视频播放期间停止。

不过有解决办法！ 通过在将视频添加到我们的网站之前对其进行基本优化，我们可以永久防止这些问题的发生——嗯，大部分都是这样。 我们真正需要做的就是以一种或另一种方式使文件更小。 所以，现在的诀窍是：我们如何在不降低质量的情况下使文件更小？

在本文中，我们将介绍您可以采取哪些工具和一些步骤来优化您的视频以供播放- 所有这些都是为了避免停顿并给您的宝贵客户留下深刻印象！

真实世界数据

找到具有超大视频的网站并不罕见 - 例如，用作英雄背景视频。 在我的研究中，我正在研究 2020 年 12 月的移动 HTTPArchive 中发现的网站，不难发现很多网站默认加载巨大的视频文件，无论是在移动设备上还是在桌面设备上。

当然，您能否实现与我将在此处展示的相同的节省，这是值得怀疑的，但您会在处理视频时获得一些有用的指示和提示。 事实上，如果您不小心，很容易在您的网站上意外放置超大视频，导致大多数客户几乎无法使用它们。

南瓜补丁的故事

想象一下现在是 10 月中旬，您正在寻找一块南瓜地和一个玉米迷宫，以便与家人度过一个周末的下午。 在舒适的台式机上，您可以在网上搜索附近的位置并找到完美的位置。 该网站看起来很可爱，页面顶部播放了一段漂亮的无人机 4K 视频。 您选择 URL 并将其发送给您自己和您所爱的人，这样您就可以在旅途中继续探索此选项。

但是当您在手机上打开页面时，您会注意到一个小故障：视频正在拼命尝试在您的手机上播放，但不幸的是未能播放。 视频不断停顿并一遍又一遍地重新启动，比在您的计算机上更具破坏性和烦人。 最终，您继续前进，为 URL 添加书签，然后继续您的日常工作。

在度过了有趣的泥泞的一天（好吧，我最近住在西雅图和英国，所以南瓜地很泥泞），你又回到了你的电脑上：也许你又想起了那个视频，你想知道为什么它没有播放在你的手机上。 好吧，让我们诊断一下发生了什么。

您可以从在浏览器中打开 DevTools 开始。 加载页面后，我们可以移动到网络选项卡，并按“媒体”过滤以查看所有视频文件：

我们看到正在下载一个 MP4 文件。 该文件不是作为独立文件通过网络传输的； 相反，流服务必须将文件分成几个片段，因此您可能会看到对同一文件的多个206 （部分内容）请求。

查看此文件的响应标头，我们可以发现一些细节：

 accept-ranges: bytes access-control-allow-headers: x-test-header, Origin, X-Requested-With, Content-Type, Accept access-control-allow-methods: GET, POST, PUT, DELETE, OPTIONS Content-Length: 87690242 Content-Range: bytes 70025216-157715457/157715458 content-type: video/mp4 date: Fri, 22 Jan 2021 15:27:26 GMT last-modified: Mon, 24 Jun 2019 05:13:04 GMT server: Apache

现在，其中一些数字有点吓人，因为它们有点大。 事实上，它们通常很大，以至于我发现自己养成了添加逗号的习惯，因此我可以了解文件的实际大小。 在这种情况下，部分下载为 87 MB，整个文件为 157,715,457 字节。 是的，没错，这个视频是 157MB，今天早些时候它（尝试）加载到我的手机上！ 难怪没有成功。

那么这个视频是怎么回事？

让我们深入一点。 显然，视频太大，无法在内存较低且网络较慢的手机上流畅播放。 但是我们需要解决什么问题呢？ 为了弄清楚究竟是什么问题，我们可以使用开源和免费的 FFMPEG，它被证明是优化视频的最可靠工具之一。 我们可以无休止地调整 FFMPEG 中的配置，但让我们在本文中只涉及一些重要的配置。

那么，让我们从名为 FFprobe 的诊断工具开始。 FFprobe 从多媒体流中收集信息，并为您提供有关视频编码方式和播放方式的详细信息。 它是 FFMPEG 包的一部分，实际上非常易于使用。

更好的是：如果您的视频已经在线，我们可以立即跳转到 ffprobe 的在线版本。 因此，让我们在表单中输入 URL，然后获取有关视频的详细信息（例如视频尺寸、比特率和相当多的元数据）。

当我从南瓜农场添加 MP4 URL 时，我们立即看到了其中一个问题。 来自 ffprobe 的show_format响应返回一个摘要：显然，有 2 个流，长度为 62 秒（这听起来很正常，不会引起任何怀疑）。 但是当我们得到size 和 bitrate时，我们会立即看到视频失败的地方。

如上所述，习惯于为这些大数字添加逗号可能是个好主意。 事实证明，在场地上空飞行的无人机镜头确实是 157MB，比特率是每秒 20MB！ 这意味着要无缝播放视频，网络必须能够以高于 20 MBPS 的速率传输视频，这正是它在手机上停滞不前的原因。

理想的播放比特率是多少？

为了避免停顿，我们需要以适当的速率流式传输视频。 这就是比特率变得重要的地方。 比特率是视频的播放速度。 为了让浏览器流畅地播放视频，视频的下载速度必须快于播放速度——这意味着视频只有在网络速度超过 20 MBPS 时才能流畅播放。 当我想到网络速度时，我倾向于依赖 WebPageTest 的流量配置文件：

从上面的概述中我们可以看出，视频可能在“本机连接”和超快光缆 FIOS 连接上播放良好（20 MBPS 正是所需的速度，所以希望不需要在背景）。 但是，所有其他连接的下行速度都明显低于 20 MBPS 。 如果视频以这些速度加载，播放器将尝试以比下载速度更快的速度消耗视频，并且视频将永久停止。

视频的比特率设置了客户可以使用的最低网络速度。 一般来说，视频的比特率应该是网络上可用吞吐量的 80% 左右。 因此，20 MBPS 的视频确实需要 24 MBPS 的网络吞吐量才能无缝播放视频。 连接速度较慢的每个人的体验都会很差，并且可能根本无法观看视频。 更具体地说，这意味着我们要在 4G 上流畅流畅地播放，比特率必须保持在 7.2 MBPS 以下。

我们可以降低此视频的比特率吗？

是的！ 让我们看看我们可以用来降低此视频比特率的一些配置。 但首先，让我们看看我们从 FFprobe 获得的数据。 非常值得注意的一件事是r_frame_rate值，它是视频中每秒的帧数。 其值为 60000/1001。 这意味着视频的帧速率为每秒 60 帧。 但是，网络上的典型帧速率是 25–30，所以我们可以做的第一件事就是用较低的比特率重新编码视频。

要记住的另一件事是恒定速率因子。 在 FFMPEG 中，主要的质量/大小基准是恒定速率因子 (CRF) 压缩，其值范围从0 （无压缩）到50 （高压缩）。 FFMPEG 中 CRF 的默认值为23 （如果省略 CRF 参数，您的视频将使用该值）。 以我个人的经验，23-28 的值仍然可以产生高质量的视频，在网络上看起来不错并且文件大小大大减小。

所以让我们从 30fps 和23的 CRF 开始。 终端命令将如下所示：

 ffmpeg -i input.mp4 -vcodec h264 -acodec aac -crf 23 -strict -2 :v fps=fps=30 output.mp4

瞧！ 这会产生一个 81.5 MB 的视频——已经提高了 48%。 但视频仍然很大，比特率为 10 MBPS。 如果我们将 CRF 设置为 28，则文件将下降到 35.4MB，比特率为 4.5 MBPS，这在 4G 连接上更有可能播放良好。

这是对原始视频的五倍改进。 为了使该视频更易于访问，我们可以调整视频的大小以使其更小。 这就是我们将在下面的流媒体部分讨论的内容。

饿了比萨的故事

想象一下，您在洛杉矶，可能从国外访问并在手机上漫游，当然还想吃一片披萨。 你在手机上找到了一个很棒的披萨店，并决定前往那里。 您可能已经注意到页面上的一些视频和英雄图片，但实际上，每个披萨店看起来都一样，所以您没有费心观看视频。 在返回酒店之前，您先去拿一两片。

那天晚上，您从运营商那里收到一条短信，说您使用的数据比您想象的要多得多（而且绝对比您最初计划的要多！）。 几辆出租车，还有比萨网站——比萨网站又贵了多少？

您将披萨网站弹出到 WebPageTest 并在移动连接上检查它：

44 MB 的视频。 它来自哪里？ 除此之外，当我们更详细地检查源和瀑布时，我们可以看到实际上有两个视频！ 幸运的是（或不幸的是？），两者都未能完全下载：

这引起了一些担忧和一些问题。

首先，为什么没有自动播放时下载了这么多视频？ 我们还没有设法点击任何东西，但已经使用了近 40 MB 的数据。 一如既往，答案在于源头。 嗯，“查看源代码”，就是这样。

 <video class="video-js vjs-big-play-centered" controls preload="auto" width="1050" height="591" poster="assets/home_poster.jpg" data-setup='{"fluid": true}'>
  <source src="assets/home_1.mp4" type='video/mp4'> <source src="assets/home.webm" type='video/webm'>
  <p class="vjs-no-js">To view this video please enable JavaScript, and consider upgrading to a web browser that <a href="https://videojs.com/html5-video-support/" target="_blank">supports HTML5 video</a></p> </video>

马上，我们至少看到两个问题：

• 预载=“自动”
  当我们设置preload="auto"时，我们将覆盖浏览器的默认设置，强制执行视频下载——无论您的客户是否按下了“播放”。 默认的preload属性是metadata ，并且会导致下载几个 100KB。 诚然，对于永远不会观看此视频的网站访问者来说，这是一个更好的结果。
• 视频订购
  如果您有多个版本的视频（在这种情况下：h264 .mp4 和 VP8 .webm 编码的视频），浏览器将选择它知道如何播放的第一个视频。 现在，每个现代浏览器都支持 mp4，而大多数现代浏览器也支持 webm（根据 CanIUse 的数据，全球支持率为 95.4%）。

我喜欢使用的一个技巧是使用 Javascript 插入适当的视频源代码行。 这样，如果您选择不在某些屏幕上提供视频，那么您只有一个空的 <video> 标签——并且无法下载任何视频。

window.onload = addAutoplay(); var videoLocation = document.getElementById("hero-video"); function addAutoplay() { if(window.innerWidth > 992){ videoLocation.setAttribute("autoplay",""); }; }
window.onload = addAutoplay(); var videoLocation = document.getElementById("hero-video"); function addAutoplay() { if(window.innerWidth > 992){ videoLocation.setAttribute("autoplay",""); }; }

如果我们现在对这两个视频运行 ffprobe，我们会发现大小的显着差异：

webm 小了 90%，但浏览量为 0 ，因为每个浏览器都支持 mp4。 这两个视频都是 640×360 和 140 秒长。 在 mp4 上运行ffmpeg命令会生成 12.4 MB 的视频，因此开发人员很可能也遵循了类似的过程来压缩和编码 .webm 变体。 也许拥有 12.5 MB 的preload="auto"毕竟不会那么糟糕。

第二个视频（餐厅内的无人机镜头）以全高清 (1080p) 拍摄，但同样从 140MB 压缩到 35MB。 因此，使用 FFMPEG 的 120s 可以将此页面上的视频重量从 160 MB 减少到 57 MB。 翻转 webm/mp4 顺序将为 95% 可以支持该格式的浏览器节省额外的几 MB。

如果我们想要做得更好，也许让视频响应各种尺寸的屏幕怎么办？ 好吧，让我们制作更小的视频 - 使用响应式视频！

<video> 标签不支持媒体查询来为不同的屏幕提供不同的视频文件，因此我们需要一种不同的方式来提供适合设备屏幕大小的视频。 实现这一目标的最简单方法是使用视频流。 这将为需要的视频播放器添加一些 Javascript 和其他资产，但视频节省肯定会弥补这些额外的数据。

我们可以使用 FFMPEG 创建视频流（我过去曾使用过这样的 bash 脚本），但这需要我们知道我们想要使用的所有大小和设置（如前所述，FFMPEG 有很多设置！ ）。

为了更轻松地流式传输视频，您可以在其中上传视频的 API（例如 api.video 和 Mux），这些工具会为您创建视频流并托管您的视频。 完整的披露，我确实在前一个工作，所以为了简化我的视频处理管道，我将使用 api.video 来转码和托管我的视频。 使用上传 API，我可以上传任何视频，该工具将创建许多不同尺寸和比特率（目前为 240p、360p、480p、720p、1080p 和 4K）的流媒体版本。

随着视频尺寸的减小，较小视频的比特率会大大降低。 这意味着视频在较小的屏幕上需要较少的网络容量，并将在较慢的网络上播放。

为简洁起见，我们将仅测试南瓜补丁视频。 我收到了与无人机视频类似的结果（另一个比萨视频只有 360p，因此它不会从较小的尺寸中受益）。

注意：请记住，该视频目前是 60fps 的 1080p mp4 视频，所有访问者的大小为 157 MB。

通过一些优化（CRF 28 并将帧速率降低到 30fps），视频减少到35.7 MB 。 使用 DevTools，我们可以模拟设备以查看在不同大小的屏幕上播放流视频的视频使用了多少数据。

下表显示了使用的总流量。 对于 HLS 视频，有一个 JavaScript 播放器、CSS、字体等会增加大约 1 MB 的额外开销。 这包括在以下总数中：

在 1080p 时，为流下载了大约 4MB 的额外资源，但对于其他大小，可以节省大量数据，而不会损失视频质量。 不仅视频大小适合设备，而且停顿的可能性要小得多，因为最有可能在较慢的移动连接上的设备的比特率降低了。

视频流处理帧速率、视频大小和质量问题——确保在任何尺寸的屏幕和任何速度的网络上都能快速播放。

“

视频流的另一个优势：如果网络速度较慢（或突然变慢），播放器可以调整正在显示的视频，并播放较低质量的视频版本——确保在设备上播放——即使在网络条件较差的情况下也是如此。 （您可以使用 StreamOrNot 测试不同的视频，这是我不久前发布的一个小型开源项目。

现在，是不是有点太多的开销？ 我们不能用 YouTube 或 Vimeo 做同样的事情（只是更快）吗？ 我们当然可以，但是我们无法从视频中完全删除品牌或广告，更不用说在视频播放器 iframe 中加载的脚本开销了。 另外，有时您可能希望将视频用作产品页面上的背景视频，并完全避免使用任何类型的外部品牌。

结论

我们不会将相机中的图像直接部署到网络上，但我们会压缩和调整它们的大小以平衡质量和网络性能。 视频文件也应该这样做。 较小的视频开始播放速度更快，停顿的频率更低，从而改善了网站的用户体验。

在本文中，我们通过几个简单的步骤来优化我们的视频，例如降低质量和帧率。 我们还研究了视频流如何让我们为 Web 构建响应速度更快的视频体验——自动提供适合设备屏幕大小的视频。

感谢您的阅读，如果您想了解更多信息，您可能想在此处、Smashing Magazine 和我的博客上阅读更多有关视频最佳实践的信息：

• Web 上的视频播放：视频的当前状态（第 1 部分）
• Web 上的视频播放：视频交付最佳实践（第 2 部分）
• 在移动网络上隐藏视频