回忆之城
生命在于折腾
posts - 510,comments - 9,trackbacks - 0

RTSP,实时流协议,是一个C/S多媒体节目协议,它可以控制流媒体数据在IP网络上的发送,同时提供用于音频和视频流的“VCR模式”远程控制功能,如停止、快进、快退和定位。同时RTSP又是一个应用层协议,用来与诸如RTP、RSVP等更低层的协议一起,提供基于Internet的整套流化服务。基于RTSP协议流媒体服务器的实现方案可以让流媒体在IP上自由翱翔。

RTSP协议

1.协议特点

RTSP协议具有如下的特点:

● 可扩展性:新方法和参数很容易加入RTSP。

● 易解析:RTSP可由标准 HTTP或MIME解析器解析。

● 安全:RTSP使用网页安全机制。

● 独立于传输:RTSP传输通道,可使用不可靠数据包协议(UDP)或可靠数据包协议(RDP),如要实现应用级可靠,可使用诸如TCP的可靠流协议。

● 记录设备控制:协议可控制记录和回放设备。

● 适合专业应用:通过SMPTE 时标,RTSP支持帧级精度,允许远程数字编辑。

● 演示描述中立:协议未强加特殊演示或元文件,可传送所用格式类型;然而,演示描述至少需包含一个RTSP URI。

● 代理与防火墙友好:协议可由应用和传输层防火墙处理。防火墙需要理解SETUP方法,为UDP媒体流打开一个“缺口”。

● 适当的服务器控制:如用户启动一个流,则也可以停止一个流。

● 传输协调:实际处理连续媒体流前,用户可协调传输方法。

● 性能协调:如基本特征无效,则必须有一些清理机制让用户决定那种方法不生效。这允许用户提出适合自己的界面。

2.同其他协议的关系

RTSP在功能上与HTTP有重叠,最明显的交叉是在流媒体内容的发布上——大多是通过网页进行的。目前的协议规范同时允许网页服务器和流媒体服务器支持RTSP实现。例如,演示描述可通过HTTP或RTSP获取,这样减少了基于浏览器情况下的往返传递时间,同时也支持独立的RTSP 服务器与不依赖HTTP的客户端通信。

但是,RTSP与HTTP 的本质差别在于以下五个方面

● RTSP和HTTP是两个不同的协议,它们采用不同的方法和协议标志符。

● RTSP协议的数据发送不占用协议带宽,并且以不同的协议发送。

● HTTP是一个不对称协议,客户端发出请求,服务器应答。在RTSP中,客户端和服务器都可发出请求,且请求是有状态的。

● HTTP是一个无状态协议,而RTSP在任何情况下,必须保持一定状态,以便在请求确认后的很长时间内,仍可设置参数,控制媒体流。

● RTSP使用ISO 10646(UTF-8)定义,而不使用ISO 8859-1定义,保持与当前的HTML一致。

虽然大多数实时媒体采用RTP作为传输协议,但RTSP并不绑定RTP。

重用HTTP的功能至少在两个方面有好处:安全和代理。由于要求非常接近,因此在缓存、代理和授权上采用HTTP功能是有价值的。

RTSP的实现

RTSP功能实现结构如下图所示。

RTSP在流媒体传输过程中,仅仅为双方建立连接,并不具备任何智能,也就不能很好地应付难以预料的网络状态。因此,必须在它原有功能的基础上,进行改进。

1、初始化

在建立连接之前,客户端应向服务器提出测试请求,即要求服务器向客户端发送相应的测试数据包。初始化的目的,是为了获取客户端和服务器之间的一些网络参数,估测基本网络状况,并以此选择相应的网络传输协议,使客户端获得最佳观看效果。

接到这个请求之后,服务器将根据自身情况进行如下测试:

● 利用同客户端建立的RTSP通道,采用TCP协议,下发测试数据包。

● 采用UDP协议,向客户端下发测试数据包。

测试数据包仅做测试用,上面带有相应的时间和顺序信息,其内部数据并无任何意义。

需要向RTSP增加一个新的方法TEST,以支持这种传输前的测试工作。

2、TCP传输

如果在TCP测试中,客户端反馈良好,即丢包率在可承受范围之内,并且在规定时间内到达,那么就认为客户端同服务器之间的网络状况良好, 可以采用RTP over TCP的方式发送数据。由于TCP没有丢包(其自身具有重传机制),网络状况又属于良好,因此客户端将有较高的视听享受。

当子网内存在防火墙时,就需要采用RTSP附加数据传输方式。即把音视频数据直接打包,在RTSP通信信道内传输。这种传输方式也存在一定的问题:

