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

示例：

C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/1.0

CSeq: 834

Session: 12345678

S->C: RTSP/1.0 200 OK

CSeq: 834

Date: 23 Jan 1997 15:35:06 GMT

PAUSE 请求中可能包含一个Range首部域用来指定何时媒体流或表示暂停，我们称这个时刻为暂停点（pause point）。该首部域必须包含一个精确的，而不是一个时间范围。媒体流的正常播放时间设置成暂停点。当服务器遇到在任何当前挂起（pending）的 PLAY请求中指定的时间点后，暂停请求生效。如果Range首部域指定了一个时间超出了任何一个当前挂起的PLAY请求，将返回错误"457 Invalid Range" 。如果一个媒体单元（比如一个音频或视频禎）正好在一个暂停点开始，那么表示将不会被播放或记录。如果Range首部域缺失，那么在收到暂停消息后媒体流 传输立即中断，并且暂停点设置成当前正常播放时间。

利用PAUSE请求可忽视所有排队的PLAY请求，但必须维护媒体流中的暂停点。不带Range首部域的后继PLAY请求从暂停点重启播放。

比如，如果服务器有两个挂起的播放请求，播放范围（range）分别是10到15和20到29，这时收到一个暂停请求，暂停点是NPT21，那么它将会开 始播放第二个范围，并且在NPT21处停止。如果服务器正在服务第一个请求播放到NPT13位置，收到暂停请求，暂停点NPT12，那么它将立即停止。如 果请求在NPT16暂停，那么服务器在完成第一个播放请求后停止，放弃了第二个播放请求。

再如，服务器收到播放请求，播放范围从10到 15和13到20（即之间有重叠），PAUSE暂停点是NPT14，则当服务器播放第一段范围时，PAUSE 请求将生效，而第二个PLAY请求会被忽略重叠部分，就好像服务器在开始播放第二段前收到PAUSE请求。不管PAUSE请求何时到达，它总是设置NPT 到14。//？

如果服务器已经在Range首部域指定的时间外发送了数据，后继的PLAY仍会在暂停点及时重启，因为它认为客户端会丢弃在暂停点后收到的数据。这就确保了连续、无隙的暂停/播放循环。

10.7 TEARDOWN

TEARDOWN请求终止了给定URI的媒体流传输，并释放了与该媒体流相关的资源。如果该URI是对此表示的表示URI，那么任何与此会话相关的任何RTSP会话标志符将不再有效。除非所有传输参数由会话描述符定义，否则SETUP请求必须在会话能被再次播放之前发出。

示例：

C->S: TEARDOWN rtsp://example.com/fizzle/foo RTSP/1.0

CSeq: 892

Session: 12345678

S->C: RTSP/1.0 200 OK

CSeq: 892

10.8 GET PARAMETER

GET PARAMETER请求检索URI指定的表示或媒体流的参数。答复和响应的内容留给了实现。不带实体主体的GET PARAMETER可用来测试客户端或服务器是否存活（"Ping"）。

示例：

S->C: GET_PARAMETER rtsp://example.com/fizzle/foo RTSP/1.0

CSeq: 431

Content-Type: text/parameters

Session: 12345678

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