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

RTSP/HTTP/RTMP网络协议对比

RTSP/HTTP/RTMP网络协议对比

1,RTSP/RTP/RTCP协议族

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

该协议族RTSP是建立在TCP之上的,RTP、RTCP建立在UDP之上。不过也可以通过interleave的方式,将RTPRTSP一起在同一个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。


评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值