第八章 交互技术，8.2 淘宝直播在双11的互动实践(作者：丰火)
8.2 淘宝直播在双11的互动实践
1. 简介
2016年中国的智能手机覆盖率已达58%，移动网络接入中4G+Wifi的占比也接近90%，这是今年移动直播能迅速爆发的一个重要的前提条件。在当前全民参与全民娱乐的大背景下，移动直播能随时随地的发起和参与的产品特点，也充分满足了用户自我表达塑造个人品牌的需求，加上移动支付的快速普及，愿意为优质内容付费的观众已经成为了大多数，按照这样的链路在直播场景下内容变现的商业模式已经非常清晰，基本上具备流量资源的各大互联网厂商都在今年杀入了移动直播的领域。
另一方面，移动直播作为一个连接用户的平台，实时性极强，借助移动设备随时接入的特性，可切入的场景也更多，双向的交互方式对于包括电商在内的其他业务模式来说也是值得探索的新玩法，所以随着这波浪潮的兴起，我们也快速启动淘宝直播来探索电商+直播的各种可能的方向，经过大半年的探索也得到很好的收获，同时也为今年双11直播会场的上线打下了基础。
整个过程对产品和技术上均带来很大的挑战，本文将为大家解析整个过程中所遇到关键问题和解决方案。
1.1 双11直播
从互动来看，需要支持多营销场景，典型如：九牛与二虎以及双11晚会直播间。九牛与二虎是一场精心设计的PGC制作的栏目，九个商家的同时直播，2位明星随机走访明星各个直播间进行PK的玩法，直播间需要提供9个房间的实时互通以及切换的能力。双11晚会对直播的互动的玩法要求非常高了，除了常规的评论、红包、关注小卡等，还有AB剧，红黑PK，点赞场景化等具体的业务需求外，还需要支持多屏互动。
从规模来看，要支持50W~100W的同时观看，同时要具备灵活的切换能力，对权益发放（如红包雨、砸金蛋）引发的QPS峰值要保障稳定的服务能力，这些也都需要从业务链路整体来梳理优化。总结一下核心面临的挑战主要有：
- 稳定性
50W~100W的同时观看
卡顿率的优化
- 实时性
播放的时延控制在<2s（排除人工引入的60s时延）
首屏打开时间小于1s
- 同步性
互动的实时推送能力
内容和互动的同步
- 带宽成本
在不降低画质的情况，节约带宽30%~40%
下面将分别对这些问题进行分别分析和方案解析。
2. 技术架构
直播作为一个实时系统，首要的目标是要将从主播端实时采集的音视频内容从网络推送到观众端，并保证整个链路的时延控制在1s-2s的范围内，整个流程上时延的优化是贯穿全局的重点。
2.1 基础架构
从架构图上可以看出，整个系统主要分为三个部分：
- 主播端：音视频的采集、编码、推流
- 阿里云：转码、截图、水印、录制
- 观众端：音视频数据的下载、解码、播放
2.2 架构重构
对直播业务进行了流程优化，使其具有更好的可扩展性和性能，主要体现在以下几方面：
- 开放性
支持1688、航旅、天猫系的直播接入，进行单独计费、结算。
- 可配置性
直播管理流程化，一个流程有若干处理节点组成，不同的个性化接入需求，配置不同的流程。
- 可复用性
每个业务流程中，对通用组件进行复用，不同的接入需求只需新增个性化的节点就可以快速支持。
- 高性能
优化了业务流程，增加本地缓存和前置缓存，双11晚会直播详情接口响应时间从14ms降低到7ms，直播列表页从114ms降低为54ms。
3. 核心优化
3.1首屏秒开
首屏秒开是指播放端用户从进入淘宝直播间到出现视频画面的时间在1秒钟之内，在极短的时间内呈现直播视频画面、已缩短用户的等待时间；在这1秒钟之内需要经历DNS解析、TCP建立连接、RTMP协议握手、流媒体数据接收/解析、视频解码、YUV数据渲染等一系列的环节。
推流端视频H264编码按照每2s一个I帧进行编码，然后按照RTMP协议打包发送到CDN边缘节点服务器，CDN服务器对视频数据从I帧开始缓存；只缓存最后一个GOP，即后面的GOP数据覆盖前面的数据，以保证视频流的实时性；流程如下：
CDN会在服务器上缓存最后一个I帧开始的GOP视频数据，此视频数据最大为2s(默认关键帧间隔为2秒)；当播放器端HTTP连接到CDN节点服务器后，CDN服务器会将缓存的GOP视频数据全部发送到播放器端。除了优化GOP缓冲之外，播放段也进行了多项优化：
- 业务依赖优化
在拉取直播间列表时直接返回播放地址，点击进入直播间时优先拉取音视频流来解析播放，收到首帧画面后进行后续业务逻辑，包括在线人数、评论列表等
- 播放预读缓冲优化
为了判断视频流、音频流的格式，播放器一般会预读一部分数据来尝试解码确定确定音视频的编码方式，而在淘宝直播中视频（H264）、音频（AAC）编码方式都是确定，完全可以避免这样的预读耗时。
双11期间最终数据如下，其中首屏平均加载 <1000ms
3.2 变速播放
在移动互联网络下，网络发生卡顿、抖动非常普遍情况下会播放器内部缓冲越来越大、整体累计延时也就越来越大，此时需要提高播放速率(如1.2倍速~1.5倍速)来降低累积延时；当播放器内部缓冲区数据越来越低时，需要降低播放速率(如变速到0.7~0.9倍速)来等待缓冲数据，避免频繁的卡顿与缓冲等待；
播放器的默认同步机制大多都是视频同步音频的，即以音频为基准时间轴，所以只需要改变音频的播放速率即可实现此目的，视频会自动进行同步；前提是在改变音频播放速率的同时不能降低声音播放体验；
播放器缓冲去大小策略数据如下图：
当网络发生抖动，播放器内部缓冲的音视频数据为5秒，此时累计延时就有5秒；在正常播放速率(1倍速)下，播放完5秒的音视频数据实际也需要5秒，累计延时不会降低，随着累计延时越来越高用户体验也会越来越差；当播放器前次发生卡顿恢复后，播放器下载缓冲的音视频数据达到6秒以上时，播放器会开启加速播放到倍速播放，播放速率会在1.1~1.5倍速之间浮动，此时缓冲内部的音视频数据会在短时间内播放完毕，如1.2倍速播放6秒视频数据会在5秒内播放完毕，会缩短1秒钟的累计延时。
同样道理，当网络发生抖动导致播放器内部缓冲的音视频数据小于5秒时，播放器也会将播放速率调慢至0.8~1.0之间以使缓冲长度恢复到合理长度以避免卡顿。
4 互动玩法
4.1 技术框架
互动是直播的关键功能，为了满足丰富的玩法，直播互动玩法的框架必须具备良好的开放性和定制化。一个典型的互动玩法交互的框架图如下：
实现互动玩法的开发和直播间功能完全解耦，承接双11期间红包、优惠券、进店小卡、关注小卡等多种玩法
最终的数据包括评论、点赞在内的总互动次数达到42.5亿次，互动率超过20%，提升了整个直播间的互动氛围表现。
4.2 帧同步
多屏互动的难点在于如何保证来自媒体流（音视频数据）和数据流（互动玩法）在时间上是精准匹配，传统的做法是基于是提升消息推送时间和到达率，但在实际场景因政策管制的原因最终播放的媒体流实际上有一定的人为延时（一般是60s），这样带来的问题：用户看到画面是时可能互动消息已经提前出现或者还没有收到，这都会导致互动效果大打折扣。
为了解决这个难题我们提出一套基于视频帧的解决方案：将互动内容作为视频的特殊帧封装到视频流里面。下面详细介绍下方案实现：
在H264视频编码标准中，帧是由一个或者多个NAL单元组成，而NAL单元又分为多种，其中有一些特殊的NAL单元其自身可以不携带任何音视频信息，如SEI_NAL。H264标准中，允许SEI_NAL单元由用户按照标准格式自己定义填充数据，且解码器在收到用户自定义的SEI_NAL时，默认不会对其进行处理。因此，我们将互动信息封装成一个SEI_NAL，将其打入到视频帧中并由主播端推送出去，最终播放器配合进行SEI_NAL的解析上报：
NAL_SEI帧的构造如下图所示：
每一次控制信息SEI的大小不会超过255字节，对视频文件大小的影响很小。
帧同步互动主要包括两部分：
- 摄像机推流时将控制信息写入视频帧
如下图所示，在林志玲扔衣服的时候，摄像机采集到扔衣服这一帧画面，由工作人员手动触发编码器，在当前帧写入控制信息， video数据和控制数据由推流端发送协议发送到服务器，服务器对此控制信息不做任何处理的下发。由此完成控制信息的写入分发。
- 播放端收到控制信息解析上报
播放器在收到帧之后，会判断帧中是否有控制信息，如果有，则会将控制信息sei从视频帧中分离出来上报给业务层，由业务层决定当前控制信息应该做什么操作。比如在用户收到林志玲扔衣服的sei时，会上报业务层该control，由业务层决定应该在界面显示一件林志玲的衣服。从而达到的效果就是视频里面林志玲在扔衣服，用户的界面上显示出了一件林志玲的衣服。
通过基于视频关键帧的互动方案，能够确保用户在视频的同一画面收到一致的互动数据，达到较好的互动体验，同时具备良好的扩展性。
4.3 直播连麦
直播的应用场景主要是两个重要的参与角色：主播与观众，而直播应用相比点播等传统应用的最大优势是：主播与观众的实时互动能力能给观众带来的更多的参与感，是除了传统互动方式包括文字，点赞，礼物等方式之外一种重要的互动能力，也是直播领域在未来的竞争重点。
直播互动连麦的流程是指：主播在直播过程中，可以邀请一个或多个观众或者其他主播进入直播间，可以和主播进行双向音视频通话，所有的观众在直播间可以看到他们的互动过程。而引入连麦功能，最大的技术难点：在对现有直播系统架构不做太大调整的情况下，提供低延迟的视频通话体验，同时兼顾未来的功能和架构演变，比如提供多方连麦功能等。经过综合考虑后设计的架构如下：
连麦中主播和连麦粉丝各推一路音视频流到服务器，同时拉取对方的音视频流进行播放，观众则观看连麦双方合并后的流。需要注意的一点是，为了保证连麦双方低延迟，主播和连麦粉丝拉取对方的音视频流均是低延迟流，而观众为了保证流畅度，拉取的是有延迟的流。
方案的优点：
1、并流功能在服务端来实现，可以降低手机端的性能压力和带宽压力，同时也更容易扩展连麦人数。
2、对现有直播架构改动不大，基本采用和现有直播架构相同的协议体系，开发成本低，稳定性有保证。
3、延迟低。实测端到端双方延迟可以达到500ms，其中服务端延迟平均只有几十毫秒，实测数据打破大家一直以来对rtmp协议延迟过大的认识。
连麦的延迟是双方通话的一项重要指标。整个过程的延迟主要有两类：
- 固有延迟，包括采集延迟、数据处理延迟、编码延迟、解码延迟、系统处理延迟、展现延迟等
针对固有延迟，在保证质量的情况下尽量降低部分参数的设置。如在H264算法可以采用延迟更低的baseline（会降低一些视频质量），采用延迟更低音频算法代替AAC等降低固定延时。
- 动态延迟，包括网络传输过程中由于丢包、拥塞等原因引起的延迟。
为了解决网络抖动引发的播放卡顿，在播放端引入一定的缓冲平滑播放过程避免频繁的卡顿。为了能根据网络情况动态确定延迟和流畅的最佳平衡点，我们引入了两个算法来解决：音频变速不变调算法和jitterbuffer控制算法。
在解决了上述问题后，最终的基础连麦能力得以完成，在双11造势期间我们也提供“全民连连看”作为直播的一种创新玩法，主打“一个正经的交友视频在线互动游戏”，取得了非常好的效果。连连看最终效果如下：
4.4 整体稳定性
互动权益在直播间的推送到达成功率是互动稳定性的最重要的指标，下图是整个直播互动在双11期间的数据表现：
为了达到整体稳定性的要求，主要在下面几个方面来进行优化：
- 全链路埋点监控
从消息的推送到互动层的渲染都进行完整的数据埋点，快速定位整体成功率。
- 消息的push&pull结合
将高频的评论消息和低频的状态消息区别开，用不同的策略来拉取
- H5互动玩法的优化
除了对“红包雨“页面的占用内存进行优化外，将常用的资源通过zcache进行提前推送降低渲染时因资源拉取失败导致互动玩法无法展示。
5. 带宽成本
为了满足带宽节约的目标，在播放端引入H265的解码算法，推流端不受影响依然保持H264推流，H265转码由云端转码服务完成，整体架构如下：
双11晚会开启H265转码后，整体节约带宽30%左右。
总结
今年是淘宝直播在双11的首次亮相，整个平台高峰时支持近50W的同时在线，同时支持了包括在会场和直播间内丰富多样的互动玩法，表现稳定。未来除了在功能上进一步加强整体运营的能力外，也需要完善全链路的数据监控能力，持续优化核心体验。基于阿里云底层的直播服务共同打造完整移动直播解决方案，提供包括直播SDK、消息通道、互动玩法等一体化开放平台。
