酷应用

降低 30% 视频码率，又拍云窄带高清转码实践 | Open Talk 2018 音视频技术沙龙·北京站分享实录

百家作者：又拍云 2018-08-09 13:27:18

7 月 28 日，又拍云 Open Talk | 2018 音视频技术沙龙·北京站顺利落幕，这是2018 音视频技术沙龙的第三站。

在活动现场，来自又拍云的多媒体开发资深工程师朱高锋做了《又拍云窄带高清转码实践》的分享。朱高锋负责又拍云音视频云处理相关的研发工作，致力于音视频前沿技术的研究和探索，对视频编解码、转码、封装等音视频技术，以及x264、ffmpeg等开源项目具有较深入的研究。

朱高峰介绍了何为“窄带高清”，以及又拍云实现“窄带高清”过程中的方式和开发思路。

以下是分享实录：

“转码”对于各家来说做法可能都不太一样，但是逻辑是一样的，我今天分享的是又拍云关于窄带高清的转码，贴近“转码”，更为底层，理论知识会相对较多一些。分享的内容主要分为两块，第一是介绍什么是窄带高清转码，第二是介绍又拍云窄带高清转码的实现方式。

首先说一下又拍云对“窄带高清”的定义：在编码标准不变，文件的封装格式不变的情况下，通过对画面场景复杂度进行智能分析、智能码率分配，节省 30% 的码流。

一、什么是窄带高清转码

△ 转码架构图

上图是传统的转码架构图，不管是本地文件还是流媒体文件，先通过解封装，使音频和视频分离，然后分别解码，示意图中间的 Option 是可选的。这个环节可以对音视频进行处理，比如回声去噪音，视频做画中画、视频图像的处理等。做好处理或者直接跳过这一步，再到转码，这时候就要经过编码，我们可以用各种不同的视频编码标准，音频也可以用不同的音频编码标准做一个编码压缩，最后封装起来成一个输出文件，这个文件可以是本地的，也可以是网络的流。

基于以上转码的架构，我们如果想通过转码，使转码后的文件变小，可以从三个方向做减少尺寸的操作（因为音频对尺寸的贡献量比较小，这里讨论以视频为主，音频暂不考虑）。首先可以采用新的视频编码标准，比如现在在研究的 H.266 ，可以降低大约 30% 到 50 % 的码率；其次是文件的封装格式，比如 FLV 和 MP4 ，受他们自身的封装格式影响，虽然封装的音频流或者视频流源头都是一样的，但是通过不同的封装格式，大小也不一样；第三点是窄带高清转码。

1、视频编码标准

视频编码的标准，目前主流的是 H.264，2003 年 H.264 的标准就已经制定完成，H.265 是 2013 年定稿的，但是由于专利费用太高，所以应用还是以 H.264 为主。关于 H.266 的标准定稿时间确定在 2020 年底，届时会推出新的编码标准。此外以谷歌为代表的 AOM ，从 2008 年到 2013 年的 VP8、VP9，当时是以谷歌为主推，因为在芯片这块的推广效果不佳，所以也只是在谷歌自家应用。 AV1 在今年年初定了标准，大家对此寄予厚望，认为它是可以和 H.265 抗衡的。另外，还有中国的标准 AVx，目前只在国内使用。

我们考虑以 H.264、H.265 和 AV1 作为主要的参考标准，当然后面一代对于前一代来说，号称码流节省都是在 30% 到 50% ，这其实是非常可观的数据。

△ 编码标准的演变

以上对比图显示，在相同码率下，AV1 比 H.264 和 H.265 质量都好；在相同质量下，它的码率更节省。

2、文件封装格式选择

△ 文件封装格式

