RTSP协议详解：实时流控制与传输

需积分: 7 107 浏览量更新于2024-07-20 收藏 249KB PDF 举报

"RTSP V1.0的文档RFC详细阐述了实时流协议（Real Time Streaming Protocol）的应用层控制机制，旨在实现具有实时特性的数据流的受控、按需交付，包括音频和视频等。RTSP适用于直播数据源和存储片段，并能管理多个数据传输会话，支持UDP、多播UDP和TCP等多种传输通道，以及基于RTP的交付机制。" 《RealTimeStreamingProtocol (RTSP)》是互联网标准轨道协议，由H.Schulzrinne、A.Rao和R.Lanphier等人于1998年发布。该文档定义了一个用于控制实时属性数据传输的应用级协议，其目的是提供一个可扩展的框架，使用户能够控制并按需提供实时数据，如音频和视频流。数据源可以包括实时数据流和已存储的媒体片段。 RTSP的核心功能包括： 1. **多会话管理**：RTSP允许同时控制多个数据传输会话，这意味着用户可以同时播放不同的媒体流，例如在一个设备上观看直播赛事，同时在另一窗口听音乐。 2. **传输通道选择**：协议支持不同类型的传输通道，包括用户数据报协议（UDP）、多播UDP和传输控制协议（TCP）。UDP通常用于低延迟但可能不那么可靠的数据传输，而TCP则确保数据包的顺序和无损传输，适合对数据完整性要求较高的情况。 3. **RTP支持**：实时传输协议（RTP）与RTSP紧密配合，用于承载实时数据，如音频和视频流。RTP提供了时间戳和序列号，确保媒体数据的同步和正确排序。 4. **控制与交互**：RTSP提供了一套命令集，如`PLAY`、`PAUSE`、`STOP`和`TELEPORT`，使得用户可以控制流的播放、暂停、停止以及快进或快退等操作。 5. **扩展性**：RTSP的设计考虑到了未来扩展，允许通过添加新的指令和选项来适应新的功能和需求。 6. **安全性与QoS**：虽然RTSP本身不直接处理安全性和服务质量（QoS），但它可以与其他机制（如SSL/TLS进行加密，或者与DiffServ或RSVP协作以确保QoS）结合使用，以满足安全和性能要求。 7. **应用范围**：RTSP适用于多种场景，包括在线视频会议、远程教育、在线直播、IP电视等，这些都需要高效、实时的多媒体数据传输。 RTSP的实施和使用不仅限于特定的硬件或软件平台，它被广泛应用于各种设备和系统中，促进了互联网上的多媒体内容的广泛传播和消费。随着技术的发展，RTSP也在不断演进，以适应新的挑战和需求，如适应移动设备的优化、支持更高分辨率的视频流等。

RFC 2326

Real Time Streaming Protocol April 1998

RFC 1123 \cite{rfc1123}>

port = *DIGIT

abs_path is defined in [H3.2.1].

Note that fragment and query identifiers do not have a well-defined

meaning at this time, with the interpretation left to the RTSP

server.

The scheme rtsp requires that commands are issued via a reliable

protocol (within the Internet, TCP), while the scheme rtspu identifies

an unreliable protocol (within the Internet, UDP).

If the port is empty or not given, port 554 is assumed. The semantics

are that the identified resource can be controlled by RTSP at the

server listening for TCP (scheme "rtsp") connections or UDP (scheme

"rtspu") packets on that port of host, and the Request-URI for the

resource is rtsp_URL.

The use of IP addresses in URLs SHOULD be avoided whenever possible

(see RFC 1924 [19]).

A presentation or a stream is identified by a textual media

identifier, using the character set and escape conventions [H3.2] of

URLs (

RFC 1738 [20]). URLs may refer to a stream or an aggregate of

streams, i.e., a presentation. Accordingly, requests described in

Section 10 can apply to either the whole presentation or an individual

stream within the presentation. Note that some request methods can

only be applied to streams, not presentations and vice versa.

For example, the RTSP URL:

rtsp://media.example.com:554/twister/audiotrack

identifies the audio stream within the presentation "twister", which

can be controlled via RTSP requests issued over a TCP connection to

port 554 of host media.example.com.

Also, the RTSP URL:

rtsp://media.example.com:554/twister

identifies the presentation "twister", which may be composed of

audio and video streams.

This does not imply a standard way to reference streams in URLs.

The presentation description defines the hierarchical relationships

in the presentation and the URLs for the individual streams. A

presentation description may name a stream "a.mov" and the whole

presentation "b.mov".

Schulzrinne, et. al. Standards Track [Page 15]

RFC 2326

Real Time Streaming Protocol April 1998

The path components of the RTSP URL are opaque to the client and do

not imply any particular file system structure for the server.

This decoupling also allows presentation descriptions to be used

with non-RTSP media control protocols simply by replacing the

scheme in the URL.

3.3 Conference Identifiers

Conference identifiers are opaque to RTSP and are encoded using

