腾讯云快直播低延时播放质量的优化实践

2023年4月12日

直播已经潜移默化成为许多人日常生活密不可分的一部分。无论是紧张刺激的比赛直播,还是垂涎欲滴的美食直播,亦或者自卖自夸的购物直播,大家都不希望在观看时出现长时间的加载和卡顿,对一些需要观众及时反馈的直播场景,过高的延时也是用户不希望出现的。如何保证直播的快速、清晰、低延时成为各大厂商必须直面的难题。我们很荣幸地邀请到了腾讯云音视频的费伟老师来到 LiveVideoStackCon 2022 北京站介绍他们的解决办法。

文 / 费伟

编辑 / LiveVideoStack

大家下午好,很高兴能参加 LiveVideoStackCon 2022 北京站的活动。第一次来到 LiveVideoStackCon 现场,让我深切感受到 LiveVideoStack 的人气,还有大家对音视频技术的热情。我是来自腾讯云音视频的费伟,目前主要负责腾讯云快直播以及云游戏 WebRTC SDK 相关的研发工作。今天我给大家分享的主题是《快直播低延时播放质量的优化实践》。

图片

分享主要从以下三个方面给大家介绍。首先从行业和技术的背景出发介绍快直播。然后,针对快直播在落地过程中一些问题和挑战,从接入的角度详细介绍腾讯云在低延时播放质量上所做的一些优化工作。最后将介绍如何通过快直播 SDK 接入,实现从传统标准直播平滑迁移到快直播。

1. 快直播介绍

什么是快直播呢?

1.1 行业背景

图片

先来看下目前的行业背景。低延时一直是直播行业重要的发展方向。根据今年 Bitmovin 视频报告最新的调研结果,低延时是音视频领域最为关注的技术创新和挑战之一。虽然今年低延时从第一降到了第二,成本控制成为当下最为关注焦点,但是低延时还是最受行业长期关注的发展方向之一。近些年来,特别是疫情以后,低延时直播需求得到了迅猛增长。我们看到的行业需求主要来自三个方面:1. 传统标准直播不断降低延时的内在需求,像电商直播、赛事直播、秀场直播等,都需要不断降低延时,提升直播的互动性和沉浸体验,从而带动平台的 GMV 增长;2. RTC 场景升级降本的需求,像在线教育和会议行业,可以通过大房间低延时旁路直播,来提升并发数和降低成本;3. 云渲染、虚拟直播、云游戏直播等创新业务场景的需求,也需要通过低延时直播来更快更好地向观众呈现画面。

1.2 技术背景

图片

下面是低延时直播的技术背景。直播领域的各种传输协议本身也在不断向低延时方向发展,像低延时 HLS、CMAF,还有被国内直播行业用到极致的 RTMP/FLV。但是 WebRTC 凭借其在超低延时、媒体特性、可扩展能力和生态系统等全方位的优势,成为目前低延时直播领域主流的传输技术。WebRTC 成熟完善的生态系统包括:90% 以上的浏览器和微信生态天然支持 WebRTC,使得接入成本非常低;另外还有开源成熟的客户端 SDK 可以定制;我认为更为重要的是,WebRTC 是一整套与媒体特性紧密结合的低延时传输技术平台,具有非常灵活的扩能能力,能为 WebRTC 实时音视频技术应用在直播领域和将来融合更多低延时场景提供很好的技术框架和技术基础。

1.3 技术框架

图片

下面看一下腾讯云快直播的技术框架。快直播是从腾讯云标准直播的基础上进化衍生出来的,最基本的方式就是将标准直播的边缘节点进行 WebRTC 升级改造,从而具有高并发的低延时 WebRTC 分发能力。这种方式的好处就是能完全兼容标准直播下各种推流和回源协议,同时也兼容现有各种云媒体处理服务能力,像音视频转码、画质增强、字幕水印等。只需要在收流端通过快直播 SDK 接入,就可以实现从标准直播平滑迁移到快直播上来。还有进阶方式,就是需要端到端 + 云媒体处理的全链路低延时优化:下行采用扩展 WebRTC 传输,实现更好的低延时传输能力和播放质量;上行采用 WebRTC、QUIC 或 SRT 进行推流,使推流的帧率更加平稳;支持多 Slice 编码推流和拉流,可以进一步降低延时;同时云媒体处理也需要有低延时处理能力,腾讯云 MPS 提供了 H.264、H.265,以及 AV1 极速高清转码服务,可以在低延时下降低码率和增强画质。总之,快直播可以根据客户需求提供不同层次的低延时直播服务。