上面是一个 YUV 文件的尺寸，包括分辨率和帧数的统计，YUV 文件原始 834 M，下面 H.264 裸码流编出来 4 M ，然后这个尺寸封装成 MP4 格式文件，MP4 格式的文件主要包含 moov 头和 MDAT（音视频数据）。moov 头内封装的是关于音视频每一帧的信息，包括大小、时间戳等，它只增加了 7K ；如果相同的码流封装成 FLV 格式的文件则增加了 12 K，因为这里帧数比较少，如果帧数比较多，还是很可观的。FLV 文件每一帧都有一个头，包括音频和视频，所以当它的文件增加一个尺寸，随着帧数越来越多，尺寸也会越来越大；TS 就更不用说了，它是188字节一个包，封装信息会更多，包括了一些媒体的信息等。

总的来说，对于实时性不强的场景，大部分都会选择采用 MP4 格式。

3、窄带高清

窄带高清是基于以上的曲线图考虑的：这里有蓝色和红色两个视频序列，蓝色表示运动比较缓慢的视频，比如我现在演讲，只是个人在动，背景都是静止的，相对来说内容的运动是比较缓慢的；红色表示运动比较剧烈的，比如《变形金刚》的电影。

以上两个视频序列的曲线可以这么来解释：PSNR 表示视频的质量，当在 40 dB 的时候，蓝色所需要的码率跟红色所需要的码率，一个是不到 1M ，一个是大于 2M 多，运动程度不一样的情况下，达到相同的质量，需要的码率是不一样的；而在相同码率下，比如 2M 的情况下，运动剧烈的可以达到 40 dB ，而静止的可以达到 45 dB，由此可见相同码率下，运动剧烈和不剧烈的视频质量不一样。

因此这里留给了我们一个操作的空间，我们在相同编码标准和封装格式不变的情况下，基于这两个结论，在人眼感知不到它质量失真的情况下，减少视频的码率。测试结果显示，码流的节省是非常可观的，一般可以达到30%之多；当然不同场景复杂度的码流节省效果不一样。

二、又拍云窄带高清转码实现

下面介绍又拍云“窄带高清”是如何实现的。首先输入一个视频转码的分片，接着进行复杂度分析，然后分场景转码参数，比如运动缓慢还是剧烈，当然这其中还会有码率控制的算法来调整编码器的输出，最终得到编码后的视频。

1、复杂度分析

关于复杂度分析，我们是借鉴了标准里面的 BT1788 关于空间感知信息和时间感知信息。空间感知信息是每一帧图像做一个 Sobel 值，然后分析它的纹理的多少作为参考标准；时间感知信息是帧与帧之间的帧差做标准差，作为时间上的变化情况。

又拍云根据用户的应用场景不同一共分了四类场景：手机自拍、动画、运动缓慢和运动剧烈。auto 是用户不用选择，我们会根据复杂度的分析自动选择上面四个最合适的方法。为什么需要进行场景分类呢？因为我们有的客户的视频源比较单一，比如一个客户只有手机自拍的视频，他就可以选择视频自拍。后面随着业务越来越复杂，我们还会有更细的一些场景分类。

2、编码器

a、H. 264 codec

△ 优化编码器参数——H.264 codec

上图是 H.264 编码器的框架，其实 H.264 和 H.265 的编码框架差不多，都是关于空间域和时间域的冗余压缩。H.264 的框架流程包括了帧间、帧内的预测、变换、量化、反变换反量化、熵编码和去方块滤波，因为目前编码标准都是基于“块”的编码，所以会出现“块效应”，所以需要去方块的滤波来提升人眼的主观质量。

b、H.265编码 codec

△ 优化编码器参数——H.265 codec

这个是 H.265 的编码框架，与 H.264 一样的混合编码框架。比如包括了帧间、帧内的预测、熵编码等，Deblocking 为了去除“块效应"，增加了一个新的 SAO 的滤波来消除振铃效应。

c、H.264 与 H.265 参数对比

关于 H.264 和 H.265 框架，虽然说他们的流程基本一样，框架也没有变化，但是他们“处处相同又处处不同”，在每个技术上都做了优化。

