直播技术：如何实现1080P延迟低于500ms的实时超清直播传输技术

若该文为原创文章&＃xff0c;未经允许不得转载
原博主博客地址&＃xff1a;https://blog.csdn.net/qq21497936
原博主博客导航&＃xff1a;https://blog.csdn.net/qq21497936/article/details/102478062
本文章博客地址&＃xff1a;https://blog.csdn.net/qq21497936/article/details/106117514
各位读者&＃xff0c;知识无穷而人力有穷&＃xff0c;要么改需求&＃xff0c;要么找专业人士&＃xff0c;要么自己研究

红胖子(红模仿)的博文大全&＃xff1a;开发技术集合&＃xff08;包含Qt实用技术、树莓派、三维、OpenCV、OpenGL、ffmpeg、OSG、单片机、软硬结合等等&＃xff09;持续更新中…&＃xff08;点击传送门&＃xff09;

导语

视频直播是很多技术团队及架构师关注的问题&＃xff0c;在实时性方面&＃xff0c;大部分直播是准实时的&＃xff0c;存在 1-3 秒延迟。本文由袁荣喜向「高可用架构」投稿&＃xff0c;介绍其将直播延迟控制在 500ms 的背后的实现。

前言

最近由于公司业务关系&＃xff0c;需要一个在公网上能实时互动超清视频的架构和技术方案。众所周知&＃xff0c;视频直播用 CDN &＃43; RTMP 就可以满足绝大部分视频直播业务&＃xff0c;我们也接触了和测试了几家 CDN 提供的方案&＃xff0c;单人直播没有问题&＃xff0c;一旦涉及到多人互动延迟非常大&＃xff0c;无法进行正常的互动交谈。对于我们做在线教育的企业来说没有互动的直播是毫无意义的&＃xff0c;所以我们决定自己来构建一个超清晰&＃xff08;1080P&＃xff09;实时视频的传输方案。

先来解释下什么是实时视频&＃xff0c;实时视频就是视频图像从产生到消费完成整个过程人感觉不到延迟&＃xff0c;只要符合这个要求的视频业务都可以称为实时视频。关于视频的实时性归纳为三个等级&＃xff1a;

• 伪实时&＃xff1a;视频消费延迟超过 3 秒&＃xff0c;单向观看实时&＃xff0c;通用架构是 CDN &＃43; RTMP &＃43; HLS&＃xff0c;现在基本上所有的直播都是这类技术。
• 准实时&＃xff1a; 视频消费延迟 1 ~ 3 秒&＃xff0c;能进行双方互动但互动有障碍。有些直播网站通过 TCP/UDP &＃43; FLV 已经实现了这类技术&＃xff0c;YY 直播属于这类技术。
• 真实时&＃xff1a;视频消费延迟 <1秒&＃xff0c;平均 500 毫秒。这类技术是真正的实时技术&＃xff0c;人和人交谈没有明显延迟感。QQ、微信、Skype 和 WebRTC 等都已经实现了这类技术。

从上图可以看出&＃xff0c;如果网络控制在环路延迟在 200ms 丢包在 10% 以下&＃xff0c;可以让视频延迟在 500ms 毫秒以下&＃xff0c;这并不是一个对网络质量要求很苛刻的条件。所以我们在后台的媒体服务部署时&＃xff0c;尽量让客户端到媒体服务器之间的网络满足这个条件&＃xff0c;如果网路环路延迟在 300ms 丢包 15% 时&＃xff0c;依然可以做到小于 1 秒的延迟&＃xff0c;基本能满足双向互动交流。

公网测试

公网测试相对比较简单&＃xff0c;我们将 Server 部署到 UCloud 云上&＃xff0c;发送端用的是上海电信 100M 公司宽带&＃xff0c;接收端用的是河北联通 20M 小区宽带&＃xff0c;环路延迟在 60ms 左右。总体测试下来 1080P 在接收端观看视频流畅自然&＃xff0c;无抖动&＃xff0c;无卡顿&＃xff0c;延迟统计平均在 180ms 左右。

入坑

在整个 1080P 超清视频的传输技术实现过程中&＃xff0c;我们遇到过比较多的坑。大致如下&＃xff1a;

