it运维服务内容,杭州优化公司排行榜,网站建设与网页制作基础入门教程,设计感十足的网站目的#xff1a; 实时流协议#xff08;RTSP#xff09;用于建立和控制单个或多个时间同步的连续媒体流#xff0c;例如音频和视频。RTSP 通常不负责实际传输这些连续的媒体流#xff0c;但可以将连续媒体流与控制流进行交错传输#xff08;参见第 10.12 节#xff09;。… 目的 实时流协议RTSP用于建立和控制单个或多个时间同步的连续媒体流例如音频和视频。RTSP 通常不负责实际传输这些连续的媒体流但可以将连续媒体流与控制流进行交错传输参见第 10.12 节。换句话说RTSP 就像是多媒体服务器的“网络遥控器”。 要控制的流集合由呈现描述presentation description来定义。本备忘录未定义呈现描述的格式。 RTSP 中没有连接的概念相反服务器通过一个标识符维护一个会话。RTSP 会话并不与传输层连接例如 TCP 连接绑定。在一个 RTSP 会话期间RTSP 客户端可以多次打开和关闭与服务器之间的可靠传输连接以发送 RTSP 请求。或者它也可以使用诸如 UDP 之类的无连接传输协议。 RTSP 控制的流可以使用 RTP [1]但 RTSP 的操作不依赖于用于传输连续媒体的传输机制。该协议在语法和操作上有意与 HTTP/1.1 [2] 类似因此在大多数情况下HTTP 的扩展机制也可以添加到 RTSP 中。然而RTSP 在许多重要方面与 HTTP 不同 RTSP 引入了许多新的方法并且具有不同的协议标识符。 RTSP 服务器在几乎所有情况下都需要默认维护状态这与 HTTP 的无状态特性不同。 RTSP 服务器和客户端都可以发起请求。 数据由不同的协议进行带外传输。有一个例外情况。 RTSP 被定义为使用 ISO 10646 (UTF-8) 而不是 ISO 8859-1这与当前 HTML 国际化的工作保持一致 [3]。 Request-URI 始终包含绝对 URI。由于与历史错误的向后兼容性HTTP/1.1 [2] 仅在请求中携带绝对路径并将主机名放在一个单独的头字段中。 这使得“虚拟主机”更加容易即一个具有单个 IP 地址的主机可以托管多个文档树 该协议支持以下操作 1、 从媒体服务器检索媒体 客户端可以通过 HTTP 或其他方法请求演示描述。如果演示内容是通过多播进行的演示描述将包含用于连续媒体的多播地址和端口。如果演示内容仅通过单播发送给客户端出于安全原因客户端需要提供目标地址。 2、邀请媒体服务器加入会议 : 媒体服务器可以被“邀请”加入一个已存在的会议既可以将媒体播放到演示中也可以录制演示中的全部或部分媒体。此模式对分布式教学应用非常有用。会议中的多方可以轮流“按下遥控按钮”。 3、向现有演示中添加媒体特别是对于实时演示如果服务器能够通知客户端有新的媒体可用这是非常有用的。 RTSP 请求可以像 HTTP/1.1 [2] 中那样由代理、隧道和缓存处理。 协议特性 RTSP 具有以下性质 1、 可扩展性可以轻松地向 RTSP 添加新方法和参数。 2、 易于解析RTSP 可以通过标准的 HTTP 或 MIME 解析器进行解析。 3、 安全性RTSP 重新利用了网络安全机制。所有 HTTP 认证机制例如基本认证RFC 2068 [2第11.1节]和摘要认证RFC 2069 [8]都可以直接应用。此外还可以复用传输层或网络层的安全机制。 4、 传输独立性RTSP 可以使用不可靠的数据报协议UDPRFC 768 [9]、可靠的数据报协议RDPRFC 1151未广泛使用 [10]或可靠的流协议如 TCPRFC 793 [11]因为它实现了应用层的可靠性。 5、 多服务器能力一个展示中的每个媒体流可以驻留在不同的服务器上。客户端会自动与不同的媒体服务器建立多个并发的控制会话。媒体同步在传输层进行。 6、 录制设备的控制该协议可以控制录制和播放设备以及能够在两种模式间切换的设备如‘录像机’。 7、 流控制与会议初始化的分离流控制与邀请媒体服务器参加会议是分离的。唯一的要求是会议初始化协议要么提供、要么可以用于创建一个唯一的会议标识符。特别是SIP [12] 或 H.323 [13] 可以用于邀请服务器加入会议。 8、 适用于专业应用RTSP 支持通过 SMPTE 时间戳实现帧级精确度以允许远程数字编辑。 9、 呈现描述中立性该协议不强制要求特定的呈现描述或元文件格式并且可以传达要使用的格式类型。然而呈现描述必须至少包含一个 RTSP URI。 10、 代理和防火墙友好该协议应能够被应用层和传输层SOCKS [14]防火墙轻松处理。防火墙可能需要理解 SETUP 方法以便为 UDP 媒体流打开一个‘通道’ 11、HTTP 友好在合理的情况下RTSP 复用了 HTTP 的概念以便可以重用现有的基础设施。该基础设施包括用于将标签与内容关联的 PICS互联网内容选择平台 [15,16]。然而RTSP 不仅仅是向 HTTP 添加方法因为控制连续媒体在大多数情况下需要服务器状态。 12、 适当的服务器控制如果客户端能够启动流则必须能够停止流。服务器不应以客户端无法停止流的方式开始向客户端传输流。 13、 传输协商客户端可以在实际处理连续媒体流之前协商传输方式。 14、 功能协商如果基本功能被禁用必须有某种明确的机制让客户端确定哪些方法不会被实现。这使客户端能够呈现适当的用户界面。例如如果不允许寻址功能用户界面必须能够禁止移动滑动位置指示器。 15、RTSP 早期的一个要求是多客户端能力。然而后来确定更好的方法是确保该协议能够轻松扩展到多客户端场景。流标识符可以被多个控制流使用因此可以实现‘传递遥控器’的功能。该协议不解决多个客户端如何协商访问的问题这留给‘社交协议’或其他控制机制来处理。 扩展 RTSP 由于并非所有媒体服务器都具有相同的功能媒体服务器必然会支持不同的请求集。例如 1、服务器可能只具备播放功能因此无需支持 RECORD 请求。 2、如果服务器只支持直播事件它可能无法进行寻址绝对定位。 3、有些服务器可能不支持设置流参数因此不支持 GET_PARAMETER 和 SET_PARAMETER 请求。 服务器应该实现第12节中描述的所有头字段。 呈现描述的创建者应避免向服务器提出不可能实现的要求。这种情况类似于 HTTP/1.1 [2]其中 [H19.6] 中描述的方法不太可能被所有服务器支持。 RTSP 可以通过三种方式扩展这些方式按所支持的更改幅度排列如下 1、现有方法可以通过新参数进行扩展只要接收方能够安全地忽略这些参数。这相当于向 HTML 标签添加新参数。如果客户端在方法扩展不被支持时需要负面确认则可以在 Require: 字段中添加对应于该扩展的标签参见第12.32节。 2、可以添加新方法。如果消息的接收方不理解请求它会返回错误代码 501未实现并且发送方不应再次尝试使用此方法。客户端还可以使用 OPTIONS 方法查询服务器支持的方法。服务器应使用 Public 响应头列出其支持的方法。 3、可以定义协议的新版本允许几乎所有方面发生变化除了协议版本号的位置。 整体操作 每个展示和媒体流都可以通过一个 RTSP URL 进行标识。展示的整体内容以及构成展示的媒体属性由展示描述文件定义其格式超出了本规范的范围。展示描述文件可以通过客户端使用 HTTP 或其他方式如电子邮件获取并不一定存储在媒体服务器上。 根据本规范的要求假设展示描述描述了一个或多个展示每个展示都有一个共同的时间轴。为简化说明且不失一般性假设展示描述只包含一个这样的展示。一个展示可以包含多个媒体流。 展示描述文件包含构成展示的媒体流的描述包括其编码、语言以及其他参数使客户端能够选择最合适的媒体组合。在这个展示描述中每个可通过 RTSP 单独控制的媒体流都通过一个 RTSP URL 进行标识该 URL 指向处理该特定媒体流的媒体服务器并命名存储在该服务器上的流。多个媒体流可以位于不同的服务器上例如音频和视频流可以分布在不同的服务器上以实现负载共享。描述还列举了服务器支持的传输方法。 除了媒体参数之外还需要确定网络目标地址和端口。可以区分几种操作模式 1、 单播媒体传输到 RTSP 请求的来源端口号由客户端选择。或者媒体通过与 RTSP 相同的可靠流进行传输。 2、 多播服务器选择地址媒体服务器选择多播地址和端口。这是直播或准点播传输的典型情况。 3、 多播客户端选择地址如果服务器要参与一个已存在的多播会议会议描述将提供多播地址、端口和加密密钥这些是通过本规范范围之外的方法建立的 。 RTSP 状态 RTSP 控制的流可以通过一个独立于控制通道的协议传输。例如RTSP 控制可以通过 TCP 连接进行而数据通过 UDP 传输。因此即使媒体服务器未收到 RTSP 请求数据传输仍然会继续。此外在其生命周期内单个媒体流可以通过依次在不同的 TCP 连接上发出的 RTSP 请求进行控制。因此服务器需要维护‘会话状态’以便将 RTSP 请求与流关联。状态转换在第 A 节中描述。 许多 RTSP 方法不影响状态。然而以下方法在定义服务器上流资源的分配和使用方面起着核心作用SETUP、PLAY、RECORD、PAUSE 和 TEARDOWN 1、SETUP: 使服务器为流分配资源并启动 RTSP 会话 . 2、PLAY and RECORD: 启动通过 SETUP 分配的流的数据传输。 3、PAUSE: 暂时停止流的传输但不释放服务器资源。 4、TEARDOWN: 释放与该流相关的资源。RTSP 会话在服务器上终止。 影响状态的 RTSP 方法使用 Session 头字段第 12.37 节来标识正在操作状态的 RTSP 会话。服务器在响应 SETUP 请求时生成会话标识符第 10.4 节。 与其他协议的关系 RTSP 在功能上与 HTTP 有一定的重叠。它也可能与 HTTP 交互因为对流媒体内容的初始访问通常通过网页进行。当前的协议规范旨在允许在实现 RTSP 的网络服务器和媒体服务器之间设置不同的交接点。例如展示描述可以通过 HTTP 或 RTSP 获取这减少了基于网页浏览器场景中的往返次数同时也支持独立的 RTSP 服务器和客户端完全不依赖于 HTTP。 然而RTSP 与 HTTP 在本质上有所不同因为数据传输是在带外通过不同的协议进行的。HTTP 是一个非对称协议客户端发出请求服务器响应。而在 RTSP 中媒体客户端和媒体服务器都可以发出请求。RTSP 请求也不是无状态的它们可以设置参数并在请求被确认后继续控制媒体流。 重用 HTTP 功能在至少两个方面具有优势分别是安全性和代理。这两者的需求非常相似因此能够采用 HTTP 在缓存、代理和身份验证方面的工作是非常有价值的。 虽然大多数实时媒体会使用 RTP 作为传输协议但 RTSP 并不依赖于 RTP。RTSP 假设存在一种展示描述格式能够表达包含多个媒体流的展示的静态和时间属性。 协议参数 RTSP Version [H3.1] 适用将 HTTP 替换为 RTSP。 RTSP URL rtsp 和 rtspu 方案用于通过 RTSP 协议引用网络资源。本节定义了 RTSP URL 的特定方案语法和语义 rtsp_URL ( rtsp: | rtspu: )// host [ : port ] [ abs_path ]host A legal Internet host domain name of IP address(in dotted decimal form), as defined by Section 2.1of RFC 1123 \cite{rfc1123}port *DIGIT abs_path 定义于 [H3.2.1]。 请注意片段和查询标识符目前没有明确定义其解释留给 RTSP 服务器处理。 rtsp 方案要求通过可靠的协议在互联网中为 TCP发出命令而 rtspu 方案标识使用不可靠的协议在互联网中为 UDP。 如果端口为空或未指定则假定为端口 554。语义是所标识的资源可以通过 RTSP 进行控制服务器在主机的该端口上监听 TCPrtsp 方案连接或 UDPrtspu 方案数据包该资源的 Request-URI 为 rtsp_URL。 应尽可能避免在 URL 中使用 IP 地址参见 RFC 1924 [19]。 展示或流通过文本媒体标识符进行标识使用 URL 的字符集和转义约定 [H3.2]RFC 1738 [20]。URL 可以引用一个流或多个流的集合即展示。因此第10节中描述的请求可以应用于整个展示或展示中的单个流。请注意有些请求方法只能应用于流不能应用于展示反之亦然。 例如RTSP URL rtsp://media.example.com:554/twister/audiotrack 标识展示 twister 中的音频流该流可以通过向主机 media.example.com 的 554 端口发出的 RTSP 请求进行控制RTSP 请求通过 TCP 连接发送。 同样RTSP URL rtsp://media.example.com:554/twister 标识展示 twister该展示可能由音频和视频流组成。 这并不意味着存在一种标准方式来通过 URL 引用流。展示描述定义了展示中的层次关系以及各个流的 URL。展示描述可能将一个流命名为 a.mov而将整个展示命名为 b.mov。 RTSP URL 的路径部分对客户端是不可见的并且不暗示服务器有任何特定的文件系统结构。这种解耦还允许通过简单地替换 URL 中的方案将展示描述用于非 RTSP 媒体控制协议。 会议标识符 会议标识符对 RTSP 是不可见的并使用标准 URI 编码方法进行编码即LWS 使用 % 进行转义。它们可以包含任何八位字节值。会议标识符必须是全局唯一的。对于 H.323应使用 conferenceID 值。 conference-id 1*xchar 会议标识符用于允许 RTSP 会话从媒体服务器参与的多媒体会议中获取参数。这些会议由本规范范围之外的协议创建例如 H.323 [13] 或 SIP [12]。例如RTSP 客户端不需要明确提供传输信息而是请求媒体服务器使用会议描述中的值。 会话标识符: 会话标识符是具有任意长度的不透明字符串。线性空格必须进行 URL 转义。会话标识符必须随机选择并且长度必须至少为八个八位字节以增加猜测的难度。参见第 16 节。 session-id 1*( ALPHA | DIGIT | safe ) SMPTE 相对时间戳: SMPTE 相对时间戳表示相对于剪辑开始的时间。相对时间戳以 SMPTE 时间码表示以实现帧级访问精度。时间码的格式为 小时:分钟:秒:帧.子帧起点为剪辑的开头。默认的 SMPTE 格式为 SMPTE 30 drop 格式帧率为 29.97 帧每秒。其他 SMPTE 码例如 SMPTE 25可以通过使用其他 SMPTE 时间 支持。时间值中的 frames 字段可以取值 0 到 29。30 帧每秒与 29.97 帧每秒之间的差异通过在每分钟的前两帧索引值为 00 和 01丢弃来处理除了每第十分钟。如果帧值为零可以省略。子帧以帧的百分之一测量。 正常播放时间: 正常播放时间 (NPT) 表示流相对于展示开头的绝对位置。时间戳由小数部分组成。小数点左边的部分可以用秒或小时、分钟和秒表示。小数点右边的部分表示秒的小数部分。 展示的开始对应于 0.0 秒。不定义负值。特殊常量 now 表示直播事件的当前时刻仅可用于直播事件。 NPT 的定义与 DSM-CC 中相同直观上NPT 是观看者与节目相关联的时钟。它通常会在录像机上以数字形式显示。当处于正常播放模式比例 1时NPT 正常前进当快速向前扫描时NPT 以更快的速率前进高正比例当反向扫描时NPT 减少高负比例暂停模式下NPT 固定不动。NPT 在逻辑上相当于 SMPTE 时间码。 [5] 该语法符合 ISO 8601 标准。npt-sec 记法优化用于自动生成npt-hhmmss 记法则便于人类阅读。now 常量允许客户端请求接收直播内容而非存储或延迟播放的版本。这是必要的因为对于这种情况绝对时间或零时间都不合适。 绝对时间: 绝对时间以 ISO 8601 时间戳表示使用协调世界时 (UTC)格林尼治标准时间。可以表示秒的小数部分.
