rtsp协议 编码_udp协议_视频编码协议(3)

? 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中解释。

1.3 术语

一些术语原由HTTP/1.1采用。在HTTP/1.1中定义的术语这里不再列举。

合控制：

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

会议：

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

客户端：

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

连接：

两个应用程序以通讯为目的在传输层建立虚拟电路。

容器文件：

可以容纳多个共同播放时包含表示(presentation)的媒体流的文件。RTSP服务器可以为这些容器文件提供合控制，但容器文件的概念本身并不是本协议内容。

连续媒体：

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

实体：

作为请求或者回应的有效负荷传输的信息。由以实体标题域（entity-header field）形式存在的元信息和以实体主体（entity body）形式存在的内容组成，如第八章所述。

媒体的初始化：

数据类型/编码的具体初始化，这些包括时钟输率，颜色表等。用户请求媒体回放的任何独立传输信息，是在创建流时初始化媒体流相位时产生的。

媒体参数:

针对回放前或回放过程中有可能改变的媒体类型而专门设定的参数。

媒宸 衿鳎?BR>可对一个或多个媒体流提供回放和录制服务的服务器。同一个表示(presentation)中不同的媒体流可能来自于不同的媒体服务 器。媒体服务器可以建立在作为传送请求表示(presentation)的Web服务器的主机上，也可以建立在不同的主机上。

媒体服务器重定向：

重新定向媒体客户端到另外一个媒体服务器。

(媒体)流：

单个媒体实例，比如，在应用用音频流或视频流。当使用RTP时，流包括由RTP 会话(session)中源所创建的所有RTP和RTCP包。这和定义DSM-CC流时相同。

消息：

RTSP通讯的基本单元。由15章语法定义的一串八位位组组成，并通过连接或者无连接协议传送。

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