Socket 缓冲区问题

我们前期开发阶段都是使用 socket 默认的缓冲区大小&＃xff0c;由于 1080P 图像帧的数据非常巨大&＃xff08;关键帧超过 80KB&＃xff09;&＃xff0c;我们发现在在内网测试没有设置丢包的网络环境发现接收端有严重的丢包&＃xff0c;经查证是 socket 收发缓冲区太小造成丢包的&＃xff0c;后来我们把 socket 缓冲区设置到 128KB 大小&＃xff0c;问题解决了。

H.264 B 帧延迟问题

前期我们为了节省传输带宽和防丢包开了 B 帧编码&＃xff0c;由于 B 帧是前后双向预测编码的&＃xff0c;会在编码期滞后几个帧间隔时间&＃xff0c;引起了超过 100ms 的编码延时&＃xff0c;后来我们为了实时性干脆把 B 帧编码选项去掉。

Push 方式丢包重传

在设计阶段我们曾经使用发送端主动 push 方式来解决丢包重传问题&＃xff0c;在测试过程发现在丢包频繁发生的情况下至少增加了 20% 的带宽消耗&＃xff0c;而且容易带来延迟和网络拥塞。后来几经论证用现在的 pull 模式来进行丢包重传。

Segment 内存问题

在设计阶段我们对每个视频缓冲区中的帧信息都是动态分配内存对象的&＃xff0c;由于 1080P 在传输过程中每秒会发送 400 - 500 个 UDP 报文&＃xff0c;在 PC 端长时间运行容易出现内存碎片&＃xff0c;在服务器端出现莫名其妙的 clib 假内存泄露和并发问题。我们实现了一个 memory slab 管理频繁申请和释放内存的问题。

音频和视频数据传输问题

在早期的设计之中我们借鉴了 FLV 的方式将音频和视频数据用同一套传输算法传输&＃xff0c;好处就是容易实现&＃xff0c;但在网络波动的情况下容易引起声音卡顿&＃xff0c;也无法根据音频的特性优化传输。后来我们把音频独立出来&＃xff0c;针对音频的特性设计了一套低延迟高质量的音频传输体系&＃xff0c;定点对音频进行传输优化。

后续的工作是重点放在媒体器多点分布、多点并发传输、P2P 分发算法的探索上&＃xff0c;尽量减少延迟和服务带宽成本,让传输变的更高效和更低廉。

Q&A

提问&＃xff1a;在优化到 500ms 方案中&＃xff0c;哪一块是最关键的&＃xff1f;

袁荣喜&＃xff1a;主要是丢包重传 拥塞和播放缓冲这三者之间的协调工作最为关键&＃xff0c;要兼顾延迟控制和视频流畅性。

提问&＃xff1a;多方视频和单方有哪些区别&＃xff0c;用到了 CDN 推流吗&＃xff1f;

袁荣喜&＃xff1a;我们公司是做在线教育的&＃xff0c;很多场景需要老师和学生交谈&＃xff0c;用 CDN 推流方式延迟很大&＃xff0c;我们这个视频主要是解决多方通信之间交谈延迟的问题。我们现在观看放也有用 CDN 推流&＃xff0c;但只是单纯的观看。我们也在研发基于 UDP 的观看端分发协议&＃xff0c;目前这部分工作还没有完成。

参考阅读

• 移动直播技术秒开优化经验&＃xff08;含PPT&＃xff09;

• 揭秘百万人围观的Facebook视频直播

技术原创文章&＃xff0c;欢迎通过公众号菜单「联系我们」进行投稿。投稿方向包括技术架构类文章、新技术及新实践、通过的文章会在高可用架构公众号、微博、今日头条等多个媒体发表。投稿需同意相关文章在高可用架构首发。转载请注明来自高可用架构「ArchNotes」微信公众号

原博主博客地址&＃xff1a;https://blog.csdn.net/qq21497936
原博主博客导航&＃xff1a;https://blog.csdn.net/qq21497936/article/details/102478062
本文章博客地址&＃xff1a;https://blog.csdn.net/qq21497936/article/details/106117514