腾讯云海外音视频技术架构 — 挑战和优化

文 | 胡仁成

整理 | LiveVideoStack

大家好，我是来自腾讯云音视频团队负责海外直播技术工作的Enson，很荣幸有机会和大家一起探讨技术相关问题。今天，由我代表团队分享一些我们在海外音视频架构实践中遇到的一些挑战和优化思路。

今天的分享主要分为三部分。前两部分都属于基础平台架构中的挑战和优化，包括接入，边缘传输，第三部分区别于前两部分，它是结合海外应用居多的OTT场景上的架构实践和技术优化。

在聊具体问题之前，先了解一下腾讯云直播基础架构。总体上分为两部分，第一部分是源站系统，用于流接入、流处理、流存储等。源站系统整体采用去中心化、区域自治设计理念，依托于腾讯云IDC全球互通的内网专线，实现网状互联。结合CDN系统形成一个星型辐射模型。真正意义上实现就近推流、就近处理和就近分发的能力。然而，全球复杂的接入条件以及多元的网络环境也给接入和边缘加速带来了巨大挑战。

1. 全球接入挑战与优化

第一部分是接入挑战和优化。

1.1 挑战

不同于国外，中国运营商两个手都可以数的过来，基础网络设施建设非常齐备。海外覆盖190+国家和地区，有数万家运营商，通常不仅存在国内遇到的local DNS、public DNS多出口导致调度不准等问题，而且建设资源远远落后于国内，另外，在一些突发场景下保证平台稳定性等一些问题都给接入方面提升非常大的复杂度。比如右上角表格可以看出，部分国家的调度精准度优化前后，提升非常大，对传输质量也产生了很大的影响。

面对如此复杂的环境和条件，我们针对接入提出了四个优化目标-更快、更准、更稳以及更加“智能”。

1.2 优化

接下来介绍优化的四方面工作，DNS解析优化（如何把调度做得更快）HTTPDNS优化（如何把调度做得更准）、弹性调度优化（如何使平台更加稳定）以及网络接入优化（如何把网络做得更智能）。

1.2.1 DNS解析优化

DNS优化可以从解析流程说起。用户在腾讯云云直播上注册域名流程基本分为两部分：

第一部分是业务域名解析，这部分对于平台没有优化空间，属于供应商布点能力建设。

重点介绍第二部分平台cname域名的优化。常规的方案是增加海外权威的布点。在平台设计之初为了容灾切换，设计了多层cname，当第二层cname解析耗时过高，整个local DNS就会很漫长，加剧了解析耗时。老的架构的解析耗时与竞品耗时相比排在最后一位。于是我们通过实施cname减层的优化方案，在同时满足容灾的要求的前提下达到local DNS一次解析就能拿到A记录，完成解析的效果。我们通过海外第三方拨测平台catchpoint无差别拨测，对比优化前后，解析耗时降低了很多，对比众多竞品也排名前列。以上是如何优化解析耗时。

1.2.2 HTTPDNS优化

早期海外CDN服务没有专门的HTTPDNS服务，使用了公有云HTTPDNS服务，很多厂商HTTPDNS服务（包括国内部分），在解析存在几个常见问题：一是IP库老旧导致海外部分国家识别准确率低。二是缓存粒度大，为了避免用国家+省份+运营商缓存复杂度高的问题，早期使用单一国家维度缓存，结合问题1容易造成缓存污染，引发短时间大面积调度异常；三是运营能力差，IP修正、问题排查、调度干预耗时较长，无法满足现网精细化运营的要求。面对这些问题，我们在20年初开始重构海外CDN专用的HTTPDNS服务。首先，在网络层部署足够多的anycast接入点，优化接入耗时和提升接入连通性。其次，在服务实现上，缓存粒度精细到国家+省份+运营商做缓存，整体精准度更加高。另外，在运营上能够分钟级修正IP归属，秒级剔除异常节点等能力，精细化运营能力得到提升。灰度新版本HTTPDNS后，部分国家比如阿塞拜疆、卡塔尔业务曲线，首帧耗时优化非常明显。这块是更准的调度优化实践。

1.2.3 弹性调度优化

