做转码服务的原型时，看了看MCU的实现，考虑到如果不做转码，可以将多路rtp流直接合成为一路rtmp流输出，这样就相当于实现了多人连麦，并将多人连麦的视频转发直播了，所以做了这个简单的原型实现！
DEMO只实现了接收一路rtp流，输出一路rtmp流！
基于ZLMediaKit，实现一个接收多路rtp流，输出一路rtmp流的简单MCU
2020-07-14 09:24:05开源实时音视频技术WebRTC中RTP/RTCP数据传输协议的应用
2020-07-12 14:51:19
|
学习RFC3550：RTP/RTCP实时传输协议基础知识
2020-07-12 14:49:51、前言
RF3550定义了实时传输协议RTP和它的控制协议RTCP。RTP协议是Internet上针对实时流媒体传输的基础协议，该协议详细说明在互联网上传输音视频的标准数据包格式。RTP本身只保证实时数据的传输，并不能提供可靠传输、流量控制和拥塞控制等服务质量保证，这需要RTCP协议提供这些服务。
RTCP协议负责流媒体的传输质量保证，提供流量控制和拥塞控制等服务。在RTP会话期间，各参与者周期性彼此发送RTCP报文。报文中包含各参与者数据发送和接收等统计信息，参与者可以据此动态控制流媒体传输质量。RTP和RTCP配合使用，通过有效反馈使使流媒体传输效率最佳化。
IETF的RFC3550定义了RTP/RTCP协议的基本内容，包括报文格式、传输规则等。除此之外，IETF还定义一系列扩展协议，包括RTP扩展，RTCP报文类型扩展，等等。本文对这些协议进行初步归纳总结，在分析RFC3550的基础上，重点分析RTP系列协议，并以报文类型为主线分析RTCP系列协议。
WebRTC源码分析——呼叫建立过程之二(创建PeerConnectionFactory)
2020-07-12 06:58:40目录
1. 引言
2 PeerConnectionFactory对象的创建
2.1 CreatePeerConnectionFactory方法解析
2.1.1 创建媒体引擎MediaEngine——CreateMediaEngine方法
2.1.2 创建实体类PeerConnectionFactory——CreateModularPeerConnectionFactory方法
1）PeerConnectionFactory的创建——构造
2）PeerConnectionFactory初始化——Initialize方法
3）PeerConnectionFactoryProxy代理的创建与返回——防止线程乱入
3 PeerConnectionFactory对象简析
3.1 PeerConnectionFactory拥有的资源——私有成员
3.1 PeerConnectionFactory提供的能力——公有方法
WEBRTC浅析（二） ICE 机制简介及STUN通信流程
2020-07-11 22:27:36WEBRTC ICE 简介
在这里，我会介绍一下WEBRTC 中， ICE 的机制。主要分为三个部分。
第一部分，为ICE的协议部分介绍。
第二部分，为STUN 的信令连接图。
第二部分，为WEBRTC中代码的实现流程。
webrtc笔记(3): 多人视频通讯常用架构Mesh/MCU/SFU
2020-07-11 21:45:20问题：为什么要搞这么多架构？
webrtc虽然是一项主要使用p2p的实时通讯技术，本应该是无中心化节点的，但是在一些大型多人通讯场景，如果都使用端对端直连，端上会遇到很带宽和性能的问题，所以就有了下图的三种架构。
基于WebRTC构建超低延迟(500ms)的直播系统
2020-07-11 21:40:08上周写了一篇文章基于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的分发能力, 我们应该切端观看端向发送端的反馈机制. 在牺牲一定视频质量的情况做到大规模的分发.
基于RTMP和WebRTC开发大规模低延迟(1000毫秒内)直播系统
2020-07-11 21:35:47随着移动设备大规模的普及以及流量的资费越来越便宜, 超低延迟的场景越来越多. 从去年到今年火过的场景就有在线娃娃机, 直播答题, 在线K歌等. 但要做到音视频的超低延迟确是很不容易, 编码延迟, 网络丢包, 网络抖动, 多节点relay,视频分段传输,播放端缓存等等都会带来延迟.
WebRTC兴起提供的方案以及遇到的问题
WebRTC技术的兴起为低延迟音视频传输带来了解决方案, 但WebRTC是为端到端设计的, 适合的场景是小规模内的实时互动, 例如视频会议, 连麦场景. 即使加入了SFU Media server作为转发服务器, 也很难做到大规模的分发. 另外一个需要考量的是流量成本, WebRTC的实时流量是通过UDP传输的(某些情况下可以用TCP), 无法复用在传统CDN的架构之上, 实时的流量价格更是CDN流量的3倍以上, 部署一个超低延迟的直播网络成本非常高.
RTMP系统推流播放延迟分析
WebRTC使用SDES代替DTLS协商
2020-07-11 21:33:57WebRTC作为浏览器中的一个组件，在设计的时候考虑了大量了安全问题，比如要求getUserMedia在加密网页中才能打开摄像头， 使用MDNS来防止IP地址的泄露， 使用DTLS来加密datachannel数据，使用DTLS-SRTP来加密音视频数据等等，在带来更高的安全性的同时也带来更多的复杂性，更多的资源占用。尤其是对于开发者来说，DTLS-SRTP的引入带来很多问题，工程的复杂性，服务器资源的占用，以及音视频建立连接的延迟等，我们使用SDES来减少DTLS带来的影响，在保证兼容WebRTC协议的同时减少系统的复杂度，降低弱网下的首帧延迟。
网页版WebRTC多人聊天Demo
2020-07-11 14:21:46网页版WebRTC多人聊天Demo
本文基于Codelab中step7，在其基础上作简单修改，使其支持多人视频通讯，本文暂时只支持星状结构三人聊天，多人聊天可以在基础上扩展，原理相同。
一.源码分析
该工程包括三个文件：server.js，main.js，index.html。
1.server.js