最近复习了下直播低延迟技术方案,顺便把自己方案完善了一下作为记录.低延时效果截图如下:

ps:左侧为相机采集画面.右侧为拉流端公网拉取画面,延迟为172ms(由于第三相机拍摄照片故延迟计算为包含采集延时)

ps:推拉流两端视频截图,由于是桌面截图,故延迟不包含设备采集延时,延迟为132ms,后续会放出测试程序,供大家进行实测对比

直播低延迟方案是我在17年 18年在上一家公司医疗直播进行的应用,医疗直播里面有个业务场景叫手术示教和手术指导,手术示教项目解决了医生手术实时教学的问题,避免多数的观摩医生拥挤在狭小手术间观看学习,也解决了交叉感染的卫生问题.手术指导则是手术过程中观摩室内医生可以实时连线手术主刀医生进行手术过程中对手术方法进行指导和讨论.(当然类似的场景应用非常狭窄,仅适用一些特殊情况手术,例如跨省/跨市医院/学术交流峰会),5g远程手术更是手术指导方案的升级版,有兴趣点击5g远程手术,在低延迟直播技术上如果加上低延迟回控技术+vr场景模拟真实环境,对医疗行业的信息共享概念将有非常大的意义

目前最流行的直播技术方案是基于ffmpeg+rtmp,本轮重点讨论的也是此项方案.直播框架总体分为三大部分:主播推流端/rtmp服务器/播放拉流端,其结构如下导图所示:

需要做到200ms内低延迟,甚至100ms内延时,前提是需要将复杂应用模型转换为极简技术模型,只有解决了极简模型的低延时处理,复杂模型可以根据多增加的每一个因素去逐步优化,最后评估整体方案的平均延时,本文约定测试前提为下:

1.数据流模型信息:单路720p@25 1200kbps视频流+44100双声道16比特率AAC音频流

2.延迟时间路径:从主播推送端渲染显示层→流媒体服务器→用户拉流端渲染层之间延时计算

即ffmpeg直播rtmp方案在上述约定下实现200ms内直播通讯.

从直播架构上图可以分析到,直播的延迟主要有存在以下几处地方:

1.数据采集延时,要确保低延时,摄像头输入仅能选取非网络及非编码类本地uvc驱动摄像头,及普通usb或者笔记本自带摄像头.摄像头数据输出需要支持720p@25 yuv420p数据输出,这样可以使数据进入到编码前处理线程时候,0性能损耗直接输出720p@25yuv420p至编码层和渲染层.即数据采集延时理论上可以达到0延时,当然我们忽略了设备硬件的输出延迟.简单得出数据采集线程处理时间