图片

腾讯云快直播提供了一步接入的升级方式,只需要升级播放端,将 HTTP 播放链接改为相应的 WebRTC 链接,上行和配置都不需要改变,就可以实现平滑升级,接入到腾讯云快直播。对于 Native 客户端可以通过视立方全功能 SDK 来接入,也可以通过快直播传输层 SDK 接入到现有的播放器当中。浏览器 WEB 端我们也提供了 H5 SDK 实现快速接入。

图片

这是快直播和标准直播在 H5 页面上的延时对比演示。在同一个页面上一路 WebRTC 推流,分别通过快直播 WebRTC,标准直播 FLV 和 HLS 拉流。可以直观地看到快直播 WebRTC 拉流端到端延时只有 500ms 左右,远低于标准直播 FLV 3 秒,HLS 10 秒左右的延时。这说明通过 WebRTC 确实能够满足低延时的要求,但是现实落地过程中仍有各种困难和挑战。

图片

将 WebRTC 应用在直播场景的困难和挑战,主要有:第一,客户端 WebRTC SDK 接口复杂,体积庞大、接入门槛比较高;第二,WebRTC 媒体能力无法满足直播场景的要求;视频不支持 H265、B 帧,音频不支持 AAC,需要转码对接,会有额外的转码成本和延时;第三,也是最大挑战,WebRTC 虽然降低了延时,但播放质量也变差。像开播成功率、首帧耗时、卡顿等指标相比于标准直播 FLV 明显变差。腾讯云快直播的目标就是降低 WebRTC 接入门槛,升级扩展 WebRTC 能力,提升 WebRTC 低延时传输性能和播放质量,推动客户以及整个行业加速向低延时方向发展。

2. 低延时播放质量优化

下面介绍腾讯云快直播在低延时播放质量优化上的一些实践工作。

图片

在详细讲述之前,先总体介绍下腾讯云快直播低延时播放的定制优化解决方案。快直播低延时播放优化是以性能指标为导向,因为性能指标至关重要,关系到能否对客户业务产生正向收益,也关系到快直播能否真正大规模落地。快直播从开播成功率、首帧耗时、卡顿等 QoS 优化和播放策略优化两个维度来优化核心 QoE 业务指标,播放渗透率和播放时长,分别对应客户最为关心的业务转化率和 GMV 指标。

QoS 优化是对 WebRTC 整个拉流和传输过程进行针对性优化,包括信令优化、调度优化、建联优化和传输优化等。播放策略侧优化则从播放的角度提升 WebRTC 在直播场景下的播放体验,包括信令预加载、多码率播放、同步平滑播放等。我们的优化目标就是相比于标准直播 FLV,快直播的性能和业务指标实现正向。

2.1 QoS 优化

图片

QoS 优化的第一个挑战是 WebRTC 的拉流需要信令协商和建联的过程,相比于标准直播 HTTP 请求过程冗长。首先要建立 TCP 信令通道进行 HTTP 信令交互,之后 ICE 建联,然后进行 DTLS 加密握手,最后才进行媒体数据传输。这样冗长的过程,直接导致首帧耗时和开播成功率负向。快直播从三方面来入手优化解决。第一,将拉流过程简化到一个极致的地步,采用与 QUIC 类似的首次请求 1RTT 认证,后续请求 0RTT 传输的策略。Server 端第一次收到 Offer 后会根据客户端 IP、业务信息、时间信息生成认证信息,将认证信息放于 Answer 的 ufrag 返回客户端并缓存在 Server 端,后续 Offer 请求带上认证信息,Server 端校验成功后,直接下发媒体数据,实现 0RTT 吐流,首帧至少减少 5 个 RTT。

