随着移动设备大规模的普及以及流量的资费越来越便宜, 超低延迟的场景越来越多. 从去年到今年火过的场景就有在线娃娃机, 直播答题, 在线K歌等. 但要做到音视频的超低延迟确是很不容易, 编码延迟, 网络丢包, 网络抖动, 多节点relay,视频分段传输,播放端缓存等等都会带来延迟.
WebRTC兴起提供的方案以及遇到的问题
WebRTC技术的兴起为低延迟音视频传输带来了解决方案, 但WebRTC是为端到端设计的, 适合的场景是小规模内的实时互动, 例如视频会议, 连麦场景. 即使加入了SFU Media server作为转发服务器, 也很难做到大规模的分发. 另外一个需要考量的是流量成本, WebRTC的实时流量是通过UDP传输的(某些情况下可以用TCP), 无法复用在传统CDN的架构之上, 实时的流量价格更是CDN流量的3倍以上, 部署一个超低延迟的直播网络成本非常高.
RTMP系统推流播放延迟分析
WebRTC作为浏览器中的一个组件，在设计的时候考虑了大量了安全问题，比如要求getUserMedia在加密网页中才能打开摄像头， 使用MDNS来防止IP地址的泄露， 使用DTLS来加密datachannel数据，使用DTLS-SRTP来加密音视频数据等等，在带来更高的安全性的同时也带来更多的复杂性，更多的资源占用。尤其是对于开发者来说，DTLS-SRTP的引入带来很多问题，工程的复杂性，服务器资源的占用，以及音视频建立连接的延迟等，我们使用SDES来减少DTLS带来的影响，在保证兼容WebRTC协议的同时减少系统的复杂度，降低弱网下的首帧延迟。
网页版WebRTC多人聊天Demo
本文基于Codelab中step7，在其基础上作简单修改，使其支持多人视频通讯，本文暂时只支持星状结构三人聊天，多人聊天可以在基础上扩展，原理相同。
一.源码分析
该工程包括三个文件：server.js，main.js，index.html。
1.server.js
WebRTC端对端连接
RTCPeerConnection
一个核心类，是上层的统一接口。
在底层有很多复杂逻辑，媒体协商 、流轨道处理、数据接收发送、数据统计等等。
今天得闲，又翻了下kurento的代码，没忍住。学有所得，分享在这里。
kurento在处理rtp流时，需要创建一个rtpbin这样一个element。我上一篇，分析了kurento是怎么通过工厂模式，创建一个gstreamer中的element对象。
这种工厂模式，提供了很大的灵活性，有新的需求的时候，就可以继承父类，构造新的处理逻辑。例如关于webrtc的rtp流的处理，在C层，KmsWebrtcEndpoint继承了KmsBaseRtpEndpoint。
基于mediasoup的多方通话研究（一）
mediasoup简介
mediasoup的特性
安装mediasoup-demo
本地运行Demo
server的配置文件
mediasoup的原理
扩展与展望
总结
mediasoup简介
webrtc中多流的实现越来越简单，也越来越规范高效化，从planB-->到unifiedPlan，不过做的早的一些视频会议还是基于plan A做的，也是老版本的webrtc版本，planB兼容planA，不过后边的趋势一定是unifiedplan，这边刚好看到对这三个SDP多流标准的说明的博文，就记录下，转载过来了，感谢原博主。本文转自https://blog.csdn.net/gyj072001/article/details/80406106
Plan A
一个PeerConnection一路媒体流。这里编辑文章摘要...
