rtmp, rtsp, webrtc 简单的关系总结

• RTSP(Real-Time Stream Protocol)协议

RTSP以客户端方式工作，对流媒体提供播放、暂停、后退、前进等操作。该标准由IETF指定，对应的协议是RFC2326。

RTSP作为一个应用层协议，提供了一个可供扩展的框架，使得流媒体的受控和点播变得可能，它主要用来控制具有实时特性的数据的发送，但其本身并不用于传送流媒体数据，而必须依赖下层传输协议(如RTP/RTCP)所提供的服务来完成流媒体数据的传送。RTSP负责定义具体的控制信息、操作方法、状态码，以及描述与RTP之间的交互操作。RTSP媒体服务协议框架如下：

• RTMP 是 Real Time Messaging Protocol（实时消息传输协议）的首字母缩写，基于TCP

包括 RTMP 基本协议及 RTMPT/RTMPS/RTMPE 等多种变种。RTMP 是一种设计用来进行实时数据通信的网络协议，主要用来在 Flash/AIR 平台和支持 RTMP 协议的流媒体/交互服务器之间进行音视频和数据通信。支持该协议的软件包括 Adobe Media Server/Ultrant Media Server/red5 等。
RTMP 是目前主流的流媒体传输协议，广泛用于直播领域，可以说市面上绝大多数的直播产品都采用了这个协议。
 

优点 
·CDN 支持良好，主流的 CDN 厂商都支持 
·协议简单，在各平台上实现容易 
缺点 
·基于 TCP ，传输成本高，在弱网环境丢包率高的情况下问题显著 
·不支持浏览器推送 
·Adobe 私有协议，Adobe 已经不再更新

 

• WebRTC，名称源自网页即时通信（英语：Web Real-Time Communication）的缩写，是一个支持网页浏览器进行实时语音对话或视频对话的 API

它于 2011 年 6 月 1 日开源并在 Google、Mozilla、Opera 支持下被纳入万维网联盟的 W3C 推荐标准。 
目前主要应用于视频会议和连麦中，协议分层如下：

优点 
·W3C 标准，主流浏览器支持程度高 
·Google 在背后支撑，并在各平台有参考实现 
·底层基于 SRTP 和 UDP，弱网情况优化空间大 
·可以实现点对点通信，通信双方延时低 
缺点 
·ICE,STUN,TURN 传统 CDN 没有类似的服务提供 

•  基于 UDP 的私有协议

有些直播应用会使用 UDP 做为底层协议开发自己的私有协议，因为 UDP 在弱网环境下的优势通过一些定制化的调优可以达到比较好的弱网优化效果，但同样因为是私有协议也势必有现实问题： 

优点 
·更多空间进行定制化优化 
缺点 
·开发成本高 
·CDN 不友好，需要自建 CDN 或者和 CDN 达成协议 
·独立作战，无法和社区一起演进

 

• 關於libjingle_peerconnection庫 

为什么是peerconnection的库呢？
第一，peerconnection是webrtc对外的提供的比较全的接口的类
第二，peerconnection在框架的高层，与应用层最近，需要的改动最少
第三，peerconnection最容易编译和集成
第四，如果你想要两个人简单的直播连麦，peerconnection就足够了

直播
简单来说就是一个人发布自己的直播供别人观看，可以有一点延迟，重点在服务器的稳定和流量带宽，CDN的分发。而目前直播技术最简单成熟的就是基于RTMP的推流拉流，在此我推荐SRS（http://www.chnvideo.com/blog-classic-srs.html），原因很简单，就是简单高效稳定开源，文章可参考http://www.cnblogs.com/meetrice/p/5428985.html

