作者| 阿里文娱技术专家 泫野

在全民互动、红包与优惠券齐飞的双 11 盛会之下，对于阿里内部而言，实则是「练兵千日 磨一剑，用兵一时见功夫」的实战训练场。对此，阿里巴巴集团董事局主席兼首席执行官张勇（逍遥子）也曾说过，「没有参加过双 11 的叫同事，参加过双 11 的叫战友」。而如今这场以技术为支撑的“战役”究竟有多复杂？在面向瞬时的高并发场景时，阿里人又是如何做到无懈可击的？

一、2019 双 11 猫晚直播的技术战果

首先回顾下 2019 双 11 猫晚直播过程中的一些亮眼成果，主要是四个方向：

第一是高清战略

今年猫晚直播超高清占比用户达到了 93% 。从清晰度档位投放上，相较于往年的 1080P、 720P 高清档位，今年我们还大规模投放了 4K、杜比（720P、1080P、4K）、50 帧等更高画质音质档位的内容，为用户提供极致的视听体验。

第二是节省成本

今年在高清战略的大背景下，用户侧平均码率大幅提升，对用户端的卡顿和带宽成本带来 巨大挑战。我们为此加强并引入了新的带宽节约核心抓手，最终今年带宽消耗成本不升反降， 节省带宽成本达到了 35%，同时达成了高画质和低成本俩个目标。

第三是基础保障

直播项目整个工程的一大特点，就是实时制作生产内容，并且链路非常长。从制作、生产、 传输、转码、分发任何链路上的一个小问题，都会导致用户体验上的下降，比如出现卡顿、花 屏、甚至无法播放等等问题。
今年我们也在流全链路和服务链路上做了大量优化工作。最终得到了 0 故障 0 降级操作的结果。

第四是创新能力

猫晚首次引入杜比全景声与帧对齐技术，在音频和视频两个层面来提升体验。

二、目标与挑战

第一是高体验目标。

我们在目标落地过程中，定义了三个技术方向：

1. 高画质方向

提升码率是提升用户画质的主要手段，但是在千万用户量级下，高码率的瞬间抖动，很可 能导致带宽消耗超出我们准备的带宽资源水位，造成用户侧出现整体卡顿甚至故障的发生。
历届猫晚中经常出现分钟级别，码率变化 2-3 倍的情况发生。这种情况下，与我们使用 VBR 转码方式是分不开的。VBR 优势在于简单画面下转码码率很低，用户侧对于下载网速门槛要求 不高，有助于用户避免卡顿；但是当出现复杂画面时，转码码率会快速增高，这种瞬间的码率 抖动不仅影响我们的带宽水位，还会导致用户卡顿提升。
针对这个问题我们需要有效的峰值码率控制，和码率抖动控制手段。

2. 低卡顿方向

用户侧的网络环境、硬件环境、设备能力参差不齐，如果只是一味的提升码率而投放默认 高清晰度档位，就会造成用户侧的卡顿问题发生。因此我们要有效识别端侧环境的能力，进而 调整清晰度的手段。
同时直播内容在实时生产过程中，任何节点发生故障都会造成用户侧的卡顿，甚至无法播 放的问题发生。我们需要一套可以实时、自动的故障容灾体系支撑我们复杂的直播链路场景。

3. 提升视听体验方向

今年猫晚进行了多视角的形式进行直播，用户可以在 C 端进行多路视角内容间切换，但是 由于不同流的进度不一致，会出现视音频回跳问题，导致用户体验下降。猫晚作为综艺类直播， 历年来音频体验同质化严重，也是我们重点需要提升的部分。

第二是低成本目标。

千万用户量级下，带宽消耗巨大，同时会带来高昂的带宽成本。另外我们的带宽资源有限， 需要严格控量使用。因此，我们要从省带宽、低码率上提供有效的技术抓手。保障我们的直播 过程既能做到高画质，又能拿到低成本的结果。

三、技术策略：核心抓手 + 基础保障

第一是高画质低成本抓手

今年优酷直播首次引入 FPGA H265 转码技术，目标提升整体 H265 覆盖率效果。FGPA H265 具备的能力：
1）提升转码压缩率，可降低峰值码率，从而降低带宽成本；
2）码率波动更小，有效降低带宽水位风险；
3）针对高分辨率高码率的实时转码能力。

第二是高画质低卡顿抓手

针对 C 端用户环境复杂问题，今年猫晚首次从制作域、视频云、播放域三域共同能力，落 地了直播智能档能力：
1）具备基于 QoE 的自适应清晰度能力；
2）流链路自动容灾预案能力。

第三是视听体验提升抓手

