作者:李晨光、匡建鑫、陈鉴平
卷首语:
据中国互联网络信息中心发布的《中国互联网络发展状况统计报告》显示,截止到 2022 年 6 月我国网络直播用户规模达到了 7.16 亿,占网民整体的 68.1% 。最主要原因是 2020 年度疫情期间导致居家办公和休闲娱乐的人数呈现激增,新媒体互动直播成为了广大网民最重要的休闲娱乐方式之一。
随着直播产业链的不断扩展完备升级,相关产业链各个环节分工逐渐明确且各环节参与人数逐步增多;为了满足不同的就业需求,引发相关就业人数提升,通过直播形式赋能传统产业升级转型,并与高新技术融合创新,优化传统行业商业模式,如直播带货、新媒体广告传媒转型等。
丰富的传统文化、新闻、竞技体育、法律、知识共享等内容,通过移动端互动直播的形式得以更加高效的展现传播,既让优质的直播内容可以实现爆发式传播扩散,又可以让用户有更多的机会感受,学习甚至主动参与直播互动,实现内容供给侧和需求传播的多方共赢。
可以说,超低延时直播技术正在走上一条全新的发展之路。InfoQ将联合火山引擎视频直播团队推出《超低延时直播技术演进之路》系列,带您探索超低延时直播技术的演进历程,揭示背后的挑战和突破,以及对未来直播行业的影响。
今天这篇文章我们来讲一下超低延时直播技术的前世今生~
网络基础设施升级、音视频传输技术迭代、WebRTC 开源等因素,驱动音视频服务时延逐渐降低, 使超低延时直播技术成为炙手可热的研究方向。实时音视频业务在消费互联网领域蓬勃发展, 并逐渐向产业互联网领域加速渗透。经历了行业第一轮的红利爆发期,我国实时音视频行业的场景效能逐渐深化,步入到理性增长阶段。
延时的指标选择很大程度上取决于用户与内容制作方的交互耦合程度,场景丰富多样。
在这些极端场景下,延时在用户侧希望越小越好,接近于实时通信的低延迟模式可以最大化地激发用户的参与感,无缝地与内容生产方产生互动效应,调动用户所见即所得的积极性。比如在主播秀场的PK、送礼、工会冲榜、打赏的活动关键环节,竞争双方的储值大户都希望实时地观察到自身主播在礼物刷榜后的反应,为后台运营决策团队或者后续活动策略提供第一时间的信息反馈。
下图体现了从技术/产品/运营的三方角度来综合思考低延时直播技术的作用;从外部-内部综合因素考虑技术的变迁对整个生态正向循环的影响。
RTMP 协议是最传统的直播协议,主播端采用 RTMP 协议推送 H.264/5 和 AAC 编码的视音频数据到云厂商 CDN 服务器进行转封装分发,端到端延迟一般控制在 3 到 7 秒。问题是 RTMP 的可扩展性存在缺陷,同时对于延迟的进一步下探存在一定的技术困难。RTMP 协议情况下:为了满足延时降低必然压缩播放器的下载缓冲区,这样会引发显著的卡顿问题,使得播放的观感产生不舒适的感受(延时下探至 2 秒以下)。
超低延时直播是近年来新兴起的一类应用。如电商直播、赛事直播等场景,兼具高并发与低延时的特性,传统直播 3-20s 的时延难以满足其需求,但对实时互动的要求又不及视频会议等典型的实时音视频应用,无需将时延降低至 400ms 以下。为此,超低延时直播融合了传统直播与实时音视频的技术架构,通过取长补短的方式实现了介于二者之间的端到端时延。尽管针对超低延时直播厂商尚无一套标准的技术路径,但大体可以归纳为拉流协议、网络架构和推流协议三个方面的改造, 在实际应用过程中,厂商会平衡成本及性能指标等因素,在不同的协议和网络架构之间进行选择。
传输层协议的****差异 (基于 UDP 协议的可靠性优化,为弱网对抗策略提供依据)
UDP 协议的优化:
基于业务场景发展的直播技术演进过程(延迟主线)
RTM 协议本身的演进历程
a=extmap:18 "http://www.webrtc.org/experiments/rtp-hdrext/decoding-timestamp"
a=extmap:19 "uri:webrtc:rtc:rtp-hdrext:video:CompositionTime"
a=extmap:21 "uri:webrtc:rtc:rtp-hdrext:video:frame-seq-range"
a=extmap:22 "uri:webrtc:rtc:rtp-hdrext:video:frame-type"
a=extmap:23 "uri:webrtc:rtc:rtp-hdrext:video:reference-frame-timestamp"
a=extmap:27 "uri:webrtc:rtc:rtp-hdrext:audio:aac-config"
a=extmap:18 "http://www.webrtc.org/experiments/rtp-hdrext/decoding-timestamp"
a=extmap:19 "uri:webrtc:rtc:rtp-hdrext:video:CompositionTime"
a=extmap:21 uri:webrtc:rtc:rtp-hdrext:video:frame-seq-range
a=extmap:22 uri:webrtc:rtc:rtp-hdrext:video:frame-type
a=extmap:23 uri:webrtc:rtc:rtp-hdrext:video:reference-frame-timestamp
a=extmap:27 uri:webrtc:rtc:rtp-hdrext:audio:aac-config
miniSDP 信令标准实现部分(抖音)
CDN 信令异步回源
RTP 携带扩展头组成部分
RTM 低延时直播基于 WebRTC 技术衍生,基于 WebRTC 标准构建点到点传输一般有如下几个步骤:
https://github.com/zhzane/mini_sdp
播放协议 | RTM-HTTP信令 | RTM-MiniSDP信令 | FLV |
---|---|---|---|
首帧时间(预览) | 600ms | 510ms | 350ms |
拉流成功率(预览) | 97.50% | 98.00% | 98.70% |
实验组 | 视频渲染百秒卡顿(直播间场景) |
---|---|
RTM默认JitterBuffer策略 | 8.3s |
RTM改进的JitterBuffer非丢帧策略 | 3.6s |
传统的 RTC 场景优先保时延,全链路会触发各种丢帧(包括但不限于解码模块,网络模块),FLV 直播场景会优先保证观播体验(不丢帧,良好的音画同步效果)。RTM 要想减少卡顿,取得 qoe 的收益,播控策略需进行定制化, 定制逻辑修改点:
确保不会由于软解的解码耗时或者硬解的 dequeuinputbuffer 等其它 api 操作阻塞 jitterbuffer ,内核层有一层强制的音画同步逻辑,可以确保音视频的播放体验;
同时上层在监控网络模块和解码模块的缓存长度,有相应的兜底逻辑:
以上为超低延时直播技术演进之路《进化篇》的所有内容,第二篇《实战篇》我们将聚焦于超低延时直播技术如何大规模落地实践,请大家持续关注~