连麦
连麦是现在直播中比较高大上的一个功能，可以和主播直接互动，市面上的映客，ME直播可以，一般都是两个人或三个人之间互动，可以说是为直播锦上添花，拉近了主播和和粉丝的距离，增加了人气等等等。
而基于WebRTC的P2P的连麦是比较简单的，最简单的思路，主播和粉丝P2P通了之后，主播将两路视频或者合成一路直接推送到SRS服务器上，供粉丝观看即可，连麦者获取主播视频本地观看。多人连麦可需要稍微复杂的服务架构设计和实现，有较大的难度，保证实时和稳定以及质量。
另外连麦模型还可以参考:视频直播中用户连麦技术模型与特点分析 http://www.cnblogs.com/oldmanlv/p/5625923.html
 

• webrtc 怎么了？？？？

ancientcc
编程的魅力在于不确定
1 人赞同了该回答
这要看你用的客户端是什么。如果你是想用浏览器，那webrtc不是好方案。但如果你是用app，可以肯定回答：可以，而且强烈建议你基于webrtc。

为什么说对App是完全可行呢？浏览器在用的Webrtc其实分两层，底层是个用C++写的库（Native Code），然后上层写个Javascript封装，以便供HTML5调用。既然是写app，那完全不用管上层Js封装，而且Google在开发Webrtc时已考虑用在app，底层C++库的API已做得很完善了。

对直播使用场景，很多人是用移动设备，移动设备基本都是用app。而webrtc中的Native Code部分跨平台特性很好，基本不用改，就能写出完全跨iOS、Android、Windows平台的代码，所以有了iOS/Android app，基本不耗成本Windows上的app就出来了。——当然，如果有人在Windows还是坚持要用浏览器，那只能说在Windoes不得不留有瑕疵。

为什么有人一想到webrtc，直观就认为只有p2p？我猜是和默认的信令服务器是p2p有关。关于这默认的信令服务器是怎么个交互流程，我有画过图。http://www.libsdl.cn/bbs/forum.php?mod=viewthread&tid=83&extra=page%3D2

根据这个图，你可以模糊中发现，只要换了信令服务器，就有可能变成直播。而事实也的确是这样。就像有人说直播时图像单向就够了（主播传向观众），而Webrtc是双向，——只要改信令服务器，立刻就单向了。

为什么强烈建议你基于webrtc？对直播系统，难的不是服务器，而是客户端。客户端难的地方则主要体现在两个方面，一是网络传输有关，像侦听事件，同步主线程和读线程，穿透；二是流数据有关，像编码、解码、回声消除。而这些正是webrtc帮你解决了。也正因为如此，现在很多直播系统最早的客户端其实是以webrtc为根的，只是后面自个不断优化，慢慢地变成自个系统而已。——诚然，官方webrtc是有地方不尽如意，但它们不断更新，就像最近一段时间优化了回声消除。
 

• WebRTC怎麼用

WebRTC实现了三个API，分别是:
* MediaStream：通过MediaStream的API能够通过设备的摄像头及话筒获得视频、音频的同步流
* RTCPeerConnection：RTCPeerConnection是WebRTC用于构建点对点之间稳定、高效的流传输的组件
* RTCDataChannel：RTCDataChannel使得浏览器之间（点对点）建立一个高吞吐量、低延时的信道，用于传输任意数据

摘取鏈接:
视频直播技术详解——推流和传输, 2016-9-13,七牛雲
WebRTC + 直播 + 连麦 = AnyRTC ?2016-9-5
从无到有开发连麦直播技术点整理-AnyRTC
(非常棒的知乎討論合集)可以用WebRTC来做视频直播吗？
如何搭建一个完整的视频直播系统？
Android IOS WebRTC 音视频开发总结（五八）– 图文解说视频直播原理
使用WebRTC搭建前端视频聊天室——入门篇,2014-3
影响音频质量和稳定性的因素到底有哪些呢？2016-7-7
CDN的原理,構架,播放延時(網絡延時\網絡抖動\網絡丟包),連麥短板(多路RTMP流实现/主播端与连麦者P2P,2016)
WebRTC的优缺点,2016-6-28
为何一直推荐WebRTC？
 

以上算是对直播推流的一点儿小的总结，大多从多个blog合并而来。