1）针对于猫晚的多视角直播场景，自研落地了一套视角帧对齐技术，多路流间也能具备帧 级别平滑切换能力，提升切换过程中视音频的连续性与一致性；
2）首次引入杜比全景声技术，让用户体验身临其境的效果。技术落地过程中，建设了一套 SRT 低延迟回传链路。

第四是基础保障

在流的生产分发全链路中，我们落地了完整的热备方案，及对应的故障自动发现自动执行 的预案机制，保障直播过程中的万无一失。

四、高画质低成本：FPGA H265

H.265 转码是一种常用有效的降低码率手段，可以在保障画质的前提下，压缩峰值码率， 从而达到节省带宽的目的。
提升 H265 覆盖率的方法，主要从 2 个端进行：

C 端播放器：提升各端播放器 H265 解码播放能力，做到全端全版本的覆盖。为了保证 播放体验，优酷直播优先采用硬件解码方式，通过白名单的策略，在测试覆盖范围内的 设备开启 H265 解码播放，低配机型上我们会慎重开启；

S 端转码层：全部清晰度档位，做到 H.265 转码。让任何档位上播放的用户都可以有 H.265 的流。但是行业主流采取的 CPU H.265 转码方案，在高分辨率高码率下存在吞吐瓶颈。

如上图所示：CPU H.265 转码在 720P（50 帧）以上清晰度档位，在保证画质和压缩率的前 提下，存在吞吐方面瓶颈，无法做到实时转码。
替换方案上，我们对比了 GPU 和 FPGA 硬件架构。在 GPU 性能对比中发现，GPU 在同压 缩码率下，画质比 CPU 差很多无法达到我们的画质需求。我们进一步把选型目标放在 FPGA 上。

画质对比

结果：FPGA H265 在同样压缩码率下，达到 x265 slow 级别的画质，符合我们对于画质和 压缩率的要求。

吞吐对比

结果：FPGA H265 吞吐能力是 x265 slow 级别的 12 倍。双 FPGA 实例可实时转码 4K60； 单 FPGA 实例可实时转码 4K30/1080p120，或者任意组合成相同吞吐的其他分辨率。
在做到与 CPU 相同压缩和画质效果下，FPGA 转码在吞吐能力上远远超出预期。双实例 4K60 的实时转码能力，覆盖了我们目前所以清晰度档位对于 H.265 转码的需求。下面我们进一 步验证了 FPGA H265 在实际转码中，对于峰值码率降低和码率波动控制方面的效果。

在实际转码中的效果：
1）相比 H.264 转码，峰值码率下降超 22%，达到码率节省效果预期；
2）码率抖动更平稳，有利于避免用户卡顿问题；
3）强大的吞吐能力，各档位 H265 转码做到了全覆盖，整体 H265 覆盖率得到了提升。

五、高画质低卡顿：智能档

智能档的核心作用就是基于用户端实际环境，自动为用户适配成合适的流进行播放。例如： 用户侧下载网速差，1080P 这种高码率档位无法做到流畅播放，通过端侧智能档的 QoE 智能评 分，可以发现并帮助用户自动适配成一个与其网速匹配的流进行流畅的播放。

那么智能档具体哪些能力呢？

1）QoE 智能评分 对用户环境、设备、硬件、网络、带宽等等因素进行综合评分的能力； 2）智能档播控配置在用户首次进入直播间时，未对其 QoE 打分前，我们需要播控提供默认的起播配置；同时 在智能档自动切换流的过程中，同样需要播控提供流的调整范围。
智能档 M3u8 相较于普通的 M3u8 文件不同，智能档会在转码的 M3u8 文件外再封装一层 Master M3u8 文件（如图云端 Master m3u8 切片），其内部是各个转码对应的子 M3u8 文件，调 整范围配置就是要在这些子M3u8 文件间进行调整。
主要作用：支持针对于播放场景的自定义范围，例如大屏在 720P 和 1080P 间选择，小屏则在 720P 和 480P 中选择，这样做到云端生产一份 Master m3u8 文件（缓存），多场景都可以使用。
3）帧级别平滑切换能力 智能档核心作用是帮助用户自动适配合适的流进行播放，整个自动切换过程中对于用户是无感知的，我们要保障切换过程中，用户在感官上的内容（包括视频和音频）连续性，不会产生卡顿的感觉。（帧对齐的解决思路会在后文中进行阐述）
4）自动容灾预案能力 智能档对流的探活能力，配合其帧级别平滑切换能力，可以在流发生故障时，帮用户快速进行流地址的切换，避免发生卡顿或播放错误的情况。
从转码层上，为了避免转码链路的单点问题，我们在华东和华北双机房同时进行热备转码； 从切片层上，封装 Master M3u8 时会把华东和华北的转码 M3u8 文件作为俩个组封装在一起。 这样给到播放器，播放器才有能力在某一路机房转码有问题时，快速切换到另一路机房转码的 m3u8 文件，让用户在流故障发生时，也能得到顺畅的播放体验。