图片

QoS 优化的第二个挑战是如何实现高并发下的平稳接入问题。DNS 异常和局部负载过高都会影响到首帧耗时和接入成功率。精准调度和负载均衡一直是大容量直播系统的重要课题。标准直播一般采用 HTTP 302 重定向来实现调度,效率比较低,而且多次 HTTP 交互会严重影响到首帧耗时。而快直播利用了 WebRTC 信令服务器和媒体服务器可以分离的特点,通过信令 answer 回复本地不同的服务器地址或其他区域的服务器地址,来修正 DNS 调度偏差和实现负载均衡调度,而且无需额外耗时。目前快直播可以实现百万级并发下的平稳接入。

图片

QoS 优化的第三个挑战是 UDP 连通性问题会影响建联成功率。虽然该问题只占线上很小一部分,但仍然会拉低整体成功率指标。我们在客户落地过程中发现 UDP 不通的原因主要有两个:某些网络的安全机制封禁了某些 UDP 端口或者整个 UDP 协议;或者跨域或跨运营商出现路由线路某些 UDP 端口不通的情况。一般采用超时回退到 FLV 的机制,但该机制播放体验不友好。

我们快直播利用 WebRTC 多 Candidate 建联的能力,在 Answer Candidate 里添加不同端口的 UDP 地址和 TCP 地址,进行多通道建联。一般情况下会优先在 UDP 通道进行数据传输,TCP 只在 UDP 不通时负责兜底,这个过程是无缝的,用户不会有感知,这样可以有效提升建联成功率和播放体验。同时,快直播也具有了 UDP 和 TCP 不同协议多通道灵活发送的能力。

图片

QoS 优化第四个挑战是,如何传输优化,减少卡顿。特别是起播卡顿,据线上统计起播卡顿占比一半以上。原因是开播后,后台会从最近 I 帧开始发送,短时间内下发大量回退数据,容易导致卡顿。腾讯云快直播采用端云协同加速来灵活适配不同的网络。具体有:开播请求带上最近的网络和播放信息,这样后台可以匹配最优的起始下发策略,有效减少起播卡顿。还有将传输内容按重要性进行分级。音频处于最高优先级,采用重传加 FEC 的双重保护;视频数据则按照解码依赖关系,采用关键帧优先,分级重传的策略。最后是根据 RTT、重传率和带宽估计,自适应调整重传窗口和 FEC 冗余策略,有效避免重传风暴。除此之外,在前面双通道建联的基础上,可以根据连接和接收的情况,自适应选择 UDP 还是 TCP 作为数据传输通道。

2.2 播放策略优化

图片

下面从播放策略的角度介绍如何提升播放质量。我们知道目前直播场景主要形式是以抖音、快手、视频号为代表的信息流推荐结合划屏切换的模式,这种模式对首帧秒开和成功率有着极为苛刻的要求,以保证用户沉浸式体验,所以预加载模式是普遍采用的技术手段。通常使用多实例播放器,当前台播放器播放当前内容时,后台播放器在一定时机下按推荐顺序提前拉流。但是在标准直播下,这种提前拉流的方式成本非常高,还可能造成带宽竞争和一定的流量浪费。腾讯云快直播利用 WebRTC 信令的特性,提出了信令预计加载的概念,将 WebRTC 拉流分为信令预加载阶段和播放器阶段。信令预加载阶段提前完成信令交互,数据回源、获取音视频头信息,提前初始化解播放器等。播放阶段直接下发数据解码播放。这种方式无需实际拉流,成本低,也不存在带宽竞争和浪费。通过信令预加载进一步降低首帧耗时,有效提升了开播渗透率,实现了开播渗透率的正向。

图片