在海外有限资源的条件下，业务突发对平台的稳定性带来非常大的挑战。从资源开销维度来看，主要是算力和网络两大类。

算力的消耗最高的是转码，早期的转码资源都是区域源站独立占用。在单区域突发时如何支持平稳服务？为了优化这个问题，结合资源大区之间时间差，我们提出了公共算力资源池以及分时调度的方案，打破固有的逻辑层区域自治限制，达到资源共享，增稳降本的效果。

另外，为了确保平台稳定性，做了一些柔性降级策略，比如buffer池用完后不转码，在极端情况下保证平台可用性。

在网络调度方面，不同于国内运营商互联能力差，国外跨运营商互联能力比较好，这时提出了区域覆盖的概念，实时负载达到一定阈值，用一定区域资源覆盖应对突发，以上是保持平台稳上做的工作。

1.2.4 网络接入优化

最后一部分就是“智能”网络调度能力建设。前文说过海外运营商非常多，但是不同于国内，他们也有一个优点，就是大部分运营商之间的互联能力较好。在这个特点下，目前我们在海外CDN机房网络接入方式这里分为三类，Transite、IXP以及Peer。

Transite一般是付费供应商，具备穿透能力，互通BGP路由，同时能够作为上联，互通全球。特点是贵，质量好。IXP一般是中立的流量交换平台，租赁端口的形式接入，成本低，没有SLA，故障率高。Public Peering，一般是免费的对等直连，与头部运营商直接互联，只支持单AS的流量传输。这三种接入方式的优劣势决定了我们需要在成本、出口均衡、容灾、质量优化这四个目标中找平衡。

首先，需要获取Top运营商、出口成本分类、机房出口等基本信息，作为关键的基础计算因子。再构建实时流量采集、分类统计、结合质量探测数据，达到四个要求间的均衡，从而实现“智能调度”能力。

总结来看，我们通过多维度的优化，提升了整体接入能力，当前的接入调度架构如上图所示，具备多种接入方式，能沟结合容量、质量、实时探测数据、成本，生成梯度的调度策略反馈调度系统，实时干预调度。

以上接入调度这块的优化工作介绍。接下来介绍下边缘加速协议上的一些优化。

2. 边缘传输挑战优化

接下来介绍下边缘加速协议上的一些优化。

2.1 挑战

这些年在海外发现挑战分为两类：第一类是边缘网络的复杂性，包括延迟、丢包、抖动带来传输上卡顿问题。第二类是客户选用的协议本身的缺陷不适合直播场景导致QoS受损的问题。

2.2 优化

接下来分别介绍下针对QUIC和WebRTC中的一些特性针对直播场景的优化。

2.2.1 QUIC优化

QUIC优化分为几大块，首先是对QUIC中BBR拥塞控制算法的优化。BBR运转于4种状态的状态机。绝大部分时间停留在带宽评测阶段，结合直播场景我们对四个状态默认算法进行了优化。

针对首帧，在START_UP阶段，直播很在意首帧，假设首帧数据量为60k，我们在最短的时间内，在起始窗口发出，假设网速足够强大能力下，那么是能够提升整体首帧指标。然而边缘网络带宽并不一定足够好，需要采用自适应能力结合终端历史网络信息作参考进行优化发包。

在带宽评估阶段，直播由于编码器特点在不同场景下产生数据量不同，静态画面很少，突然复杂场景产生很多数据量，在数据源产生突变时，对拥塞算法在发送端影响很大。我们的评估不仅关心接收端，还需要关心发送端，结合实际运营经验，我们发现直播场景下，默认带宽评估算出来的窗口往往是偏小的，于是我们提出要采取窗口补偿。另外，QUIC是应用层的，把QUIC切后台后，会发现ACK驱动停止，当再切回去后，RTT会有很多大噪点，所以会发生很多由业务行为产生的噪点，这不是真实的网络特征，如何将噪点剔除？这也是要求我们去通过更好的滤波器去优化这块RTT噪点。

第三部分针对最小RTT探测状态优化，进入PROBE_RTT的时间周期以及周期内的发送窗口，默认值不适合直播场景，通过算法参数调优提升了直播场景的传输稳定性。

2.2.2 WebRTC优化

