LiveVideoStack线上分享第三季，第十二期，由京东云架构师张树军从基础出发，为大家阐述多码率视频流切换技术的原理与实现方式，并结合京东云视频云的实践，分析多码率帧对齐技术原理及其在多码率自适应切换中的具体应用。
文/张树军
整理/LiveVideoStack
大家好，我是来自京东云的架构师张树军，毕业于天津大学，先后任职于中电华大、永新视博、网易，期间一直从事于视频编解码和流媒体开发和架构设计等工作。在2018年5月加入京东云，目前负责京东视频云音视频转码相关研发工作。
本次分享主要会从以下七个方面来分享京东云在做音视频方面的心得体验，首先会为大家介绍京东云为什么会做多码率视频流切换以及多码率视频流切换的应用场景，另外会讲一下多码率视频流切换端到端的实现方式以及技术原理，然后会为大家介绍京东云在开发落地实践过程中遇到的一些问题，希望以此给大家带来一些启发，最后会有京东云在下一阶段要做的一些工作以及后续开展。
1. 深度编码的多码率视频流切换及应用场景
研发团队在最初接到多码率切换的产品需求时，在很短的时间内实现了一版从端到端实现多码率对齐、切换的解决方案，在对比了竞品公开数据之后，团队希望基于Codec角度去做一些深度编码的多码率对齐、切换工作。
多码率切换的应用场景分为设备多样性、网络复杂性、多码率流/文件对齐和多码率自适应切换四个方面，
2. 端到端实现方式
经过团队自研和调研之后，总结端到端的多码率切换对齐有Segment对齐/切换、GOP对齐/切换和帧级对齐/切换三种方式，对齐相当于在sever端做内容生产时要生产出对齐的视频直播流和点播文件，切换是指在客户端如何做流级的切换和文件级的切换。
2.1 Segment对齐/切换
Segment对齐在sever端的处理，不论是视频直播的流还是点播文件都需要多码率的输出，直播是多码率的流输出，点播需要有VOD多码率的点播文件生成，Segment对齐方式对于sever端需要切出Segment的IDR，在切割位置做到时间戳PDF对齐，对Segment内部没有要求。
Segment切换在播放端的处理，由上图所示，play代表播放器，res1、res2代表不同的码率，相当于多码率的点播文件输出。目前自动切换码率的技术可以检测用户目前网络的带宽和设备的性能来判断当前用户适合哪种直播流或点播文件，在手动切换码率时，用户点击切换码率后首先要等待当前Segment播完才能够切换到下一个Segment，这是由于Segment是IDR对齐的，可以独立解码，所以Segment存在的问题上Segment长度越长就越影响用户切换码率的时间和响应时间，用户体验会随着Segment长度的增加而越来越差。
2.2 GOP对齐/切换
GOP对齐在sever端的处理，可以在sever端加GOP，将多个GOP打在一个Segment上，Segment内部也可以是IDR对齐，GOP对齐相对于Segment对齐要求更高一些，每个GOP之前都有一个IDR，并且同时需要满足IDR和GOP 的对齐。
上图表示在客户端使用GOP切换的场景，每个GOP都是一个独立的解码单元，有一个IDR就可以独立解码，手动切换时会在当前GOP播放完成后播放切换码率的GOP。GOP对齐的切换优势相比Segment来说切换的时间要更短，因为GOP比Segment更小一级，而且基本上是最小的独立解码单元，用户使用体验要比Segment高一级。
2.3 帧级对齐/切换
帧级对齐在sever端的处理如上图所示，假设用户需要一个直播流或一个点播流，通过编码输出720P和540P两档码率，它可以做到两种码率输出后的每一帧对齐且每一帧的时间戳也对齐，相当于做到了最精细的对齐。
在客户端如果要做到帧级切换，对应的帧级对齐的流切换方式如上图所示，要做到帧级切换首先要做到对每一帧进行解码，帧解码要依赖于独立的GOP数据，也就是说要做到帧级对齐，GOP是最基本的cache缓存，每个流中要缓存一个GOP cache，使得每个流都可以独立解码，解码之后具体在display上显示哪种码率就可以根据切换命令来选择，这样做的优势是可以做到帧级切换（灵活度更高的无感知切换），但对用户终端消耗比较大。
2.4 切换方式对比
总结以上三种切换方式可以知道，Segment对齐就是最简单的IDR对齐，对客户端和serve端处理起来都很方便，缺点是切换速度较慢；GOP对齐在IDR中可以基于GOP做到更精细的对齐，切换速度比Segment对齐要快，但缺点是GOP固定，有人为因素干预编码器编码，质量有所下降；帧级切换由于是逐帧编码，切换速度最快，但对用户终端消耗比较大。
3. 技术原理
以点播举例，点播一般都会做2-pass编码，第一pass的数据肯定会给第二pass数据作参考使用，如果做点播多档转码输出，其实可以用其中一档的mbtree等数据去指导其他档的2-pass转码输出,可以做到各档次帧类型和时间戳均对齐，而且其他档的1-pass编码都可以省略，但由于其他档都是以参考档的1-pass数据去指导2-pass转码输出，因此输出质量并不是最优的，只有去参考自身的1-pass数据才能得到最优的编码质量。
京东云在此基础上改进了转码流程，增加了上图中紫色部分的模块（缩放W*H，特定YUV），保证lookahead输出的每一帧数据在多档输出统一一致，这样就可以保证无论直播还是点播，在各档次流或者文件输出时每一帧的picture type和时间戳都是对齐的。
3.1 数据损失评估
上述工作是为了达到帧&时间戳对齐的目的所做的工作，但还是要评估加上这些模块后对数据所造成的损失，因此团队做了有关数据损失的对比实验。使用默认的帧决策和指定的模块去干预lookahead输出的帧决策，分别使用4K测试集合1080P测试集作bdrate实验，bdrate为负表示同等质量下不对齐编码比对齐编码节省的码率百分比，bdrate越接近0表示对齐编码影响越小。最后对比数据的结果还在接受范围内，可证明改进方案是可行的。
3.2 直播对齐同步机制
在直播场景可以将点播逻辑直接拿来用，优化之前的直播对齐方案如上图所示，由于两个拉流的时间点和数据都不一样，所以在场景切换前无法做到对齐，在场景切换部分之后多档直播流就可以做到对齐，但如果有些场景切换特别长，对齐的这部分也会被拉长，直接会影响到直播体验，从功能上来讲也不是大家都认可的对齐。
因此京东云在直播对齐中将场景切换提前，引入一些同步的机制，在拉流的过程中做一些同步信息加入到流中，这个操作不会影响转码效果，一旦收到同步信息每条转码流可以在一个时间点插入I帧对齐，这样比没有加对齐同步机制的方法在体验上和功能满足性方面都有很大提升。
4. 实践落地中的挑战
京东云在实践落地时也遇到过一些问题，第一点，保证Lookahead数据一致性，同时Lookahead数据一致性也是对齐的前提，之后的picture type帧决策才能一致，后续做点播与直播相对也会变得容易，另外缩放算法必须保持一致，不同的缩放方式会导致数据产生差异;第二点，由于在方法中引入了额外的图像数据，这些数据一定要配合编码器的内存预分配机制，以上两点是在sever端需要关注的问题。在客户端方面，IDR帧一定是I帧，但I帧并不一定是IDR帧，IDR帧就是即时解码刷新帧，一旦遇到IDR帧所有之前的数据都被清掉，重新开始进入解码环节，不需要参考之前的reference参考帧，但I帧后面的数据可以跳过I帧再往前去参考之前的I帧，所以收到I帧之后去解码容易出现解码花屏。
5. 展望&总结
关于后期的展望，还有一些相关工作要去完善，比如支持变帧率对齐可行性、支持终端帧级别切换可行性、支持直播1.5pass可行性和优化lookahead冗余计算@1pass。
最后简单总结下本次分享，直播点播的多码率对齐中最关键的技术是引入同步各档次lookahead帧决策的工作，通过这些可以指导各档输出的picture type帧类型和时间戳一致，在直播的多码率对齐上京东云做了一些同步的工作，提升直播多码率对齐的使用体验。客户端切换目前是基于帧对齐的直播流切换，但目前还是以GOP为主的切换，后期会对其做一些帧级的深度优化。