播放时长上,由于标准 WebRTC 本身是针对 RTC 场景的,播放策略是低延时优先,容易出现追帧的情况。根据 RTCP 反馈的 NTP 时间戳进行弱同步,容易不同步。特别是开播回退数据比较多时会导致快速追帧和不同步。播放体验不符合直播场景的观看习惯,导致播放时长负向。腾讯云快直播将播放策略改为平滑优先,根据 RTP 扩展携带的 PTS 进行强同步。同时改进音视频 Jitter Buffer 实现,可以根据网络抖动,自适应大范围的平滑伸缩,能抗 0~50% 的丢包率。这样做的目的是让大部分网络好的观众能享受低延时播放,少部分网络不好的观众适当增加延时来保证流畅播放,从而实现播放时长整体正向 。

图片

这张图是多码率播放策略。用户实际网络条件千差万别,当用户网络带宽低于视频码率的时候,任何传输调优的效果都是非常有限的,特别是在移动数据网络下。多码率部播放可以有效提升不同终端在不同带宽场景下的播放质量。

标准直播 FLV 的多码率播放,一般是在端侧根据网速或缓存状态进行码率切换。切换的本质是多次拉流,本地进行 GOP 拼接,切换过程中不能切换编码格式。快直播多码率则利用信令的优势实现更为灵活和平滑的切换,一次拉流过程中可以任意切换,支持端侧和服务器侧的切换控制。切换后在服务器侧 GOP 对齐后再进行下发,可以实现更平滑的切换效果。用户可以通过不同分辨率转码,也可以通过不同编码格式转码实现多码率。最简单应用就是当检测到本地网络不好时,先以低码率起播,再根据网络变化进行码率调整,这样能有效提升秒开率和成功率。通过上述方法,快直播多码率切换得以更加灵活,效果也更加平滑,有效提升播放性能指标和体验。

3. 快直播 SDK 接入

下面我将介绍如何通过快直播 SDK 接入解决 WebRTC 媒体能力不足和接入门槛高的问题,从而实现向快直播的快速迁移。

图片

腾讯云快直播是以 WebRTC 技术为基础,快直播 SDK 也是从原生 WebRTC SDK 发展而来的。我们先基于原生 WebRTC SDK 实现标准 WebRTC 拉流,然后基于标准 WebRTC 升级扩展,逐步建立起自己的快直播扩展 WebRTC 协议栈。

首先对 WebRTC 的媒体能力进行扩展来支持直播场景下主流的媒体格式。像视频编码格式支持了 H.265、B 帧,音频支持了 AAC 的 LC、HE 和 HEv2 3 个 profile,还有 48K 和 44.1k 采样率以及 LATM、ADTS 封装。扩展后实现了 WebRTC 与直播媒体格式的无缝对接,减少了转码成本和转码耗时。我们还扩展了一些其他的媒体能力,例如加密协商开关,协商开关可以根据直播内容是否开启加密,从而减少前后端加解密开销和 DTLS 握手延时;音频支持了带外灵活 FEC,使 AAC 音频得到 NACK 加 FEC 双重保护;支持私有业务数据通过 SEI、MetaData 和一些自定义 NAL 类型来透传,实现互动信息的同步;支持各种自定义 RTP 扩展,例如 DTS、PTS 扩展;利用 WebRTC 天然的 P2P 能力实现了数据分享,为客户降低带宽成本。所有这些 WebRTC 的扩展媒体能力都能基于信令协商,实现完美兼容标准 WebRTC 和扩展 WebRTC。

图片

快直播提供了两种形式的 SDK 来帮助客户降低接入门槛 —— 全功能 SDK 和传输层 SDK。

全功能 SDK 包含传输、解码和渲染,并封装成 View 的形式,客户可以实现 0 开发,直接嵌入 APP 当中,以满足中长尾客户的需求。同时针对性地进行了解码渲染性能优化,可以实现 < 100ms 的极致低延时性能。全功能 SDK 也同时也输出给我们腾讯云云游戏业务作为 WebRTC 内核。全功能 SDK 缺点也很明显,包体积较大,打包增量有 5M 多,对原有播放和业务逻辑侵入较大。