其次，是对WebRTC发包策略的优化。腾讯云把WebRTC协议作为低延时技术放到传输系统中去做。早期快直播刚上线卡顿率增加了很多。分析了很多场景，大家会认为在低延时情况下，buffer小了，卡顿率偏高，然而调整buffer足够大时，发现还是偏高。我们分析了一种场景，在高清直播游戏流环境下，单个I帧普遍非常大，处于限速环境下的客户端会频繁触发限速丢包。在默认算法的作用下，整体发送速率降低，引起播放端卡顿。为了解决此问题首先识别出终端网络限速。其次要兼顾直播流帧率、I帧大小以及评估出的极限带宽等因子，做一定的均衡计算，计算更优发包速率，达到更平滑发包效果。

对比左图，可以明显看出优化前后，巨大差异以及对比竞品我们的优势，毛刺越少效果越好。

2.2.3 QUIC0RTT特性对首帧影响

再分享QUIC 0RTT优化首帧的分享。第一阶段在海外一个现象级应用服务中推进迁移QUIC，完成了http\https到QUIC的全量迁移。建连平均耗时从2.3RTT优化到0.23RTT。第二阶段，对0RTT校验逻辑优化，进一步提升0RTT率到98.8%。整体平均建连耗时近乎于0。从业务收益数据对比来看，首帧收益非常大，特别是部分RTT比较大的国家和地区。

2.2.4 WebRTC首帧优化

原生RTC不适合直播的原因是首次建联开销较大，可能会有6个RTT。基于这个问题，我们主要的思想就是将原有交互流程压缩，合并信令，用UDP替代TCP发包，压缩包的大小，通过定时重传的方式进行补偿，基本能实现0RTT的建连。针对弱网案例，由于过多重传引发的“重传风暴”问题，对极端弱网用户不友好，我们提出了冗余策略调整，发包次数和间隔都线上数据进行验证调优。最终首帧这里能够追平FLV场景下的数据。

综合实验数据和实际线上业务数据收益来看，整体优化都是非常明显的。

随着客户的需求累积和我们对多协议的优化和集成，一些客户需要QUIC、WebRTC、RTP等。为满足多样化的接入，我们构建了多协议加速平台、用插件式方案进行管理，针对性优化。

3. OTT架构实践及技术优化

综上都是对基础平台能力的优化介绍。

第三部分主要介绍海外特有的广泛的OTT场景的技术架构和实现。在国内已经卷不动了，邀请大家一起去海外OTT行业卷一卷。

3.1 OTT市场背景

海外的OTT市场非常大，千亿美金市场，发现海外比如AWS、GCP等知名云厂商提供音视频解决方案基本都是OTT行业的，这么大的市场和这么多供应商，我们就想去海外卷一卷。从技术能力特点上来看，要求7*24小时本地运行，播放媒体协议差异性，国内喜欢RTMP等，他们用的更多的是MPEG-DASH、HLS，还要求多码率自适应；对低延时追求有CMAF、LHLS等方案；内容版权保护需要具备DRM能力；另外OTT平台商业模型不同于国内直播打赏，海外都是靠广告，如何以标准化方式支持广告插入能力，这方面也有针对性的标准协议。我们需要满足以上技术能力去满足产品化需求。

3.2 OTT技术机构图

基于这样的技术需求以及我们对海外OTT解决方案供应商的一些产品能力调研后，我们设计实现了基础的OTT技术架构。整体特点包含全球化和高可用，需要丰富多样的媒体格式支持，对数字版权保护和增值服务技术有强需求，最后就是多CDN的方案。面对这样的需求，我们的技术架构就摈弃了原有云直播一体化的设计方案。根据原子能力抽象出三种不同特点的服务平台。一是跨境低延迟加速传输平台，具备丰富多媒体协议格式支持能力，用户接入到源站，有可能是网络摄像机等设备，需要支持SRT协议之类的，或很老的摄像只支持RTP那种。二是高性能媒体转码处理平台，具备高性能转码，核心卖点是编码器能力。三是高性能媒体源站平台，具备转封装、加密、源站、访问控制等能力。通过对核心技术能力的拆分，使得我们的技术方案更具备开放性和包容性，更容易被海外的OTT平台接受。

3.3 基础架构技术和场景化技术方案

