为何公众号推送会延迟发送_基于WebRTC构建超低延迟(500ms)的直播系统

上周写了一篇文章基于RTMP和WebRTC 构建低延迟的直播系统(https://zhuanlan.zhihu.com/p/47302561), 只所以要基于RTMP, 还是考虑尽可能复用现有的技术和基础设施. 实际上国外已经有基于WebRTC的CDN系统, 比如 http://phenixrts.com/, https://www.millicast.com/. 比这更早的可以追溯到beam, 一个实时的游戏直播平台, 在2016年被微软收购后改名mixer(https://mixer.com). 目前国内低延迟直播的做法是在rtmp的基础调优, 比如使用可靠UDP方案替换RTMP的传输层, 目前使比较多的方案有KCP和QUIC. 但魔改RTMP的方案始终没有特别好的适配浏览器的方法. 相比有超过40亿设备支持的WebRTC来说, WebRTC的方案无疑更有想象空间.

但WebRTC天生为Peer-To-Peer而生, 并没有提供对大规模分发的支持. 为提升WebRTC分发能力, 于是有了SFU的方案, 但常见的SFU方案, 也只能让WebRTC具备几十路到几百路的分发能力. 试想在用WebRTC直播, 瞬间进入几百个观看端, 这几百观看端都在请求关键帧, 发送端的压力会非常大造成整个直播不可观看. 在这几百人中如果有几个人网络特别差, 也会造成整个直播质量的下降. 如果我们想提升WebRTC的分发能力, 我们应该切端观看端向发送端的反馈机制. 在牺牲一定视频质量的情况做到大规模的分发.

全链路的WebRTC直播跟我上篇文章写的RTMP-WebRTC的方案类似, 有其中几个点需要注意一下:

0, 在源站接入点, 使用WebRTC接入, 这样我们可以省去RTMP到WebRTC协议转封装时间, 和音频转码的资源消耗.

1, 在边缘观看接入点, 在接受到用户观看请求之后, 检查本地有没有相应的视频流, 如果没有相应的流会向源站进行请求, 源站会以RTP包的形式向边缘节点推送一路流, 源站然后把RTP媒体包封装成WebRTC协议的流推送给观看端.

2, 源站服务器会定期的向发送端请求关键帧, 把GOP控制在2秒以内.

3, 边缘站会缓存一个GOP, 在有新的观看请求时可以快速的发送给观看端, 达到秒播的效果. 这部分的原理跟我们在RTMP直播中缓存一个GOP原理一样.

最简单的一个架构如下:

Talk is cheap, Show me your code:

我实现了一个版本, 并部署在了https://rtcast.dot.cc, 进入后会开始发布一路流, 发布成功之后会有观看链接, 在另一个页面中打开观看链接就可以观看. 欢迎交流.

我的博客即将同步至腾讯云+社区，邀请大家一同入驻：

腾讯云自媒体分享计划 - 云+社区 - 腾讯云​cloud.tencent.com