rtsp协议 编码_海康rtsp协议_http 协议(5)

合适的服务器控制：

若客户端能启动一个流，它必须也能停止一个流。服务器不能启动一个用户不能停止的流。

传输协商：

实际处理连续媒体流前，客户端可协商传输方法。

性能协商：

若基础特性被禁用，必须有某种明确的机制让用户决定哪种方法将不不被实现。这允许用户提出适合的用户界面。例如，如果不允许寻找，用户界面必须能禁止位置条滑动。

早期曾要求RTSP支持多用户，但现在有了更好的方案，就是保证RTSP能很容易扩展成支持多用户即可。因为流的标志可以被多个控制流使用，因此可以"轮换持有控制器"。协议不涉及到多个客户端如何协调入口--这项任务被留给"社会协议"或其他层。

1.5 扩展RTSP

由于不是所有媒体服务器有着相同的功能，媒体服务器有必要支持不同的请求集。例如：

服务器可能只能回放，因此不必支持录制请求。

用于提供现场直播的服务器可能不支持寻找（绝对位置）功能。

一些服务器可能不支持设置流参数，因此不支持GET_PARAMETER和SET_PARAMETER请求。

但服务器应该实现所有12章中要求的标题域。

表示描述(presentationdescription)应当保证不提出服务器不支持的功能，这种情形和HTTP/1.1 [2]中，[H19.6]所描述的方法不太可能被所有服务器都支持的情形一致。

RTSP 可以如下三种方式扩展，按所支持的改变多少排序：

*已有的方法可以扩展加入新参数，只要这些参数可以被接收方安全地忽略。（这和给一种HTML tag增加新标签是一样的）如果客户端在请求失败时需要一个拒绝确认，需要在请求：字段(见Section12.32)中加入一个对应于该扩展的标签。

*可以加入新方法。如果接收方不理解请求，它就返回一个501错误码（意指未实现），发送方就不应再尝试这种方法。客户端可以用OPTIONS方法去询问服务器支持的方法。服务器应该在公共回应头里列出它所支持的所有方法。

*可以定义新版本的协议，以支持几乎所有方面的改变（除了版本协议号的位置）。

1.6 整体运作

每个表示和媒体流可用RTSP URL识别。表示组成的整个表示与媒体属性由表示描述(presentation description)文件定义，其式不在本协议中定义。客户端可以通过HTTP或其它途径（如email）获得此表示描述文件，它没有必要保存在媒体服务器上。

根据此规范的目标，我们假想一个表示描述(presentation description)描述了多个表示(presentation)，每个表示(presentation)维持一个统一的时间轴。为简明但不失一般性，假定表示描述(presentation description)正好包含一个这样的表示(presentation)。表示(presentation)可包含多个媒体流。

表示描述(presentation description)包含组成表示的流的描述，包括它们的编码，语言和使用户可以选择最符合要求媒体的其他参数。在表示描述中，各个由RTSP分别控制的媒体流各有一个RTSPURL。RTSP URL指出了处理具体媒体流的服务器以及存在于该服务器上流的名字。多个媒体流可以放到不同的服务器上，比如音频和视频流可以分别放到不同服务器而实现均分负载。描述（description)还列出了服务器可使用的传输方法。

除媒体参数外，网络目标地址和端口也需要决定。下面区分几种操作模式：

单播：

多播，服务器选择地址：

媒体服务器选择多播地址和端口，这是现场直播或准点播常用的方式。

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/tongxinshuyu/article-47669-5.html