传输层 SDK 就是把传输层单独抽离出来,封装成简单易用的接口,支持全平台接入,高性能,可扩展,能满足大客户定制的需求。与此同时提供标准 FFmpeg Demuxer 实现,可以非常便捷地接入到客户现有的各种播放器当中,打包增量小于 500K,完全复用原有播放器和业务逻辑。

图片

下面重点介绍快直播传输层 SDK。传输层 SDK 可以通过腾讯云提供的 FFmpeg Demuxer 非常方便地接入到客户自有播放器,还有各种开源播放器,像 ijkplayer、VLC、ffplay 等等。但是在接入过程中,需要解决如何实现高效低延时播控策略。我们提出了两种实现方式,播放器播控模式和 SDK 内部播控模式。

播放器播控模式需要客户根据业务延时要求设置播放器 Buffer 大小,然后根 Buffer 水位调节播放速度,以及音频数据变速不变调处理等功能。SDK 内部播控客户只需要设置 SDK Jitter Buffer 的大小和和音频解码解码器接口,SDK 会根据 Jitter Buffer 状态和 Jitter Delay 自动调整播放策略,并根据播放状态进行音频信号处理。

内部播控的优点在于可以不依赖客户播放器,不同客户不同平台不同播放器可以实现统一的低延时播放质量。还可以自定义 Jitter Buffer 策略,实现自适应的延时控制。

目前快直播传输层 SDK 已经被行业主要客户广泛采用,有效助力客户低延时直播业务的快速落地。

图片

上图是快直播传输层 SDK 与 H5 标准 WebRTC 抗丢包率性能的对比。H5 标准 WebRTC 采用最新 Chrome 浏览器,快直播传输层 SDK 采用 ffplay 命令行播放。由于启用了 SDK 内部播控,不同平台不同播放器可以有统一的播放质量和抗弱网性能。测试在 MAC 上进行,采用系统自带工具来设置系统丢包率,丢包率从 10% 逐步提高到 20%、30%、40%、50%。在 20% 时,标准 WebRTC 出现轻微卡顿,而 30% 时标准 WebRTC 已经出现严重卡顿,50% 时标准 WebRTC 画面则几乎卡死。同样条件下,基于快直播传输层 SDK 的 ffplay 一直能流畅播放,这说明传输层 SDK 有远比标准 WebRTC 优秀的的抗丢包能力来保持高丢包率场景下的流畅播放。

图片

腾讯云快直播通过 QoS 优化和播放策略优化实现了性能指标的正向,后续会继续优化迭代,以保持技术领先优势。下一步的重点是成本优化和做大规模。成本优化上,利用信令协商接入灵活调度的特点,降低资源成本。紧密结合腾讯云领先的媒体处理能力,增强画质,降低码率。利用 WebRTC 天然的 P2P 能力,实现低延时分享,降低带宽成本。技术优势叠加成本优势,就可以推动存量客户大规模迁移到快直播,同时吸引更多的新客户。

疫情后,尽管 RTC 热度有所降低,但从长远的技术和时间维度来看,低延时是大势所趋。新场景新需求还有各种新玩法一定会不断涌现,快直播会为云渲染、虚拟直播等全真互联网的到来做好的探索和技术储备。

图片

腾讯云快直播一直以开放的心态与行业伙伴一起共建行业生态与标准,一起做大低延时直播的行业规模。我们联合信通院发布了业内首份《超低延时直播白皮书》。对快直播技术感兴趣的同学可下载学习,里面会有更多的技术介绍。另外腾讯云正在和行业伙伴一起共建基于 WebRTC 超低延时直播协议的行业标准,感兴趣的伙伴可以一起参与标准建设,共同推广和完善 WebRTC 超低延时直播协议。

图片

对快直播 SDK 感兴趣的同学也可以下载体验。

以上就是本次分享的全部内容,谢谢大家!


还可输入800
全部评论
作者介绍

LiveVideoStack

音视频技术社区

文章

粉丝

视频

阅读排行
  • 2周
  • 4周
  • 16周