[Rtsp]RTSP流媒体协议(多媒体播放控制协议)介绍(4)

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、实际效果

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