首页 | DV动态 | 数码产品 | 视频采编 | DV教程 | 图片 | IPTV-流媒体 | 网站建设 | DV社区
【收藏DV】
  最近3月排行
·服装号型
·张立宪:如果我是作文老师
RTSP协议、RTMP协议、HTTP协议的区别
2016/7/28 18:51:39
 

理论上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)

欢迎关注微信公众账号:手机烟台(mYantai)

 

  上一篇:HLS (HTTP Live Streaming)
  下一篇:4G LTE 网只能提供数据服务,不能承载语音通话
      更多...
::打印本页 ::      ::关闭窗口::


版权所有© 中国数码在线网站 DV OnLine©  鲁ICP备12016322号