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

*RTSP引入了很多新方法并且有不同的协议标识符。

*RTSP服务器在绝大多数默认情况下需要维持状态，而HTTP是无状态协议。

*RTSP客户机和服务器都可以发出请求。

*数据由信带外的另一个协议传送（但有一个特例）。

*RTSP使用ISO 10646(UTF-8) 而不是ISO 8859-1，以配合当前HTML的国际化。

*RTSP的URI请求时总是包含绝对URI。而由于历史原因造成的后向兼容性问题，HTTP/1.1只在请求中包含绝对路径，把主机名放入单独的头部域中。

当只有一个IP的主机要提供多个文档树时，可使"虚拟主机"的实现更简单。

协议支持以下操作：

从媒体服务器上获得媒体：

用户可通过HTTP或其它途径请求一个表示描述。如果该表示是组播，表示描述就包含用于该连续媒体的的多播地址和端口。如表示仅通过单播发送给用户，用户为了安全应起见要提供目的地址。

邀请媒体服务器进入会议：

媒体服务器可被"邀请"加入已存在的的会议，包括向该表示内回放媒体，或记录此表示中的一部分或全部媒体。这种模式在分布式教学应用上很有用。会议中的各方可轮流"按网络的按钮"。

将媒体加到已存在的表示中：

现场表示的专用概念。当服务器可以告诉客户端"可以附加媒体"时有用。

和HTTP/1.1类，RTSP的请求可由代理、通道与缓存处理。

1.2 要求

在本文档中的关键字"必须"，"必须不"、"需要"、"必须"、"必须不"、"应该"、"不应该"、"推荐"、"可能"、和"可选的"，都和RFC2119 [4]中的解释一致。

1.3 术语

一些HTTP/1.1的术语被采用。这里没有举出的术语，其定义与HTTP/1.1相同。

合控制：

服务器使用一条时间线对多个流进行控制。对音频/视频的回放来讲，这意味着客户端仅需发送一条播放或者暂停消息就可同时控制音频和视频的回放。

会议：

多方参与的多媒体表示，这里的多方意味着大于或等于一方。

客户端：

指请求媒体服务器上连续流媒体数据的客户端。

连接：

以通讯为目的，在传输层建立的两个程序间的虚拟信道。

容器文件：

可以容纳多个媒体流的文件，而这些媒体流共同播放时通常还包含一个表示。RTSP服务器可以为这些容器文件提供合控制，但容器文件的概念本身并不包含在本协议中。

连续媒体：

接受器和数据源之间存在时序关系的数据。也就是说，接受器需要重放原来存在于源数据中的时序关系。最普通的连续媒体的例子是音频和视频。连续媒体可以是实时的（交互的），它们在源和接受器之间是一种紧密的时序关系；或者是流（回放）的形式，时序关系没那么严。

实体：

请求或者响应的载荷部分中所传输的信息。实体由信息元组成，而每个信息元由由实体头部域和实体主体组成。实体头部域内是信息式，实体主体内是信息内容，如第8章所述。

媒体初始化：

数据类型/编码的具体初始化。这包括时钟频率，颜色空间等。客户端请求一个媒体流回放时所需的任何独立于传输的信息，都是在流创建时媒体初始化阶段产生的。

媒体参数:

对于某种特定的媒体类型来说，回放前或者回放中有可能会发生改变的一些参数。

媒体服务器：

提供一个或多个媒体流之回放或录制服务的服务器。同一个表示(presentation)中不同的媒体流可能来自于不同的媒体服务器。媒体服务器可以建在激活该表示(presentation)的Web服务器上，也可以建立在不同的主机上。

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