2017年6月29日
By Jan Ozer 特约编辑
专题文章

Going Low: The Encoding Secrets for Small Sizes With High Quality

让我们从两个观察开始. First, nothing in video compression is free. 对每个编码参数进行调整, 你用编码时间来换取质量, 这转化为成本, 兼容性, 可玩性, 或送达. To gain in quality, you necessarily lose somewhere else. There is no magic; optimization is just a series of controlled and (hopefully) informed decisions about these tradeoffs. Second, no analysis is ever complete; it’s simply a point-in-time observation of a work in process, hopefully to advance the overall state of analysis.

你感觉到我了吗?? 如果是这样，让我们开始吧.

挑战:你能走多低?

这篇文章的灵感来自编辑Eric Schumacher-Rasmussen的一封电子邮件, saying, in essence, that “Netflix and Amazon are now enabling downloads, 文件确实很小，但看起来很棒. 他们是怎么做到的?” Soon thereafter, Netflix published a blog post on its process entitled, “More Efficient Mobile Encodes for Netflix Downloads,” 哪一个给出了它的一般配方. We asked Amazon for similar guidance, which it declined to provide.

Netflix的分析非常庞大, 涉及在Netflix的云渲染平台上以多种分辨率编码的600部完整长度的电影或剧集, 用客观的质量标准评估, 峰值信噪比与视频多方法评估融合(VMAF). Using the techniques discussed in the blog post, Netflix was able to maintain the same quality of its existing H.264起始点，同时减少H.264文件.VP9的比例为35%.9%(以PSNR衡量).

我们的预算并没有那么大. I tested with three videos at a single resolution, encoded on my trusty HP Z840 using the PSNR, 多尺度结构相似度, and video quality metric (VQM) measurements, although I’ll only share PSNR results herein. 在这个分析中有很多数字，清晰地呈现它们是一个真正的挑战.

我生产的质量和H一样.264 starting point with a 25 percent+ reduction in data rate with H.264, VP9 + 44%. Please hold your applause until the end however, 因为有很多, many differences between what I did and what Netflix did, 我们不可能比较我们的结果. 不过，如果你想制作质量最低的手机下载，那你就来对地方了.

测试文件和假设

Let’s quickly cover my test files and test assumption. I tested with segments from Blender movies 钢铁之泪 (3分钟)和 Sintel (2 minutes), as well as 3 minutes from Netflix’s own test video, Meridian. 我只测试了848 × 480的分辨率, creating master 480p files from all three 4K sources, and encoding from and comparing to these master 480p files.

为什么这个决议? 因为它似乎在移动观看分辨率和传输非常低的数据速率之间取得了很好的平衡. 此外，最近发布全球媒体格式报告从编码.Com显示了增长100% 在480p的部署中，从2015年的6%到2016年的12%，大概是针对移动设备. 如果你不能在那个分辨率下生产, however, 不出汗, as the techniques discussed below should work at any resolution.

The next major decision was the starting point, which is obviously critical to the overall percentage savings. Netflix将其测试结果与“我们当前的流”进行了比较，这些流是使用Main H编码的.264配置文件. 与Netflix, however, 这是一个移动的目标, 由于该公司对其库中的所有视频应用标题编码(参见 “How Netflix Pioneered Per-Title Video Encoding Optimization”). 因此，我必须采取的第一步是为我的起始点编码确定适当的数据速率和编码技术.

来计算这个, I encoded each file with x264 set at CRF 23, 以我的经验来看，这与工作室在iTunes下载中使用的质量水平相符吗, 至少是1080p和720p. (有关此技术的更多信息，请查看 “How to Use Objective Quality Measurement Tools.”) I measured PSNR as a reality check and found all values between 39.46 and 41.65 dB, which generally means very good quality. 为透视，在其 “逐标题编码优化” post, Netflix评论说，超过45分贝的值通常不会带来明显的质量改善, and that scores below 35 dB often exhibit noticeable artifacts. 我在中间的位置很方.

