原文地址：https://blog.cloudflare.com/making-video-intuitive-an-explainer/
原文标题：Making Video Intuitive: An Explainer
原文作者：Kyle Boutette
原文写于：2020/5/12 GMT+8 下午7:00:00
译者：驱蚊器喵#ΦωΦ
翻译水平有限，有不通顺的语句，请见谅。
在 Cloudflare 的 Stream 团队中，我们致力于为用户提供良好观看体验的同时，保证我们的服务定价合理。这需要我们对视频处理管道进行大量微调，而大多数人可能难以分辨其区别。这就使得这些调整的结果不那么直观。
在本文中，我们就来玩一玩。相对平常精细化的优化工作，我们这次反其道而行之。今天，我们将让我们很容易看到不同版本的视频之间的变化：我们将从一个高清视频开始，然后将之毁掉。与其追求完美，不如让我们来看看各种视频编码设置的影响。我们将深入探讨，如何让一些目标视频变得冠冕堂皇的（糟糕），并在此过程中学习。
每个人都这样认为，互联网上的视频应该看起来很好看，开始播放的速度快，而且无论他们在哪个设备上播放，都不需要缓冲。人们可以用视频的一个版本对比另一个版本，并说第一个看起来更好看。但是，大多数人都很难阐述”更好”的定义。当你只是在观看视频时，这不是你需要考虑的问题。然而，当你在存储、编码和分发视频时，视频的外观决定了你的观众用户体验。
为了确定看起来更好是什么样子，视频工程师们会使用各种各样的技术。其中最容易理解，同时最明显的是：通过让人看两个版本的视频进行比较 – 主观比较。在这里我们就用眼睛看。
那么，谁是我们的实验视频呢？我们要用一个经典的视频来做示范 — 也许对视频工作者来说太过经典了 — Big Buck Bunny。这是由 Sacha Goedegebure 提供的开源影片，可在 Creative Commons Attribution 3.0 license 许可下使用。为了节省时间，我们只用视频其中的 17 秒。这是视频从 https://peach.blender.org/download/ 下载时的样子。请花点时间细细品味这段视频的质量，因为我们的质量只会越来越差（译者：😂）。
为了简洁起见，我们将通过两个属性来评估我们的结果：动作流畅，以及看起来”艳丽(crisp)”。视频不卡顿，视频中的重要特征可以明显辨认。
值得一提的是，视频是你的大脑被欺骗后的产物。每一个视频本质只是一串优化过的图片 – 组成一个非常复杂的翻页本。足够快地展示这些图片，你就可以骗过大脑来形成运动。如果你把足够多的光点显示在一起，它们就会融合成一个连续的图像。然后，足够频繁地改变这些光的颜色，你就可以感受到流畅的运动。
帧率
流畅与否，由帧率来决定，以帧/秒(frames-per-second,fps)来衡量。fps 是指在一秒钟内显示单个图片的数量；许多视频的编码速度在 24 到 30 fps 之间。描述 fps 的一种方法是以一帧显示的时间长短来计算，这通常称为帧时间。当帧率为 24fps 时，每一帧的显示时间约为 41 毫秒。当帧率为 2fps 时，这个时间会跳到 500 毫秒。降低帧率，会使帧数迅速趋向于持续整整一秒。平滑运动主要归结为单一的帧速率。把帧率搞的乱七八糟，这样的运动方式并不能实现我们目标。而且，这会非常容易破坏帧率和用户体验。人们对运动的容忍度很低。为了了解这个想法，这里是我们的原始剪辑减少到 2fps 的样子; 每帧 500ms 是一个很长的时间。
1 | ffmpeg -v info -y -hide_banner -i source.mp4 -r 2 -c:v h264 -c:a copy 2fps.mp4 |
译者注：
参数解释
-v info, 输出 log 的级别为 info
-y, 覆盖输出文件
-hide_banner, 不显示程序的 banner 信息
-i source.mp4, 输入的文件
-r 2, 设置帧率为 2
-c:v h264,c 指的是 codec，v 指 video，对视频编码为 h264，即使是使用和源视频相同的编码，也需要显式写出来
-c:a copy,a 指的是 audio，对音频的处理为拷贝，意思是不处理，直接拷贝输入文件的音频
2fps.mp4, 这是输出文件
分辨率
有很多配置选项，可以让微小的功能与众不同。你可以做的选择包括编解码器、级别、配置文件、比特率、分辨率、色彩空间，或关键帧频率等。这些因素中的每一个也会影响到除了可以感知到的质量之外的其他因素，例如，所产生的文件有多大，它与哪些设备兼容。对于用什么参数来编码视频，没有一个通用的正确答案。为了在不浪费资源的同时获得最佳体验，同样的视频，为现代 4k 显示器设计，和为 2007 年的 iPod Nano 设计，方式是不同的。我们将专注于影响视频清晰度的因素上，因为这在很大程度上决定了播放体验。
我们要用 FFmpeg 来实现这个目标。这是视频世界里的瑞士军刀；一个近乎通用的命令行工具，用于转换和处理媒体。FFmpeg 已经有近 20 年的历史，数百个贡献者，基本上可以用于处理任何数字视频相关的任务。它的灵活性也使得它的工作相当复杂。对于每一个版本的视频，我们将展示用于生成它的 ffmpeg 命令，并在此过程中进行演示。
让我们一起想一想，到底要改变什么属性，才能让这个视频的播放体验变得糟糕。
你可能听说过分辨率和比特率。为了解释这两个术语，我们用一个比喻来说明。分辨率提供了像素。像素是承载信息的桶。比特率是填满这些桶的信息。一个给定的水桶有多满，决定了一个像素能代表多少内容。一个水桶的信息位数太少，像素对原始信息源的准确度就会越来越低。在实际应用中，它们的数值关系比较复杂。这些就是我们将要改变的。
决定哪个桶应该获得多少比特的信息，由视频编码器(video encoder)决定。编码器的工作是尽可能有效地使用为它预算的比特数，以显示最佳质量的视频。我们要通过改变比特率预算来影响最终的比特率。和有钱的人一样，预算是我们编码器的一个概念。没有被压缩的视频可以在红、绿、蓝(RGB)通道的每个像素上使用一个字节，甚至更多。对于一个 1080p 的视频，这意味着 1920x1080 像素乘以3个字节，每帧分配到 6.2MB 信息。我们稍后会讨论帧数，但 6.2MB 是一个很大的数字 – 在这样的速率下，一张 DVD 光盘只能容纳约 50 秒的视频。
确定了变量，我们就可以开始了。对于我们编码的每一个变量，我们会在这个表格中进行对比。我们的源视频，帧率是 24fps，使用 H.264 编码，并且还有一些其他的各种设置，但这些设置不会改变。期待着这些数字会明显变小，因为我们会进行一系列实验，看看有什么变化。
| 分辨率 | 比特率 | 文件大小 | |
|---|---|---|---|
| 原始视频 | 1280x720 | 7.5Mbps | 16MB |
首先，让我们改变一下分辨率，看看有什么影响。大多数人接触到的最低分辨率通常是 140p，所以我们使用这个分辨率，对源视频重新编码。因为很多视频平台都有这个选项，所以我们现在还不指望会出现无法观看的体验。
1 | ffmpeg -v info -y -hide_banner -i source.mp4 -vf scale=-2:140 -c:v h264 -b:v 6000k -c:a copy scaled-140.mp4 |
译者注：
参数解释
-vf scale=-2:140, vf 指 video filter 视频滤镜，使用 scale 滤镜缩放输入的视频，参数格式是 width:height,140p 分辨率的画面 height 是 140，width -2 是指按宽高比自动设置 width。详细可以查看 官方文档scale部分
-b:v 6000k,b 指 bitrate 比特率，v 仅对 video 视频部分处理，比特率设置为 6000k，也就是 6M
| 分辨率 | 比特率 | 文件大小 | |
|---|---|---|---|
| 原始视频 | 1280x720 | 7.5Mbps | 16MB |
| 缩放到140p | 248x140 | 2.9Mbps | 6.1MB |
通过表格中的数字，我们发现了一些奇怪的结果。我们要求的比特率是 6M，但编码器给我们的比特率大约是源视频的三分之一。考虑到像素的数量被大幅减少，编码器将更少的比特率信息放在我们的比特率桶中。尽管它尽力使用了提供给它的全部预算比特率，但编码器填满了我们提供的所有比特率桶，还没有用完预算比特率。它是怎么处理这些剩余的信息呢？因为这些比特信息不在视频中，所以编码器把它们扔掉了。
在4英寸的手机屏幕上，这个播放体验还能被接受。因为在小屏幕设备上，你不会注意到那种颗粒感的显示效果。而在40英寸的电视上，颗粒就会显示成块状，很难看。在40英寸的电视上，140行的像素会变得可以单独区分，这并不能骗过大脑，也破坏了视频的魔力。
比特率
比特率是指在一定时间内的信息密度，通常是一秒钟。这与帧速率相互作用，给我们一个每帧的预计比特率。我们的数据源的比特率为 7.5Mbps (百万比特/秒)，帧率为 24fps，这意味着我们平均每帧的信息量为 7500Kbps/24fps = 312.5Kb。
不同类型的帧
一个帧有不同的编码方式。对于单一颜色的帧序列和《Big Buck Bunny》中的大部分序列，使用相同的技术是没有意义的。因为这些序列之间的信息密度和分布不同。帧的不同表示方式利用了这些不同的模式。因此，每个帧的平均大小，312Kb，既小于大帧的大小，也大于小帧的大小。有些帧只包含相对于其他帧的变化 - 这些是P帧或B帧 - 这些小帧的大小可能远远小于 312Kb。然而，有些帧包含完整的图像 - 这些是I帧 - 往往远远大于 312Kb。由于我们是以多秒为单位整体观看视频，我们不需要担心它们，因为我们关注的是整体体验。了解帧的相关知识，有助于了解帧在不同类型的内容时对比特率的影响，这一点我们将在后面讨论。
我们的起始比特率非常大，信息量比我们实际需要的多。让我们在保持分辨率不变的同时，将信息量削减到原来的 1/75。
1 | ffmpeg -v info -y -hide_banner -i source.mp4 -c:v h264 -b:v 100k -c:a copy bitrate-100k.mp4 |
| 分辨率 | 比特率 | 文件大小 | |
|---|---|---|---|
| 原始视频 | 1280x720 | 7.5Mbps | 16MB |
| 缩放到140p | 248x140 | 2.9Mbps | 6.1MB |
| 目标比特率为100Kbps | 1280x720 | 102Kbps | 217KB |
看一下视频，毛皮和小草都变成了斑点。因为信息量不够，所以无法准确地表现出细微的细节。
我们提供的比特率预算是 100Kbps，但编码器似乎还没有完全达到。上次我们改变分辨率的时候，比特率比我们要求的低，这次我们的比特率却比我们要求的更高了。为什么会出现这种情况呢？
我们有这么多数据桶，在每个桶中都有编码器的最小需求量。由于编码器可以处理比特率，所以最终的比特率会比满满一桶要稍微多一点，因为这样更容易计算。这与我们之前的实验中的比特率比预期的要低的原因有点相反。
我们可以使用速率控制模式(using rate control modes)来影响编码器利用预算比特率的方式。我们将继续使用默认的”平均比特率”模式，让实验保持简单。这种模式是次优模式，因为它让编码器在前期花费了大量的预算，对以后的使用不利。然而，这很容易推理。
分辨率 + 比特率
以 100Kbps 的比特率为目标，我们得到了一个不愉快的视频，但视频并非完全无法观看。我们还没有完全毁掉我们的视频。我们不妨比特率降到更低的极限，在保持分辨率不变的情况下，把比特率降到 20Kbps。
1 | ffmpeg -v info -y -hide_banner -i source.mp4 -c:v h264 -b:v 20k -c:a copy bitrate-20k.mp4 |
| 分辨率 | 比特率 | 文件大小 | |
|---|---|---|---|
| 原始视频 | 1280x720 | 7.5Mbps | 16MB |
| 缩放到140p | 248x140 | 2.9Mbps | 6.1MB |
| 目标比特率为100Kbps | 1280x720 | 102Kbps | 217KB |
| 目标比特率为20Kbps | 1280x720 | 35Kbps | 81KB |
现在这样，完全是不忍直视！有的地方有颜色，但视频大部分都是灰阶长方形，大致上接近于我们所期待的剪影。这段视频的比特率略低于上一次实验的三分之一，看起来肯定只有不到三分之一的信息量。
和之前一样，我们没有达到我们的比特率目标，原因也是同样的，我们的像素桶信息量不足。编码器需要在 102Kbps 到 35Kbps 之间的某个时间点开始做艰难的决定。牺牲了大部分的色彩和场景。
我们将讨论一下为什么会有移动的灰度矩形和彩色斑块。这些东西给了我们一个提示，有关于编码器的工作原理。
如果我们再深入一点，把微小的分辨率与荒谬的低码率结合起来呢？那样应该会是更糟糕的体验，对吧？
1 | ffmpeg -v info -y -hide_banner -i source.mp4 -vf scale=-2:140 -c:v h264 -b:v 20k -c:a copy scaled-140_bitrate-20k.mp4 |
| 分辨率 | 比特率 | 文件大小 | |
|---|---|---|---|
| 原始视频 | 1280x720 | 7.5Mbps | 16MB |
| 缩放到140p | 248x140 | 2.9Mbps | 6.1MB |
| 目标比特率为100Kbps | 1280x720 | 102Kbps | 217KB |
| 目标比特率为20Kbps | 1280x720 | 35Kbps | 81KB |
| 缩放到140p并且目标比特率为20Kbps | 248x140 | 19Kbps | 48KB |
等一下，这其实也不算太差。这几乎就像一个 100Kbps 的分辨率, 1280x720 画质的缩小版。为什么这看起来不那么糟糕？较低的比特率意味着信息量更少，这意味着视频看起来应该更糟糕才对。更低的分辨率意味着图像的细节应该更少。数字变小了，所以视频看起来不应该更好看!
回想一下桶和信息，现在我们有更少的信息，但却有更少的离散空间供这些信息居住。这种低比特率和低分辨率的特定组合意味着信息桶被很好地填满了。编码器准确地命中了我们的目标比特率，这是一个合理的指标，说明它至少满足了最终的结果。
这在 4k 显示屏上并不是一个有趣的体验，但对于 2007 年的 iPod Nano 来说，这已经足够了。第三代的 iPod Nano 有一个320x240的显示屏，分布在 2 英寸的屏幕上。我们观看 140p 的视频几乎和更高画质的视频没有什么区别。更为重要的是，占用 48KB 容量来播放 17 秒的视频，可以很好地利用有限的存储空间 – 部分机型存储空间为 4GB。在资源有限的环境下，这种低画质的视频质量，对体验质量的提升可谓是一个很大的进步。
我们应该对比特率和分辨率之间的关系有了一个直观的感受以及折衷的考虑。但还有一个问题，就是我们是否需要进行折衷？是否存在一定的比特率和像素数的比例，在最小的文件大小下，在给定的分辨率下获得最佳的质量。
事实上，这样完美的比例是存在的。在破坏视频的过程中，我们最终测试了几个备选比例的源视频。
| 分辨率 | 比特率 | 文件大小 | 位/像素(有效比特数) | |
|---|---|---|---|---|
| 原始视频 | 1280x720 | 7.5Mbps | 16MB | 8.10 |
| 缩放到140p | 248x140 | 2.9Mbps | 6.1MB | 83.5 |
| 目标比特率为100Kbps | 1280x720 | 102Kbps | 217KB | 0.11 |
| 目标比特率为20Kbps | 1280x720 | 35Kbps | 81KB | 0.03 |
| 缩放到140p，目标比特率为20Kbps | 248x140 | 19Kbps | 48KB | 0.55 |
然而，这其中也有一些连带问题。
最大的问题是，最佳比例取决于你的源视频。每个视频所需要显示的信息量都不一样。这其中有几个原因。
如果一个画面有很多细节，那么它需要更多的信息来表现。按时间顺序排列的帧在视觉上有明显的差异（比如动作片），比起一组视觉上相似的帧（比如一个安静仓库外的监控摄像头）需要更多的信息。前者不能使用很多的B帧或P帧，而B帧或者P帧占用更少的空间。具有平面色彩的动画内容需要编码器做出比实景动画更少的交互，导致视觉效果下降。
回想一下造成灰度矩形和彩色斑块的配置，我们可以学到更多的东西。我们看到，长方形和色彩似乎在移动，就像编码器用小方块的图片做了个命令行的游戏(shell game)。
现在的情况是，编码器正在识别帧内和帧间的重复模式。然后，它可以参考这些模式来移动它们，而不需要实际复制它们。前面提到的P帧和B帧主要是由这些移位模式组成的。这在本质上，与其他使用字典来引用之前内容的压缩算法类似。在大多数的视频编解码器中，可以进行移位的图片位被称为 “宏块(macroblocks)”，它将每一帧用 NxN 个像素的正方形分割成 N 个像素。比特率越小，这种命令行游戏版视频的宏块越不明显。
为了更清楚地看到这种效果，我们可以要求 FFmpeg 向我们展示它所做的决定。具体来说，它可以向我们展示它决定移动宏块的 “运动” 。这里的视频是 140p 的视频，为了让我们更容易看到运动矢量箭头。
1 | ffmpeg -v info -y -hide_banner -flags2 +export_mvs -i source.mp4 -vf scale=-2:140,codecview=mv=pf+bf+bb -c:v h264 -b:v 6000k -c:a copy motion-vector.mp4 |
更糟糕的是，平面色彩和噪音可能只在同一视频中的两个不同场景中看到。这迫使你要么在一个场景中浪费你的比特率预算，要么在另一个场景中看起来很糟糕。我们给予编码器一个它可以使用的目标比特率。最后呈现出的视频，循环编码的产物，正是编码器如何利用目标比特率的反馈结果。
另一个注意事项是，你的比特率会受到前面列出的所有属性的影响，其中影响最大的是编解码器的选择，其次是比特率预算。我们探讨了比特率和分辨率之间的关系，但每个属性都会对质量产生影响，并且一个属性经常与其他属性相互影响。
到目前为止，我们已经了解了一些影响视频的视觉质量的属性和设置。每天，视频工程师和编码器都要做出艰难的调整，来优化人眼看到的视频，同时将文件大小控制在最小范围内。现代的编码方案使用诸如 per title encoding 等技术来缩小最佳分辨率-比特率组合。这些方案看起来有点类似于我们在这里所做的：测试不同的设置，看看什么属性能得到理想的结果。
在每一个例子中都包含了一个 FFmpeg 命令，你可以复制他们，然后用你自己的视频进行实验。我们鼓励你尝试提高视频质量，同时减少文件的大小，并找到其平衡点，在这个过程中找到更多的帮助。