【腾讯云】 毫秒级超低延时,CDN直播的“升级”之路
- 腾讯云从传统CDN直播到超低延时快直播的“升级”之路。
发布于2022-03-03 10:11:58阅读 5320
16年爆发的千播大战到20年经受的疫情洗礼,五年的蓬勃发展和资本沉淀已让直播这个行业由最初的野蛮生长逐渐过渡到了平稳的成熟期。
但随着疫情的催化,一方面类似电商带货,在线教育这种大规模低延时直播应用场景地不断涌现,使得客户对于直播流畅度、低延时等性能的要求愈加严苛。另一方面,连麦互动、实况赛事等高实时性直播场景的普及,也使得观众对于直播延时、互动、清晰度等方面的要求不断提升。直播行业正在逐步向低延时、强互动、超高清、沉浸式的方向升级。传统CDN直播无法满足这样的低延时需求,而实时音视频产品虽然能满足延时需求,但面对超大并发仍不足以全面支撑这场“直播升级”。整个行业都在寻求突破性的解决方案。
2月22日,腾讯云携手信通院联合发布《超低延时直播白皮书》(文末附下载),首次系统性地阐释了超低延时直播技术,为行业在超低延时方向的发展提供了新的思路及解法。作为首家将直播延时降低到500ms以内的云厂商,下面我们就来看看腾讯云从传统CDN直播到超低延时快直播的“升级”之路。
破局之道:WebRTC超低延时技术
传统的CDN直播,一般主要使用FLV、HLS、RTMP几种直播协议。RTMP和FLV延时一般在3-5秒左右,HLS延时则更大,达到几秒到几十秒。3~5秒延时对于传统的直播形式可以被接受, 但是对于某些特定的场景效果会很差,例如需要两个主播进行互动的主播PK场景。
那么如何打造既具备低延时观看体验,接入高效,价格又可接受的直播技术方案呢?为满足市场需求,这套方案应当满足以下三点:
播放器兼容性较好,能够支持跨平台播放需求;
性价比高,能够支持大规模并发需求;
技术特性能够满足低延时流媒体特性和可扩展性的要求。
腾讯云音视频找到的破局之道是基于Google在2011年开源的WebRTC协议标准,首创将WebRTC技术引入直播领域,对现有的直播系统架构进行了改造优化,打造出全新的超低延时直播技术——快直播。
全新的超低延时直播技术——快直播。
首先,腾讯云工程师们摒弃了传统直播的传输播控模型,借鉴 WebRTC通信模型,将传输和播放控制实时反馈联动,形成反馈闭环,通过感知网络状态来调整播控缓存策略和传输策略,使传输和播控缓存实时对网络进行最优匹配,使用户在特定的网络环境下达到体验最优的效果。
当然WebRTC的初衷是用于低延时P2P通信,在适配直播系统时也会面临挑战。我们通过信令改造、音视频改造、传输改造、增值改造来实现流媒体功能的匹配和升级。
信令改造:
标准WebRTC的信令交互是一个繁复冗长的过程,不利于直播的快速开播。快直播通过采用miniSDP二进制压缩方案,将SDP压缩到1个MTU内,在一个UDP包内完成SDP交互,并结合0-RTT方案,大幅减少信令耗时、提升信令交互成功率,进而降低首帧耗时,提升开播成功率。
音视频改造:
快直播拓展了WebRTC的能力,支持AAC音频,支持H.265编码并支持B帧。
传输改造:
柔性分级传输:快直播通过服务端与客户端的配合,WebRTC扩展帧属性和依赖关系,采样柔性分级丢帧的传输策略来渐进式降低码率,以适应弱网情况。
自适应码率(Simulcast/ABR):快直播通过扩展RTCP作为切流信令,客户端和服务端都具备根据网络来无缝切流的能力,服务端通过渐进式超发来探测网络的承载能力,作为切流决策依据,达到快速、精准、无缝切流的目的。
P2P分发网络:快直播利用WebRTC原生自带的P2P能力,能够将看同一视频流的用户群就近地组织成网络,相互分享传输,每个客户端节点一边通过RTC与CDN协商数据,同时与其他客户端节点约定内容共享,在保持低延时的前提下依然能够取得不错的效果。
增值改造:
- 快直播支持全链路的私有数据透传,使得标准直播到快直播的迁移过渡平滑无缝。同时可根据SDP协商选择开关加密。关闭加密可进一步减少首帧耗时。
在一系列性能改造和优化后,快直播相比传统CDN直播,能够有效降低延时、卡顿,在首屏渲染时长上也具有明显的体验优化。
用户为本:回归用户体验
- 简单、高效的接入体验
腾讯云快直播在最初的产品设计中,就致力于能够让已经使用过标准直播的客户无缝切换到快直播,同时新接入快直播的客户能够有足够简单的接入体验。即使在WebRTC协议和传统RTMP、FLV、HLS协议的请求方式、鉴权方式都不相同的情况下,快直播团队依然坚持让用户将快直播只理解为“云直播的第四种播放协议”,同一个域名既可以使用标准直播,又可以使用快直播。这样标准直播客户升级到快直播,只需将下行播放地址的协议头由http://改为webrtc://,其余配置和能力全部复用,无需任何特殊配置和开通,就可以体验到快直播播放。相比将快直播完全独立域名、独立开通使用的方案,腾讯云快直播的切换成本极低,极大地降低了客户的切换负担和时间成本。
阿里云
1 流媒体服务器会开几个端口分别支持不同播放形式的访问
2. 秒开问题
- 国内直播平台大部分还是使用h264和AAC,所以我们也是首先支持这两种格式,其他音视频格式像HEVC等也是我们后续要支持的格式。
3.RTP报文
- PT字段是载荷类型,sequence number是包序列号,发送端切片的时候,写好序列号,接收端依据这个序列号进行数据的还原。而且在重传发生的时候,还依靠这个序列号进行NACK的反馈。时间戳对流媒体传输非常重要,播放器依赖它进行解码和同步。SSRC用来识别不同的身份,同一个IP和端口被NAT重新分配的时候, SSRC识别出这是一个不同的连接。
- 前面讲过使用TCP传输的时候,网络抖动出现堆积时,需要丢帧,但是一定是丢完整的帧,不能丢片段。那为什么RTP场景下为什么没有这个问题?以H264为例,RTP在封装的时候,如果NAL单元小于MTU,那么我们认为一个RTP包可以完整封装一个NAL单元的,如果出现丢帧,那么我们认为缺少的是一个完整的NAL单元,对后面NAL单元解析是没有问题的,不会出现数据错乱。
4.平滑发送机制
5.播放端上的优化
6.RTC内部打包机制
7.FEC冗余传输
8.UDP传输注意事项
-
9.探活策略
这幅时序图更细致的展开了一下实现的逻辑,播放端和服务器。
完整的支持WebRTC一定是目标, 毕竟直接通过浏览器就可以完成推流和播放对于用户的接入来说实在太方便, 对于CDN来讲控制接入一定是一个必须做的事情。
对于CDN要做的另一个事情就是优化传输,其实无论对于文件加速还是流媒体加速,传输永远都是最重要的,CDN这个分发网络本身就是为了优化传输而存在。
UDP传输比原来的TCP传输对资源消耗要多,而且重传、封包、FEC冗余计算等都会额外增加计算量,在多进程模式下可能还会遇到内存资源的过多消耗。
从实践来看,UDP传输比原来的TCP传输对资源消耗要多,而且重传、封包、FEC冗余计算等都会额外增加计算量,在多进程模式下可能还会遇到内存资源的过多消耗。