接下来分三块介绍OTT基础架构中核心能力。

3.3.1 明眸-极速高清转码器

首先介绍下我们最硬核，明眸-极速高清转码器。极速高清转码器以其高清低码的优异性能备受各大OTT流量平台的青睐。极速高清能够帮助这些OTT平台通过极致的码率压缩和画质优化，能够在不降低画质的前提下，压缩30-50%的码率，大大降低了OTT平台的流量成本。另外，一些画质增强、超分等技术也被应用到了欧洲客户的一些老片修复中，提升平台IP内容的质量。

上图是我们在印度给一家本土头部的OTT平台做POC时和竞品的编码器性能对比。

整体看，腾讯云StreamLive在码率节省10%左右的前提下,vmaf、ssim得分也远远领先竞品。

另外，用户主观评价质量也优于竞品。

3.3.2 场景化需求实现方案

接下来我们介绍下OTT场景化技术方案实现，具备多音轨、分布式转码以及广告信息事件标签、DRM的实现。

多音轨往往通过MPEG-TS多PID的形式，多通道传输生成多音轨，首先，需要在TS层面按PID把多音频提取出来，采集对应的语音字段信息，透传到切片模块，这些语言信息都会注入到标签文件中。SCTE35这种特有的二进制协议需要遵循SCTE 35 2019标准去进行解析、构建Pair，下发到切片模块，在对应PTS点的视频帧部分，按协议识别，打上SCTE 35的事件标签。在转封装过程中，实现StreamLive API与其他平台对接，提供Widevine、Fairplay 这些标准的DRM能力。通过上述技术方案，基本实现了常见的OTT的场景化需求，具备与海外厂商竞争的基本能力。

3.3.3 DASH多码率应用案例

以上是我们在MPEG-DASH这种流媒体协议上做的能力验证和在客户场景化实现。同时，我们还针对播放器做了一些兼容性优化， 比如DASH多音轨场景下，音视频的pts gap>20ms就很容易引发播放暂停等问题。

针对首帧我们结合端也做了一些优化，比如2分片起播、低码率优先、减少下载次数，首帧平均耗时大大降低，由原来的600ms+降到了200ms+性能提升。

最后，为了优化播放质量，客户一般都会要求码率自适应，这种方案要求从推流开始到结束所有分辨率都需要转码，转码成本非常高，兼顾到客户成本需求支持多码率转码动态启停。要做到这个能力，最难的就是做到切片对齐，在这个方面，我们做了很多优化工作，并且最终也解决了这个难点问题。总而言之，切片方式存在了天然的弊端，就是播放延迟很大，基本都在15s以上。面对这个问题，我们持续优化，基于CMAF协议，实现了低延迟能力。

先分析切片传输这种方式产生延迟的原因。通常有两类场景。第一种场景，假设8秒一个切片，在第4个切片生成过程中的第3秒，突然有请求，为了追求响应速度会吐历史切量分段3，忽略传输环节延时开销，这种情况下最少延时也得8+3=11s。延迟很高。第二种场景，假设为了降低延迟，不追求响应速度，等最新的分片4生成再吐分片4，忽略所有传输耗时开销，延迟是8s。综合看，这两种方式都不好。

一种方式延迟很高，另一种牺牲Response时间降低延时的同时牺牲了首帧，对用户体验非常差，为了解决这类问题，CMAF协议是一种针对性方案。

CMAF协议在切片层面可以支持切更小粒度的Fragment，是多个小的moof+mdat组合方式，能够切到帧粒度。同时CMAF支持流式传输，将最新I帧开始的所有数据通过一个一个的moof+mdat的形式，通过Chunked流的形式下发下去，确保延迟<=1个GOP，同时，不会影响response时间，首帧效果也比较好。

看下对比效果，同一入流两种切片方式会有15s的时间延时差，这么大的差别另一个原因就是DASH的播放器逻辑上攒3个片起播的逻辑。

关于OTT分享包括现在实现的能力、优化方案在国际站StreamLink、StreamLive、Stream Package产品上完全实现，有兴趣的同学可以看一下，这里也呼吁广大友商到海外卷一卷OTT。

以上为本次的分享内容，谢谢大家！