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

PAUSEReady

TEARDOWN Init

SETUPPlaying

RecordingRECORDRecording

PAUSEReady

TEARDOWN Init

SETUPRecording

附录B：同RTP交互

RTSP允许媒体客户端控制媒体表示中选择出的非连续片段，表现为RTP媒体层[24]的流。表现为RTP流的媒体层不应该受NPT时间的跳跃的影响。因此，RTP序列号和RTP时间戳在跨越NPT时间跳跃时都【必须】是连续且单调递增的。

例如，假设时钟频率是8000Hz，包之间的时间间隔是100毫秒，初始序列号和时间戳都是0。我们首先播放NPT 10到NPT 15，然后向前跳播放NPT 18到NPT 20。第一个片段在RTP包上表现为序列号从0到49，时间戳从0到39，200。第二个片段则表现为序列号从50到69，时间戳从40，000到55，200。

我们不能假定RTSP客户端可以与RTP媒体agent通信，因为这可能是两个独立的进程。如果RTP时间戳的时间间隔和NPT一样，媒体agent将假设表示有暂停。如果NPT时间跳跃足够大，RTP时间戳可能会到达上限而从头开始，这样媒体agent可能会认为之后的包跟之前已播放的包重复了。

对于某些数据类型，RTSP层和RTP层之间的紧密整合是有必要的。这完全不能排除上文所述的限制。RTSP/RTP组合媒体客户端应该用RTP-Info域来判断要来的RTP包是在搜索之前还是之后发的。

对于连续音频，服务器【应该】在服务于新PLAY请求之始就设置RTP标志位。这使客户端可以进行播放延迟调整。

对于倍速改变（12.34节），RTP时间戳应该和回放计时一致。例如，当以两倍速、speed为1播放30帧/秒的视频记录，服务器应该每两帧丢弃一帧以维持用间隔为3000每帧的正常时间戳传送视频流，但是NPT每一视频帧增加1/15秒。

客户端可以通过通知位置重设后的第一个包的RTP时间戳，来维护正确NPT的播放。RTP-info（12.33）头部的sequence参数提供下个片段的首个序列号。

附录C：用SDP描述RTSP会话

会话描述协议（SDP,RFC 2327 [6]）可能会RTSP被用于描述流或表示。这类使用被限制在以下几个方面，用于给出访问方式和编码：

合控制：

不能够合控制的由来自于一个或多个服务器多个流组成的表示。这类描述通常由其他途径得来，以HTTP为典型。不它们也可以通过ANNOUNCE方法接收。

非合控制：

C.1 定义

该附件使用的词条"会话级别", "媒体级别"和其他键/属性名及的定义在SDP（RFC2327[6]中：

C.1.1 控制URL

“a=control”属性用来传送控制RUL。该属性可用在会话和媒体描述上。；如果用于单个媒体，它指示用来控制那个特定媒体流的URL。如果用在会话级别，该属性指示合控制的URL。

例子：

a=control:rtsp://example.com/foo

该属性可能包含相对或者绝对URL，遵循RFC 1808 [25]的规则和习惯。实现应该按以下顺序寻找基URL：

1.RTSP Content-Base 域

2.RTSP Content-Location 域

3.RTSP 请求 URL

如果此属性只包含星号（*）,则URL被以空内嵌UL对待，因此继承整个基URL。

C.1.2 媒体－流

"m="被用来列举流。它期望所有列举出的流都将有合适的同步处理。如果会话是单播，端口号则是服务器对客户端的推荐；客户端在SETUP中还是应该在包括它并有可能忽略此推荐。如果服务器没有偏好，它【应该】把端口号置零。

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