音视频相关流媒体协议对比

RTSP/HTTP/RTMP网络协议对比

RTSP/HTTP/RTMP网络协议对比

1，RTSP/RTP/RTCP协议族

本协议族是最早的视频传输协议。其中RTSP协议用于视频点播的会话控制，例如发起点播请求的SETUP请求，进行具体播放操作的PLAY、PAUSE请求，视频的跳转也是通过PLAY请求的参数支持的。而RTP协议用于具体的视频数据流的传输。RTCP协议中的C是控制的意思，用于在视频流数据之外，丢包或者码率之类的控制。

该协议族RTSP是建立在TCP之上的，RTP、RTCP建立在UDP之上。不过也可以通过interleave的方式，将RTP和RTSP一起在同一个TCP连接上传输。

RTSP协议族，是最早被提出来的，因此很多考虑的地方，都还带有早期的特征。比如使用UDP，是考虑到传输的效率，以及视频协议本身对丢包就有一定的容忍度。但是UDP协议，显然不能用于更大规模的网络，而且复杂网络下路由器的穿透也是问题。

从视频角度而言，RTSP协议族的优势，在于可以控制到视频帧，因此可以承载实时性很高的应用。这个优点是相对于HTTP方式的最大优点。H.323视频会议协议，底层一般采用RTSP协议。RTSP协议族的复杂度主要集中在服务器端，因为服务器端需要parse视频文件，seek到具体的视频帧，而且可能还需要进行倍速播放（就是老旧的DVD带的那种2倍速，4倍速播放的功能），倍速播放功能是RTSP协议独有的，其他视频协议都无法支持。

缺点，就是服务器端的复杂度也比较高，实现起来也比较复杂。

 

2，HTTP协议

HTTP的视频协议，主要是在互联网普及之后。在互联网上看视频的需求下形成的。

2.1 HTTP

最初的HTTP视频协议，没有任何特别之处，就是通用的HTTP文件渐进式下载。本质就是下载视频文件，而利用视频文件本身的特点，就是存在头部信息，和部分视频帧数据，就完全可以解码播放了。显然这种方式需要将视频文件的头部信息放在文件的前面。有些例如faststart工具，就是专门做这个功能的。

但是最为原始的状态下，视频无法进行快进或者跳转播放到文件尚未被下载到的部分。这个时候对HTTP协议提出了range-request的要求。这个目前几乎所有HTTP的服务器都支持了。range-request，是请求文件的部分数据，指定偏移字节数。在视频客户端解析出视频文件的头部后，就可以判断后续视频相应的帧的位置了。或者根据码率等信息，计算相应的为位置。

2.2

支持HTTP range-request的服务器，目前就可以支持我们一般网络看视频的要求了。但是，这种方式，无法支持实时视频流，或者准实时视频流。因为视频流，是不存在一个视频文件的概念的。HTTP协议播放视频的好处，就是简单。采取通用的HTTP服务器，就可以提供服务，不需要专门类型的服务器，也不需要特别的网络端口，穿过路由器防火墙一点都没有问题。而且还可以利用通用的CDN来简化视频的部署分发的工作，减少带宽的使用。CDN代理服务器对这个协议的缓存优化相当成熟，而很少有代理服务器对 RTSP 的进行缓存优化。

这个是目前用于PC端或者网页端，视频点播业务，最常见的解决方案。客户端的实现，一般采用flash完成，flash本是的videoplayer或者videodisplay控件就可以完成。资源一般采用flv格式，也可以使用mp4格式。

在此基础上，多家公司推出了自己的解决方法。

2.3 HLS HDS MSS DASH

苹果推出的HTTP LiveStreaming，就是随着苹果设备的普及得以广泛应用的一种。从名词就可以判断出来，HLS支持Live直播式的视频传输。HTTP采用m3u8作为索引文件，视频为MPEG2-TS格式的片段文件。如果为直播视频流，则采取更新m3u8文件，从而更新视频索引列表，达到视频直播的目的。但是这种方法，因为最终视频是片段文件，所以必然存在片段视频长度的延迟。因此只可以用于对实时性要求没有那么高的准实时视频流。但是HLS方式，因为采用了较早的MPEG2-TS格式，这种格式的overhead，也就是头部信息占据总文件的比例比较大，也就是效率不够高。之所以没有使用其他格式，主要是商业竞争和版权的问题。