While constant rate factor (CRF) encoding suggests the data rate, 对于自适应比特率编码来说，这不是一种合适的技术，因为它可能会产生剧烈的数据速率波动，从而妨碍顺利交付文件的能力, 特别是通过移动连接. So using this CRF computed data rate as a target, I encoded each file using two-pass variable bitrate (VBR), 最大数据速率为目标的110%，视频缓冲验证器(VBV)缓冲区相当于1秒的视频. For the record, I recommend 110 percent constrained VBR because of a 一系列测试在我的Streaming Learning Center网站上的文档显示200%的受限VBR会降低整体QoE. I recommend the VBV buffer setting because of a 一系列测试这表明较高的设置增加了流体的可变性，这再次阻碍了产能.

Yes, 我知道苹果最近将其HLS建议从110%受限VBR改为200%受限VBR, but that doesn’t change my findings and conclusions; 110 percent constrained VBR is what I use and that’s what I recommend. 这就是我的起始点. 如果听起来过于保守, note that many producers still encode using constant bitrate (CBR), 哪种产品的质量更低.

你可以看到 Table 1应用这些限制会降低所有文件的CRF编码的质量，这是我所期望的. However, 为了便于比较, the production encodes would be my starting point, 因为这些将是针对自适应比特率(ABR)传输的“正常编码”的数据速率和PSNR值.

lowt1

清楚地把棍子插在地上, the production encode numbers in Table 1 were those I had to beat, and the 39.60 dB average is the number I will continually point to. 问题是, 我可以将传输数据速率降低多少，并继续等于或超过这些数字?

调整概述

在Netflix Mobile的博客文章中, the company achieved its bitrate savings three general ways: 1) using VP9, 2)优化H的编码设置.264 and VP9, 3)分割文件, and optimizing each segment separately rather than each file as a whole. I covered the same three points, although in a slightly different order; first I optimized H.264，然后应用逐块优化. 然后我对VP9做了同样的处理.

请注意，对于每个调整, 我讨论了它对于为下载而编码的文件和为自适应交付而编码的文件的效用. 有些只能下载, 但也有一些可以用来提高自适应比特率(ABR)传输的质量.

优化H.264

Table 2 显示了我应用于生产编码的更改及其在PSNR dB和百分比中的改进. All were directly inspired by comments in the Netflix blog post.

lowt2

The first adjustment was to change from the main H.264高调到高调. The potential downside of this change is 兼容性, 因为一些更老的iOS设备无法播放高分辨率编码的视频.

For Android, Google still recommends using the baseline profile for all H.264编码是因为H.264 decoder in the Android OS plays baseline only, 他们也不知道Android设备上部署了哪些硬件编解码器. Still, 苹果最新的HLS文件建议在所有流中使用high profile, 你可以期待大多数Android设备拥有与iOS设备相似的硬件功能. So, moving from the main profile to high is probably a safe change to make, irrespective of whether you’re encoding for download or streaming, 尽管收益不大, averaging .26db，等于0.66 percent.

关键帧间隔

在其优化设置的讨论, Netflix identified “increased random access picture period,” which I took to mean increasing the keyframe interval. 在我的生产编码中, I recommend a keyframe interval every 2 seconds, which I changed to one every 15 seconds for my optimized encodes. 如表2所示, this increased PSNR dB by almost a full percentage point, 所以手机下载是值得的.

增加关键帧间隔的一个缺点是减少了文件内的随机访问. That is, 如果你希望你的观众不断地导航到视频中的随机点, 增加关键帧间隔可能会增加这些操作期间的延迟. For linear playback of movies and TV shows from a mobile download, however, 其影响应该可以忽略不计.

However, 为ABR传送编码时, keyframes must divide evenly into segment duration, 通常是6秒或更短. 因此，编码ABR传送时应该使用的最长关键帧间隔是ABR片段的持续时间.

比特率控制/缓冲区大小

当我将受限VBR从110%更改为300%时，质量得到了最大的提高, 并将VBV缓冲从相当于1秒的视频增加到3秒. 这提高了PSNR .77分贝，几乎整整2个百分点. However, between the keyframe interval adjustment and this one, 我们将数据速率从一个高度可交付的平坦线改变为一个过山车式的高低起伏，在流媒体传输过程中很容易出现停顿(Figure 1). 当你从硬盘上回放时, 这没关系, 而是你更愿意将哪个流媒体传输到通过3G连接的手机上?

low1