我们在去年年末的时候一直致力于webrtc协议的开发和研究，经过几个月的开发，目前webrtc协议已经集成进了EasyPlayer.js播放器当中，这也是我们研发webrtc的新进展。作为视频通信市场上的新晋协议，webrtc常常被拿来和主流的RTMP、RTSP做比较。
大多数人都认为webrtc更适合现代视频传输需求的发展，未来webrtc的直播方案将会取代rtmp的直播方案，其实不然，RTMP由于具备良好的实用性和推流的稳定性并没有被市场淘汰。我们在开发出了webrtc协议的播放后，仍然对支持rtmp协议传输的视频平台EasyDSS做了功能拓展和开发，支持RTMP的EasyDSS平台仍然是我们产业当中的一个重要角色。
讲到RTMP，最常被用户诟病的就是其延迟性。有研究表明，在 0.1s 以下的延迟，用户几乎是无感知的；1s 左右的延迟，用户会明显注意到延时的发生，但在该时间内思维依然是连贯的；超过 10s 的延时，用户会失去等待的耐心。在所有关键技术指标中，RTMP协议的直播方案对延时的控制是最需要提升的。好在RTMP的实用性可以让大家忍受3-5s的延时，并且在最新版本的EasyDSS中，我们通过技术手段将其延时大大降低，在体育赛事、演唱会、新闻现场的直播场景中，EasyDSS已经做到了让用户感知不到延时的存在。
对于webrtc的开发，各大厂家则会更偏向于有高互动性要求的直播场景，我们的EasyRTC也是基于此来进行开发的。以直播连麦为例，主播端把通信直播流发到观众端，同时也可以把观众端拉上麦，实现主播和观众的互动。使用 WebRTC，内容实时传输，主播和观众可以进行音视频连麦互动，实时沟通。
不过通常来说，webrtc搭建直播的成本比RTMP更高，因为UDP 传输比 TCP 对资源消耗要多，在多进程模式下可能还会遇到内存资源的过多消耗，这些都导致开发及使用成本的增加。
至于webrtc和RTMP两大阵营的选择，主要还是看在场景的使用上，这就涉及到了是否存在强交互，即是否允许人为介入。在大并发的场景中，没有强交互的情况下，选用RTMP做传输较为合适，如果有强交互，则选取webrtc更加灵活。但这里值得注意的是，webrtc的方式将会在搭建成本上对运营者有更高的要求。
在视频传输、播放、分发的全过程中，是不存在独立运行的单一程序的，正因为webrtc和RTMP都可能同时被不同需求的项目所需要，所以我们将两种协议都做了保留，如果大家对这两个协议还想了解更多，或者是想直接对比两种协议的不同和差别，可直接下载EasyRTC或者EasyDSS测试。