另外一个需要考量的是流量成本, WebRTC的实时流量是通过UDP传输的(某些情况下可以用TCP), 无法复用在传统CDN的架构之上, 实时的流量价格更是CDN流量的3倍以上, 部署一个超低延迟的直播网络成本非常高...低成本的低延迟的实现
在RTMP直播系统中从推流端到网络传输到播放器都做深度定制确实可以做到比较低的延迟, 但成本也是比较高的, 需要完备的高水平的团队(服务端和客户端), 以及大量的带宽服务器资源....这样的好处还有一个就是在WebRTC播放端, 如果出现丢关键帧的情况可以快速回复....在我们这个场景下WebRTC服务端会拒绝WebRTR的FIR信息, 通过下一个关键帧来解决关键帧丢失的问题.
2, RTMP源站以及边缘站尽可能的不做任何缓存
在一个帧率为25FPS的直播流中, 缓存一帧就会增加...如何落地
目前身边完全没有完全匹配的需求, 这个方案目前并没有落地, 设想中的落地方式是, RTMP部分还是用现有的CDN, 自己部署WebRTC的边缘节点, 根据访问请求向CDN拉流.