六、视听体验：视角帧对齐

首先看一下业务场景：猫晚直播过程中，我们在现场舞台的各个角度架设了摄像机，例如 演员在唱歌，摄像机 1 拍摄侧脸，摄像机 2 拍摄正脸。在播放器中用户可以通过切换视角方式， 来自主选择看侧面还是正面。
由于双路摄像机的流，同通过不同的编码器、链路上传到云的，会存在进度不一致的问题。 用户切换过程就会出现画面或声音回跳的问题，例如明星唱了一句歌词，切换后可能由于画面 回跳导致又唱了一遍，造成用户体验的下降。
所以，帧对齐的目标就是通过技术解决多路流之间切换，保证画面前后一致性连续性，从 而提升用户体验。主要应用场景包括：自适应码率、多视角内容切换、云端画面合成、异地容 灾预案等。

1. 画面不对齐的原因

1）不同的流，编码器开始推流时间不同，导致同一帧画面的 PTS 不同；
2）同一路流，视频云转码任务启动时间有差异，并重写了 PTS，导致各转码的同一帧画面 PTS 不同。

2. 解决思路

需要从制作域，视频云，播放域整体改造，实现帧对齐能力：
1）制作域：多路编码器间，推流时需要带入统一参考系，用于云端对齐。在参考系选择上， 我们使用的从 ntp server 获取绝对时间戳，时间戳本身不会被地域限制，在异地推流场景下也适用；
2）视频云：针对不同转码间，PTS 不同的问题。云端实现了直接使用源流 PTS 透传（PTS COPY）的方案，这样各路转码任务启动时间虽然有差异，但是都是使用源流同一帧画面中的 PTS，从而保证了个转码的 PTS 一致；在切片服务中，需要保证同一帧画面在同一切片内（即保证切片序号一致），因此我们改进了切片序号的算法，从基于 PTS 计算改造为 PTS+推流时间 戳来计算的方式；
3）播放域：做到多路流间，同一帧画面在同一分片内（TS 文件），播放器有能力并做到了 非关键帧级别 seek。了解编解码的同学应该清楚，直接从非关键帧起播会出现花屏等无法播放 的问题，这里面我就需要从 I 帧进行解码，但不显示出来，直到解码到 seek 的帧后进行解码并 显示，通过这个优化来实现非关键帧 seek。
整体方案，在猫晚过程中达到了帧对齐的预期效果。我们相信这套技术的沉淀，可以在未来多个场景中应用，并促进直播内容制作的新思路。

七、视听体验：杜比全景声

今天首次采用杜比全景声能力进行猫晚直播，在音质体验提升目标上，启动重要作用。整 体技术方案落地难点，除了 C 端播放器覆盖杜比 e-ac3 音频解码还原成杜比音效的能力，更多问题存在于传输链路上。
下面先看一下广电是怎么做杜比内容传输的：

广电方案中，通过现场编码杜比音频，信号通过光缆或卫星回传给电视台的演播室，再通过同轴或光纤传输到家庭的机顶盒中进行解码播放。
整体链路上达到广电级安全标准，可靠性非常高。但对于线路上成本也非常昂贵，并不适用于互联网方案。

在互联网直播场景中，我们分析了友商的方案，基本是基于广电转播的模式。 现场编码杜比音频，通过光缆或卫星回传到自己的演播室，演播室通过 UDP+TS 文件+内网专线回传给云端，云端最终分发给用户进行播放。
其中的问题：
1）演播室后方人力成本：由于现场要回传给演播室，则需要大量后方人力。面向中小型甚 至个人发起的直播场次，是无法 cover 住这部分成本的。
2）网络部署成本：由于 rtmp 公网协议中，我们无法传输杜比的 e-ac3 音频，只能采用原始 的 TS 文件+UDP+内网专线方式回传。云部署的机房只能开通白名单方式开通回传链路，这样 就增加了部署成本，并且无法做到回传链路的通用性。

为解决以上方案的成本问题，今年优酷直播协同阿里云，共同推进落地基于 SRT 公网协议 的低延迟回传链路。
SRT 是一种可以在复杂网络环境下，进行实时传输数据流的开源传输技术。传输层是采用 UDP 协议，具备开销低、速度快的特点。SRT 具备支持多种流类型的特性，可以回传杜比的 e-ac3 音频，阿里云收到回传流会进行云端解封装，视频部分通过 rtmp 协议内部传输、转码、切片， 杜比音频部分则会透传方式进行传递。从用户的体验来看，用户听到的音频，就是直接从现场 制作好的杜比效果传来的，保证了杜比效果的原汁原味。
整套回传落地后，我们节省了演播室大量的后方人力成本和网络的部署成本。基于 SRT 协 议公网传输链路，支撑了中小型直播甚至个人发起的直播，也能制作杜比直播的场景。

