理论上RTSP RTMPHTTP都可以做直播和点播，但一般做直播用RTSP RTMP，做点播用HTTP。做视频会议的时候原来用SIP协议，现在基本上被RTMP协议取代了。...
RTSP、 RTMP、HTTP的共同点、区别
共同点：
1：RTSP RTMP HTTP都是在应用应用层。
2： 理论上RTSP RTMPHTTP都可以做直播和点播，但一般做直播用RTSP RTMP，做点播用HTTP。做视频会议的时候原来用SIP协议，现在基本上被RTMP协议取代了。
区别：
1：HTTP: 即超文本传送协议(ftp即文件传输协议)。
rtsp:（Real Time Streaming Protocol），实时流传输协议。
rtmp：全称Routing Table Maintenance Protocol（路由选择表维护协议）。
2：HTTP将所有的数据作为文件做处理。http协议不是流媒体协议。
RTMP和RTSP协议是流媒体协议。
3：RTMP协议是Adobe的私有协议,未完全公开，RTSP协议和HTTP协议是共有协议，并有专门机构做维护。
4：RTMP协议一般传输的是flv，f4v格式流，RTSP协议一般传输的是ts,mp4格式的流。HTTP没有特定的流。
5：RTSP传输一般需要2-3个通道，命令和数据通道分离，HTTP和RTMP一般在TCP一个通道上传输命令和数据。
RTSP、RTCP、RTP区别
1：RTSP实时流协议
作为一个应用层协议，RTSP提供了一个可供扩展的框架，它的意义在于使得实时流媒体数据的受控和点播变得可能。总的说来，RTSP是一个流媒体表示 协议，主要用来控制具有实时特性的数据发送，但它本身并不传输数据，而是必须依赖于下层传输协议所提供的某些服务。RTSP可以对流媒体提供诸如播放、暂 停、快进等操作，它负责定义具体的控制消息、操作方法、状态码等，此外还描述了与RTP间的交互操作（RFC2326）。
2：RTCP控制协议
RTCP控制协议需要与RTP数据协议一起配合使用，当应用程序启动一个RTP会话时将同时占用两个端口，分别供RTP和RTCP使用。RTP本身并 不能为按序传输数据包提供可靠的保证，也不提供流量控制和拥塞控制，这些都由RTCP来负责完成。通常RTCP会采用与RTP相同的分发机制，向会话中的 所有成员周期性地发送控制信息，应用程序通过接收这些数据，从中获取会话参与者的相关资料，以及网络状况、分组丢失概率等反馈信息，从而能够对服务质量进 行控制或者对网络状况进行诊断。
RTCP协议的功能是通过不同的RTCP数据报来实现的，主要有如下几种类型：
SR：发送端报告，所谓发送端是指发出RTP数据报的应用程序或者终端，发送端同时也可以是接收端。(SERVER定时间发送给CLIENT)。
RR：接收端报告，所谓接收端是指仅接收但不发送RTP数据报的应用程序或者终端。(SERVER接收CLIENT端发送过来的响应)。
SDES：源描述，主要功能是作为会话成员有关标识信息的载体，如用户名、邮件地址、电话号码等，此外还具有向会话成员传达会话控制信息的功能。
BYE：通知离开，主要功能是指示某一个或者几个源不再有效，即通知会话中的其他成员自己将退出会话。
APP：由应用程序自己定义，解决了RTCP的扩展性问题，并且为协议的实现者提供了很大的灵活性。
3：RTP数据协议
RTP数据协议负责对流媒体数据进行封包并实现媒体流的实时传输，每一个RTP数据报都由头部（Header）和负载（Payload）两个部分组成，其中头部前12个字节的含义是固定的，而负载则可以是音频或者视频数据。
RTP用到的地方就是 PLAY ，服务器往客户端传输数据用UDP协议，RTP是在传输数据的前面加了个12字节的头(描述信息)。
RTP载荷封装设计本文的网络传输是基于IP协议，所以最大传输单元(MTU)最大为1500字节，在使用IP／UDP／RTP的协议层次结构的时候，这 其中包括至少20字节的IP头，8字节的UDP头，以及12字节的RTP头。这样，头信息至少要占用40个字节，那么RTP载荷的最大尺寸为1460字 节。以H264 为例，如果一帧数据大于1460，则需要分片打包，然后到接收端再拆包，组合成一帧数据，进行解码播放。
【RTMP协议与RTSP协议比较】
考虑做一个手机直播系统，首先需要指定一个合理的技术方案。由于自己以前不是搞多媒体这块，对流媒体开发不熟悉，自己的理解思维总习惯用java web开发的惯性走，先指定一个大体的框架。不管对还是错，先考虑其技术可行性。
框架的指定，首先取决于自己采用的流媒体协议，我们熟知的流媒体协议有RTMP,RTSP,HLS。网上有很多这方面的介绍，我懒得复制了，在这里只谈谈自己的看法。
先谈一下HLS，这个协议接触得最早，自己的个人理解，如果要开发一套准实时的手机音视频直播系统，需要支持iphone，android，windows phone等多款手机，这个协议真心不错。为什么是准实时呢，因为客户端播放的是最新切割的ts文件，它的延迟取决于切片的大小。
参考文章http://www.cnblogs.com/haibindev/archive/2013/01/30/2880764.html ，其思路步骤：
1、采集视频源和音频源的数据
2、对原始数据进行H264编码和AAC编码
3、视频和音频数据封装为MPEG-TS包
4、HLS分段生成策略及m3u8索引文件
5、HTTP传输协议
这里面的很多步骤需要用到ffmpeg编解码库，比如编码， 切片等。方便之处是可以使用普通的http服务器就ok了，推荐使用nginx，这是一款功能无比强大的web服务器，其反向代理，性能好的不可言喻。
由于我大学非计算机专业出身，或者说与计算机专业一点都不靠边，我的计算机语言功底弱爆了。数据结构算法真心是我的软肋，C++语言就会简单的用MFC编写hello world ，HLS当初就这样被我放弃了。
RTSP协议，这应该是实时性最好的了，如果要想实时性要求很高，比如0.5s以内，这个是不错的选择。前阵子模仿spydroid写了个建议的rtsp服务器，其实就是options，describe，setup，play，pause，teardown这几步了，这个协议用的最广泛，网上介绍也比较多。要想真正深入了解rtsp协议，c++语言功底好的可以查看live555 。 (DVOL本文转自：中国DV传媒 http://www.dvol.cn)
