rtmp推流 webrtc_基于RTMP和WebRTC开发大规模低延迟(1000毫秒内)直播系统

问题

随着移动设备大规模的普及以及流量的资费越来越便宜, 超低延迟的场景越来越多. 从去年到今年火过的场景就有在线娃娃机, 直播答题, 在线K歌等. 但要做到音视频的超低延迟确是很不容易, 编码延迟, 网络丢包, 网络抖动, 多节点relay,视频分段传输,播放端缓存等等都会带来延迟.

WebRTC兴起提供的方案以及遇到的问题

WebRTC技术的兴起为低延迟音视频传输带来了解决方案, 但WebRTC是为端到端设计的, 适合的场景是小规模内的实时互动, 例如视频会议, 连麦场景. 即使加入了SFU Media server作为转发服务器, 也很难做到大规模的分发. 另外一个需要考量的是流量成本, WebRTC的实时流量是通过UDP传输的(某些情况下可以用TCP), 无法复用在传统CDN的架构之上, 实时的流量价格更是CDN流量的3倍以上, 部署一个超低延迟的直播网络成本非常高.

RTMP系统推流播放延迟分析

一个经过优化的RTMP-CDN网络端到端的延迟大概在2-3秒, 延迟大一些要在5秒甚至10秒以上. 从推流到播放, 会引入延迟的环节有编码延迟, 网络丢包和网络抖动, 视频的分段传输, 多媒体节点的relay, 播放器的缓存等等. 实际上除了网络丢包和网络抖动不太可控之外, 其他的各各环节都有一定的优化方案, 比如使用x264的-preset ultrafast和zerolatency, 可以降低编码的延迟,

分段传输部分可以把GOP减少到1秒之内, 在播放器端可以适当减小buffer, 并设置一定的追帧策略, 防止过大的buffer引起的时延.

低成本的低延迟的实现

在RTMP直播系统中从推流端到网络传输到播放器都做深度定制确实可以做到比较低的延迟, 但成本也是比较高的, 需要完备的高水平的团队(服务端和客户端), 以及大量的带宽服务器资源. 如果想做到超低延迟(1000毫秒以内)更是难上加难, 而且这么低的延迟也会带来一些负面的效果, 网络出现少许抖动的时候就会出现卡顿等等. 有没有更低成本的实现方案呢? 以及如何复用现有的CDN的基础设施来做到低延