standard URI encoding methods (i.e., LWS is escaped with %). They can

contain any octet value. The conference identifier MUST be globally

unique. For H.323, the conferenceID value is to be used.

conference-id = 1*xchar

Conference identifiers are used to allow RTSP sessions to obtain

parameters from multimedia conferences the media server is

participating in. These conferences are created by protocols

outside the scope of this specification, e.g., H.323 [13] or SIP

[12]. Instead of the RTSP client explicitly providing transport

information, for example, it asks the media server to use the

values in the conference description instead.

3.4 Session Identifiers

Session identifiers are opaque strings of arbitrary length. Linear

white space must be URL-escaped. A session identifier MUST be chosen

randomly and MUST be at least eight octets long to make guessing it

more difficult. (See

Section 16.)

session-id = 1*( ALPHA | DIGIT | safe )

3.5 SMPTE Relative Timestamps

A SMPTE relative timestamp expresses time relative to the start of

the clip. Relative timestamps are expressed as SMPTE time codes for

frame-level access accuracy. The time code has the format

hours:minutes:seconds:frames.subframes, with the origin at the start

of the clip. The default smpte format is "SMPTE 30 drop" format, with

frame rate is 29.97 frames per second. Other SMPTE codes MAY be

supported (such as "SMPTE 25") through the use of alternative use of

"smpte time". For the "frames" field in the time value can assume

the values 0 through 29. The difference between 30 and 29.97 frames

per second is handled by dropping the first two frame indices (values

00 and 01) of every minute, except every tenth minute. If the frame

value is zero, it may be omitted. Subframes are measured in

one-hundredth of a frame.

Schulzrinne, et. al. Standards Track [Page 16]

RFC 2326

Real Time Streaming Protocol April 1998

smpte-range = smpte-type "=" smpte-time "-" [ smpte-time ]

smpte-type = "smpte" | "smpte-30-drop" | "smpte-25"

; other timecodes may be added

smpte-time = 1*2DIGIT ":" 1*2DIGIT ":" 1*2DIGIT [ ":" 1*2DIGIT ]

[ "." 1*2DIGIT ]

Examples:

smpte=10:12:33:20-

smpte=10:07:33-

smpte=10:07:00-10:07:33:05.01

smpte-25=10:07:00-10:07:33:05.01

3.6 Normal Play Time

Normal play time (NPT) indicates the stream absolute position

relative to the beginning of the presentation. The timestamp consists

of a decimal fraction. The part left of the decimal may be expressed

in either seconds or hours, minutes, and seconds. The part right of

the decimal point measures fractions of a second.

The beginning of a presentation corresponds to 0.0 seconds. Negative

values are not defined. The special constant now is defined as the

current instant of a live event. It may be used only for live events.

NPT is defined as in DSM-CC: "Intuitively, NPT is the clock the

viewer associates with a program. It is often digitally displayed on

a VCR. NPT advances normally when in normal play mode (scale = 1),

advances at a faster rate when in fast scan forward (high positive

scale ratio), decrements when in scan reverse (high negative scale

ratio) and is fixed in pause mode. NPT is (logically) equivalent to

SMPTE time codes." [5]

npt-range = ( npt-time "-" [ npt-time ] ) | ( "-" npt-time )

npt-time = "now" | npt-sec | npt-hhmmss

npt-sec = 1*DIGIT [ "." *DIGIT ]

npt-hhmmss = npt-hh ":" npt-mm ":" npt-ss [ "." *DIGIT ]

npt-hh = 1*DIGIT ; any positive number

npt-mm = 1*2DIGIT ; 0-59

npt-ss = 1*2DIGIT ; 0-59

Examples:

npt=123.45-125

npt=12:05:35.3-

npt=now-

The syntax conforms to ISO 8601. The npt-sec notation is optimized

for automatic generation, the ntp-hhmmss notation for consumption

by human readers. The "now" constant allows clients to request to

Schulzrinne, et. al. Standards Track [Page 17]

剩余91页未读，继续阅读

Robert_NORM

粉丝: 2
资源: 29

RTSP协议详解：实时流控制与传输

HIKVISION RTSP IPMD V1.0

rfc1945中文 HTTP1.0

rfc2326.doc（RTSP1.0）

http-status-codes:枚举HTTP状态代码的常量。 支持RFC1945（HTTP1.0，RFC2616（HTTP1.1）和RFC2518（WebDAV）中定义的所有状态代码

rfc 2326 rtsp

RTSP.rar_Rtsp 服务器端源程序_rfc_rtsp

rfc 2326 rtsp 协议 中文版带目录

RFC 2326 rtsp 中文版（前11章）

RFC5280_中文版_个人翻译v1.0

MS - RTSP Protocol Version 1.0

最新资源

http-status-codes:枚举HTTP状态代码的常量。支持RFC1945（HTTP1.0，RFC2616（HTTP1.1）和RFC2518（WebDAV）中定义的所有状态代码

rfc 2326 rtsp 协议中文版带目录