相应的，adobe公司，推出相似的HTTPdynamic streaming。这种方式本质和HLS的策略是类似的，就是通过索引文件+视频片段的方式。但是显然采用的索引格式和视频片段格式都不一样的。HDS采用的是视频格式是flv或者f4v，索引格式记不清楚了。

类似的，微软也推出了Microsoft Smooth Streaming，也即是mss的视频播出方式，采用的视频格式是分段mp4格式。

MPEG标准组则推出了DynamicAdaptive Streaming over HTTP,DASH.采用的视频格式为3GPP吧。

显然，这个目前是百花齐放的状态，虽然最常用的的是HLS，谁叫苹果这么霸气呢。而安卓和苹果上面对于flash都有限制，而HDS是adobe推出在adobe平台上面的。mss，只有在少数几个地方见到过。dash，目前仅仅是论文里面的产物。

以上的协议，主要是解决一个问题，就是自适应码率切换，上面的dynamic，adaptive都是类似的意思。主要是利用索引文件中同时给出不同码率的视频文件的地址，这样播放器端，可以根据带宽情况，自适应选择不同码率的视频文件。

同时在视频直播方面，在安卓和iOS平台以外，还有很多视频服务器提供厂商，自己开发协议，一般采用方式为固定时间片段的flv文件的方式（采用flv，是因为flash上方便播放）

2.4 HTML5

同时HTML制定厂商也不寂寞，推出HTML5这种方式，这种方式本质上，和前面的HTTP视频协议没有任何区别。但是播放器端，不再依赖于特定的插件如flash，或者其他播放软件，而是可以支持浏览器的直接视频播放。采用的是html中嵌入video标签，同时直接指明视频的url。不过，不同的浏览器，对于音视频的格式支持不完全相同。比较通用的是视频H。264格式，音频AAC格式，封装格式MP4。

2.5其他

在HTTP协议的基础上，各家公司，针对自己的业务特性，也可能开发自己的专有的数据格式，或者协议。但是都是在上述的基本上做出一些细微的修改而已。毕竟国内的技术体系，还完全无法提出一个新的技术的程度。（google，就提出新的编码格式替换H.264,SPDY协议，这个国内做不到的）。

一般只会做到例如HTTP特殊字段或者特殊参数，传递到flash中做出一定的解释。或者在原有的视频文件格式基础上添加一些特殊意义的头部等等。

 

 

3，RTMP

这个是adobe公司自己推出的视频播放协议。需要专用的服务器，如FMS，开源的有red5.这种协议也是flash默认支持的。

4，总结对比

总体来看，视频相关的协议发展，是从专用的协议、服务器，逐渐向HTTP过渡的过程。而且逐渐适应网络的发展和需求，复杂多变的网络环境，才催生了http的视频协议。

 

Rtsp：

优点： 带宽好时效率高 倍速播放 控制精准，任意选择播放点

缺点： 服务端实现复杂 代理服务器弱（数量少，优化少） 无路由器防火墙穿透 管流分离（需要1-3个通道）

 

HTTP系：

优点： 基础设施完善 代理服务器强（数量多，CDN缓存优化） 实现简单，部署快 自适应码率切换 有路由器防火墙穿透

缺点： 实时性不高 播放控制精度不高 播放器要做协议授权，开放度比rtsp低 无倍速播放

 

RTMP：

优点： 实时性高 控制精准，任意选择播放点 应用广泛（flash）

缺点： Flv缓存在内存，会消耗服务器资源 协议复杂，未全部公开 似乎CDN缓存不好搞（未接触过）

 

5，推荐应用

  . 流媒体设备或系统接入：安防行业使用rtsp，民用相机使用RTMP协议。

  . 流媒体系统内部直播分发使用RTMP。

  .PC+直播+实时性要求高：使用flash播放RTMP。

  .PC+直播+没有实时性要求：使用RTMP或者HLS均可。

  .PC+点播：使用HTTP或者HLS。

  .Apple IOS/OSX：都使用HLS（实时性要求高得自己解析RTMP，或者使用外部库，

    譬如https://www.vitamio.org）

  .Andorid：和IOS一样，不过可以确定的是可以自己开发支持RTMP。