第一，H.264 块的尺寸是从 16x16 扩展到 H.265 的 64x64，这是一个指数级的块的复杂度的提升；

第二，关于预测，H.265 帧内的预测方向提升到了 35 种。因为 H.265 是针对高清的，包括 1080P、2K、4K，最高到 8K，这种图片的尺寸会比较大，所以它可以分大块，对于那些变化不明显的大块图像区域，可以用更大的块尺寸，可以在预测环节减少分块带来的复杂计算。对运动矢量也做了优化，并且对亮度和色度差值算法变的更复杂；

第三，加入并行计算，因为复杂度提升了很多，而且目前计算机行业的并行技术发展的也很好，所以在视频编码标准制定的时候加入了并行的优化，来节省编码时间。

d、H.265 编参数优化

△ H.265 编码参数优化

不管是 H.264 还是 H.265，他们的编码参数有几十甚至上百个，那么该如何设置呢？我们需要理论上去分析它在哪些环节花费时间比较长，然后在这些环节上做参数优化。

首先是帧间，因为现在都是基于块的，如果块预测准确，前后帧可能是完全一样的，这时候编码的比特就是 0 ；但是如果预测的不准确，它们做差异的时候可能会是一个很大的值，这样编码后的码率就会大，所以帧间预测的准确程度也决定了码率能节省多少。但是如果穷尽搜索或者全搜索的情况下，计算量会非常庞大。所以帧间预测的因素包括了运动搜索的算法、运动搜索的范围等。

目前我们的编码帧类型有 I 帧，P 帧，B 帧。B 帧包括被参考的 B 帧和无参考的 B 帧，I 帧理论说应该占比较多的比特，这样对于视频质量影响比较好一点，P 帧是前向参考，所以是其次大小，然后是有参考的 B 帧，无参考的B帧最小，是可有可无的存在。这种在做实时流的时候比较明显，你如果丢了 I 帧，相当于一个 GOP 的帧都无法解出来，全部都要丢掉，会出现错误扩散。

视频后处理，包括了去方块滤波、样点自适应补偿（SAO），会比较好的提升视频图像质量。并行计算的技术影响会比较大，此外还有码率控制和汇编优化。

3、码率控制算法

码率控制是在视频编码标准规定之外的，作用于编码器，是基于反馈机制来调节编码器的码流输出。比如当输出的时候，带宽突然变小，但是你还是按照现在码流的输出质量，它肯定会丢，这样会反馈到编码器，可以减少码流输出；如果带宽变好了，也会反馈到编码器上，输出更高质量的码流。

码率控制在学术上分为两类，一种是 CBR ，恒定的码率，另一种叫 VBR ，可变的码率，但是在实际应用的时候会有一些变化。码率控制会根据不同的应用场景会有一些变化，比如本地文件或者针对流，码率控制的策略都不一样。针对流肯定是用 CBR ，但是它会存在浪费带宽的情况，质量不会是最好的。

关于具体的码率控制的模式，比如恒定的 CQP 量化参数来进行编码，这个基本是用来做学术研究，验证编码器质量的好坏，它的好处是比较快，可以更好的鉴定编码器的情况；平均的 ABR 的码率是 vbr 的一种；CBR ，它会设置一个固定码率大小，因为在流媒体应用领域，一个带宽的多少会有固定的值，比如最高不能突破 2 M ，所以这种方式会用；N-pass ，比如 2-pass 码率控制方式，因为需要两遍编码，只能应用在实时性不强的情形，他会码率控制的更准确，但是因为需要两遍所以时间消耗比较多；CRF 的原理和 CQP 类似，但是这种考虑了运动缓慢或者运动剧烈的情况下所需要的码率不一样，做了一些码率的优化分配的方式；VBV 这个是一个缓冲池，因为码流控制是基于一个反馈机制的，所以也是需要缓冲池的机制来保证。