八、基础保障：现场&视频云链路

如图所示，直播流链路非常长，任何节点出现问题都是导致用户侧的无法播放、卡顿等问 题发生。如何做到绝对的万无一失？
核心思路有两点：
1）全链路上的热备
2）故障自动发现和自动预案执行能力以下详细解释一下全链路上的热备工作：
1）信号热备
猫晚的现场信号，是从浙江转播车中通过线路给出的信号。如果线路或信号源出现问题， 会导致我们无信号可播的状况。因此我们在杭州异地，准备了机顶盒的广电信号进行备份，如 果现场信号有任何问题，我们有能力直接使用广电信号为用户进行转播。广电信号的安全标准 是非常高的，如果出现问题说明电视台播出也出现了故障，这种情况基本不会发生。
2）现场硬件热备 现场导播台、编码器等硬件，我们会准备主备硬件，以热备的方式，同时进行推流。阿里云侧，实现了高可用的热备 relay 拉流转码能力，可以实现优先从主编码器拉流转码，当主编码器流链路故障时，可以在 6 秒内自动切换到备编码器流链路上，继续为用户提供流内容，端侧 用户无明显感知。
3）网络热备
如果现场 Wi-Fi、有线网络断掉，导致无法推流时，我们现场还准备了 4G 背包，通过 4G网络可以将流推到云上，保障链路畅通。
4）传输链路热备
在现场与视频云间，我们拉通了 3 根 VPC 专线，分别是电信、联通、移动运营商。由于现 场在上海，我们优先使用电信的网络专线，当运营商链路出现问题时，可以做到 2 秒中内自动 切换到其他运营商链路上，持续的保障链路畅通。
5）转码中心热备 数据流千里迢迢到达视频云后，转码任务也会存在单点问题。如果转码任务转出内容画面有问题，或码率没有控制住，此时必须降级并重启转码任务，同时会造成部分用户播放的中断。
针对转码问题，我们同时在华东和华北双机房配置了相同的转码任务，并同时开启转码。这样 当任何一个转码机房出现故障时，我们有能力通过云端修改链路方式，使用另外一个备用机房 转码为用户提供服务，保障用户侧的观看体验。
今年猫晚在技术上做到了信号、硬件、网络、传输链路、回源中心、转码、切片、播放， 实现了全链路热备，以及故障快速发现自动修复能力，保障了今年晚会万无一失。

九、基础保障：服务链路

除了流链路稳定性，我们在服务链路也做了大量优化保障工作。服务链路保障的目的是，在千万级用户流量涌入到直播间后，用户可以正常的进入直播间并且拿到流地址进行播放。
整个优化工作可以分成几步：
梳理流量入口，尤其是触达类 PUSH 引流入口。PUSH 引流能力具备快速将入口触达用户， 用户会在短时间快速涌入直播间的特点，是影响服务 QPS 峰值的核心稳定性因素。如果多个 PUSH 引流同时发送，QPS 峰值则会出现叠加的情况；
1）基于实际业务场景，在网关层进行限流和防刷，同时要避免无意义的 QPS 叠加。在需 要投放多个 PUSH 引流入口时，我们尽力避免同时发送，而是有节奏的间隔一段时间发送，避 免峰值叠加造成的稳定性风险，同时造成服务器资源浪费；
2）除了网关层限流，防止流量穿透导致应用层出现雪崩。应用层本身也要进行限流，防止 网关层出现没有限住流量的情况发生，达到双重保障。另外应用服务我们要进行多机房部署， 甚至异地部署，规避机房单点问题带来的稳定性风险；
3）核心链路服务的下游依赖，也要做限流防控，避免流量过载导致宕机。同时针对下游依 赖，我们做到了秒级的自动熔断能力。整个流量洪峰会在几秒内到达，通过人工方式发现和进 行熔断动作是来不及的，存在下游依赖出现超时或错误，拖垮核心链路的风险。另外，核心链 路上的所有下游依赖，我们都进行了弱依赖改造：即使下游所有依赖，包括存储都挂掉，我们 的服务仍然可以给到用户一个可播的流地址，从而在服务链路上做到绝对的高可用性。
今年猫晚播放服务可用性达到 99.99%以上，服务平均 RT(99) 36ms，0 故障，符合预期。 同时猫晚项目 1 个月内共进行了 5 次全链路压测，10 多次线上直播链路演练。几乎 1 周 1 次的 全链路压测，隔一天 1 次线上演练，这也是和链路上各个团队的努力分不开的，共同保障了今 年猫晚的万无一失。