● 传输过程中,只是把音视频文件当成一个普通文件来处理,而没有考虑到它的音视频特性,不利于以后的扩展。

● 音频与视频文件没有分离,不利于某些特殊需求的场合。例如,客户端需要对音、视频做不同的处理。

● 客户端的反馈和RTSP的控制信息也是通过同一条RTSP信道传送,因此控制效率不高。

因此,一般情况下,都默认使用RTP over TCP的方式发送数据。

3、UDP传输

如果在TCP测试中,客户端的反馈存在比较大的问题,即网络情况不理想,就应该考虑进行UDP测试。

目前初步采取的措施,在服务器端准备了两种码率的视频文件——高码率和低码率。

收到客户端的TEST方法后,将采用UDP协议下发测试包。采取的策略是每间隔2秒,下发一个1500字节的UDP数据包。当丢包率处于一定范围(75%~85%)之内,就认为客户端的网络状况基本良好,可以下发高码率的电影文件;否则,认为测试不成功,由于网络状况的限制,仅对客户端下发低码率的电影文件。

在基于UDP的播放过程中,可能会出现轻微的马赛克,这是完全可以接受的。这些马赛克出现的主要原因是:

● 不可靠连接造成的网络丢包,为客户端被动丢包。

● 高质量文件(DVD->MP4)的高数据量,使得客户端解码线程和显示线程出现拥塞,从而出现客户端主动丢包。

但从整体而言,UDP传输消耗的带宽,要比TCP小许多。在一般的视频点播要求下,使用基于UDP的传输线路,是完全可以满足要求的。

4、传输反馈

在传输过程中,主要采取的方式是RTP over TCP或RTP over UDP,因此,在RTP端口之外,还存在一个回传端口RTCP。

在服务器收到客户端的RTCP回传信息后,需要对其进行判断。如果客户端的丢包率、解码率等指标在一定限度之下,就认为目前传送的视频文件可令客户端获得最大程度的音视频享受;否则,考虑改为传输更低码率的视频文件或放弃这次RTSP会话,以避免更大范围的拥塞。

5、实际效果

采取如上方法设计的系统,可以满足视频点播的基本要求,避免了服务器视频文件下发的盲目性,同时使客户端应用效果最好。

引入智能流技术

随着针对流媒体技术研究的不断深入,简单的流媒体实现已经不能满足人们日益增长的网络文化需求。即使在宽带条件下,当网络用户达到一定限额时,简单的流媒体技术将面临着网络拥塞、丢包等常见的网络问题。因此,如何在网络出现异常的情况下,依然保证客户端音视频享受的最大化,就成为现在研究的热点。

一种解决方法是服务器减少发送给客户端的数据而阻止再缓冲,在RealSystem 5.0中,这种方法称为“视频流瘦化”。这种方法的限制是RealVideo文件必须是一种数据速率设计,结果可通过抽取内部帧扩展到更低速率,导致质量较低,离原始数据速率越远,质量越差。

另一种解决方法是根据不同连接速率创建多个文件,根据用户连接,服务器发送相应文件,这种方法带来制作和管理上的困难,而且,用户连接是动态变化的,服务器也无法实时协调。

智能流技术通过两种途径克服带宽协调和流瘦化:首先,确立一个编码框架,允许不同速率的多个流同时编码,合并到同一个文件中;第二,采用一种复杂客户/服务器机制探测带宽变化。

针对软件、设备和数据传输速度上的差别,用户以不同带宽浏览音视频内容。为满足客户要求,Real Networks公司编码、记录不同速率下媒体数据,并保存在单一文件中,此文件被称为智能流文件,即创建可扩展流式文件。当客户端发出请求时,它将其带宽容量传给服务器,媒体服务器根据客户带宽将智能流文件相应部分传送给用户。以此方式,用户可使用最优质的传输,制作人员只需要压缩一次,管理员也只需要维护单一文件,而媒体服务器根据所得带宽自动切换。智能流通过描述Internet上变化的带宽特点来发送高质量媒体并保证其可靠性,并对混合连接环境的内容授权提供了解决方法。这样流媒体实现方式如下:对所有连接速率环境创建一个文件。在混合环境下以不同速率传送媒体。根据网络的变化情况,无缝切换到其他速率。关键帧优先,音频比部分视频帧数据更重要,向后兼容老版本RealPlayer。

posted on 2008-05-08 17:03 回忆之城 阅读(3572) 评论(0)  编辑 收藏 引用 所属分类: 行业相关
只有注册用户登录后才能发表评论。