Real-Time Streaming Protocol (RTSP) Version 2.0

需积分: 10 83 浏览量更新于2024-07-20 收藏 964KB PDF 举报

"RTSP V2.0 文档" 本文档定义了实时流协议（RTSP）的第2.0版，它是一种应用层协议，用于建立和控制具有实时特性的数据传输，通常是指流媒体。流媒体包括点播视频或直播音频。简单来说，RTSP充当多媒体服务器的“网络远程控制器”。 RTSP 2.0取代了之前在RFC2326中定义的RTSP 1.0版本。这个新版本旨在提供一个可扩展的框架，以便实现受控的按需传输实时数据，如音频和视频。数据源可以是实时数据馈送或存储的剪辑。该协议设计用于控制多个数据传输会话，并提供了选择交付通道的能力，如UDP、多播UDP和TCP，以及基于RTP（RFC3550）的传输机制。 RTSP 2.0的核心功能包括： 1. **会话管理**：RTSP允许客户端与服务器之间建立和管理流媒体会话，包括播放、暂停、快进、快退和停止等操作。 2. **通道选择**：支持多种传输协议，如用户数据报协议（UDP）、多播UDP和传输控制协议（TCP），以适应不同的网络环境和需求。 3. **RTP兼容性**：RTSP通常与RTP一起使用，为数据传输提供同步和错误恢复机制，确保流媒体的质量和可靠性。 4. **扩展性**：RTSP 2.0的设计考虑了未来扩展，可以通过添加新的请求方法、响应代码、头字段和参数来适应新技术和应用场景。 5. **控制功能**：RTSP提供了对服务器上媒体源的精细控制，包括选择不同的轨道、调整播放速率、进行时间跳跃等。 6. **安全性**：虽然文档中没有详细说明，但作为标准协议，RTSP 2.0可能也考虑了安全措施，如加密和身份验证，以保护内容和用户隐私。 RTSP 2.0的标准化进程表明，这个协议已经成为互联网工程任务组（IETF）的互联网标准轨道文档。这代表了广泛的认可和对协议稳定性的信心。然而，此文档还涵盖了RTSP的更新、改进和可能的兼容性问题，这些问题需要在实际应用中仔细考虑和解决。 RTSP 2.0是一个强大的工具，用于管理和控制实时流媒体服务，其设计目标是提高灵活性、可靠性和用户体验。通过定义清晰的操作命令和接口，它为开发高效、适应性强的流媒体系统提供了基础。随着技术的发展，RTSP 2.0将继续扮演着流媒体领域的重要角色。

RFC 7826

RTSP 2.0 December 2016

example, clients needing to know the current media range for a time-

progressing session can use the GET_PARAMETER method and include the

media range. Furthermore, synchronization information can be

requested by using a combination of RTP-Info (

Section 18.45) and

Range (

Section 18.40).

RTSP 2.0 does not have a strong mechanism for negotiating the headers

or parameters and their formats. However, responses will indicate

request-headers or parameters that are not supported. A priori

determination of what features are available needs to be done through

out-of-band mechanisms, like the session description, or through the

usage of feature tags (

Section 4.5).

2.5. Media Delivery

This document specifies how media is delivered with RTP [

RFC3550]

over UDP [

RFC768], TCP [RFC793], or the RTSP connection. Additional

protocols may be specified in the future as needed.

The usage of RTP as a media delivery protocol requires some

additional information to function well. The PLAY response contains

information to enable reliable and timely delivery of how a client

should synchronize different sources in the different RTP sessions.

It also provides a mapping between RTP timestamps and the content-

time scale. When the server wants to notify the client about the

completion of the media delivery, it sends a PLAY_NOTIFY request to

the client. The PLAY_NOTIFY request includes information about the

stream end, including the last RTP sequence number for each stream,

thus enabling the client to empty the buffer smoothly.

2.5.1. Media Delivery Manipulations

The basic playback functionality of RTSP enables delivery of a range

of requested content to the client at the pace intended by the

content’s creator. However, RTSP can also manipulate the delivery to

the client in two ways.

Scale: The ratio of media-content time delivered per unit of

playback time.

Speed: The ratio of playback time delivered per unit of wallclock

time.

Both affect the media delivery per time unit. However, they

manipulate two independent timescales and the effects are possible to

combine.

Schulzrinne, et al. Standards Track [Page 16]

RFC 7826

RTSP 2.0 December 2016

Scale (

Section 18.46) is used for fast-forward or slow-motion control

as it changes the amount of content timescale that should be played

back per time unit. Scale > 1.0, means fast forward, e.g., scale =

2.0 results in that 2 seconds of content being played back every

second of playback. Scale = 1.0 is the default value that is used if

no scale is specified, i.e., playback at the content’s original rate.

Scale values between 0 and 1.0 provide for slow motion. Scale can be

negative to allow for reverse playback in either regular pace

(scale = -1.0), fast backwards (scale < -1.0), or slow-motion

backwards (-1.0 < scale < 0). Scale = 0 would be equal to pause and

is not allowed.

In most cases, the realization of scale means server-side

manipulation of the media to ensure that the client can actually play

it back. The nature of these media manipulations and when they are

needed is highly media-type dependent. Let’s consider two common

media types, audio and video.

It is very difficult to modify the playback rate of audio.

Typically, no more than a factor of two is possible while maintaining

intelligibility by changing the pitch and rate of speech. Music goes

out of tune if one tries to manipulate the playback rate by

resampling it. This is a well-known problem, and audio is commonly

muted or played back in short segments with skips to keep up with the

current playback point.

For video, it is possible to manipulate the frame rate, although the

rendering capabilities are often limited to certain frame rates.

Also, the allowed bitrates in decoding, the structure used in the

encoding, and the dependency between frames and other capabilities of

the rendering device limits the possible manipulations. Therefore,

the basic fast-forward capabilities often are implemented by

selecting certain subsets of frames.

Due to the media restrictions, the possible scale values are commonly

restricted to the set of realizable scale ratios. To enable the

clients to select from the possible scale values, RTSP can signal the

supported scale ratios for the content. To support aggregated or

dynamic content, where this may change during the ongoing session and

dependent on the location within the content, a mechanism for

updating the media properties and the scale factor currently in use,

exists.

Speed (

Section 18.50) affects how much of the playback timeline is

delivered in a given wallclock period. The default is Speed = 1

which means to deliver at the same rate the media is consumed.

Speed > 1 means that the receiver will get content faster than it

regularly would consume it. Speed < 1 means that delivery is slower

Schulzrinne, et al. Standards Track [Page 17]

RFC 7826

RTSP 2.0 December 2016

than the regular media rate. Speed values of 0 or lower have no

meaning and are not allowed. This mechanism enables two general

functionalities. One is client-side scale operations, i.e., the

client receives all the frames and makes the adjustment to the

playback locally. The second is delivery control for the buffering

of media. By specifying a speed over 1.0, the client can build up

the amount of playback time it has present in its buffers to a level

that is sufficient for its needs.

A naive implementation of Speed would only affect the transmission

schedule of the media and has a clear impact on the needed bandwidth.

This would result in the data rate being proportional to the speed

factor. Speed = 1.5, i.e., 50% faster than normal delivery, would

result in a 50% increase in the data-transport rate. Whether or not

that can be supported depends solely on the underlying network path.

Scale may also have some impact on the required bandwidth due to the

manipulation of the content in the new playback schedule. An example

is fast forward where only the independently decodable intra-frames

are included in the media stream. This usage of solely intra-frames

increases the data rate significantly compared to a normal sequence

with the same number of frames, where most frames are encoded using

prediction.

This potential increase of the data rate needs to be handled by the

media sender. The client has requested that the media be delivered

in a specific way, which should be honored. However, the media

sender cannot ignore if the network path between the sender and the

receiver can’t handle the resulting media stream. In that case, the

media stream needs to be adapted to fit the available resources of

the path. This can result in a reduced media quality.

The need for bitrate adaptation becomes especially problematic in

connection with the Speed semantics. If the goal is to fill up the

buffer, the client may not want to do that at the cost of reduced

quality. If the client wants to make local playout changes, then it

may actually require that the requested speed be honored. To resolve

this issue, Speed uses a range so that both cases can be supported.

The server is requested to use the highest possible speed value

within the range, which is compatible with the available bandwidth.

As long as the server can maintain a speed value within the range, it

shall not change the media quality, but instead modify the actual

delivery rate in response to available bandwidth and reflect this in

the Speed value in the response. However, if this is not possible,

the server should instead modify the media quality to respect the

lowest speed value and the available bandwidth.

Schulzrinne, et al. Standards Track [Page 18]

RFC 7826

RTSP 2.0 December 2016

This functionality enables the local scaling implementation to use a

tight range, or even a range where the lower bound equals the upper

bound, to identify that it requires the server to deliver the

requested amount of media time per delivery time, independent of how

much it needs to adapt the media quality to fit within the available

path bandwidth. For buffer filling, it is suitable to use a range

with a reasonable span and with a lower bound at the nominal media

rate 1.0, such as 1.0 - 2.5. If the client wants to reduce the

buffer, it can specify an upper bound that is below 1.0 to force the

server to deliver slower than the nominal media rate.

2.6. Session Maintenance and Termination

The session context that has been established is kept alive by having

the client show liveness. This is done in two main ways:

o Media-transport protocol keep-alive. RTP Control Protocol (RTCP)

may be used when using RTP.

o Any RTSP request referencing the session context.

Section 10.5 discusses the methods for showing liveness in more

depth. If the client fails to show liveness for more than the

established session timeout value (normally 60 seconds), the server

may terminate the context. Other values may be selected by the

server through the inclusion of the timeout parameter in the session

header.

The session context is normally terminated by the client sending a

TEARDOWN request (

Section 13.7) to the server referencing the

aggregated control URI. An individual media resource can be removed

from a session context by a TEARDOWN request referencing that

particular media resource. If all media resources are removed from a

session context, the session context is terminated.

A client may keep the session alive indefinitely if allowed by the

server; however, a client is advised to release the session context

when an extended period of time without media delivery activity has

passed. The client can re-establish the session context if required

later. What constitutes an extended period of time is dependent on

the client, server, and their usage. It is recommended that the

client terminate the session before ten times the session timeout

value has passed. A server may terminate the session after one

session timeout period without any client activity beyond keep-alive.

When a server terminates the session context, it does so by sending a

TEARDOWN request indicating the reason.

Schulzrinne, et al. Standards Track [Page 19]

RFC 7826

RTSP 2.0 December 2016

A server can also request that the client tear down the session and

re-establish it at an alternative server, as may be needed for

maintenance. This is done by using the REDIRECT method

(

Section 13.10). The Terminate-Reason header (Section 18.52) is used

to indicate when and why. The Location header indicates where it

should connect if there is an alternative server available. When the

deadline expires, the server simply stops providing the service. To

achieve a clean closure, the client needs to initiate session

termination prior to the deadline. In case the server has no other

server to redirect to, and it wants to close the session for

maintenance, it shall use the TEARDOWN method with a Terminate-Reason

header.

2.7. Extending RTSP

RTSP is quite a versatile protocol that supports extensions in many

different directions. Even this core specification contains several

blocks of functionality that are optional to implement. The use case

and need for the protocol deployment should determine what parts are

implemented. Allowing for extensions makes it possible for RTSP to

address additional use cases. However, extensions will affect the

interoperability of the protocol; therefore, it is important that

they can be added in a structured way.

The client can learn the capability of a server by using the OPTIONS

method (

Section 13.1) and the Supported header (Section 18.51). It

can also try and possibly fail using new methods or require that

particular features be supported using the Require (

Section 18.43) or

Proxy-Require (

Section 18.37) header.

The RTSP, in itself, can be extended in three ways, listed here in

increasing order of the magnitude of changes supported:

o Existing methods can be extended with new parameters, for example,

headers, as long as these parameters can be safely ignored by the

recipient. If the client needs negative acknowledgment when a

method extension is not supported, a tag corresponding to the

extension may be added in the field of the Require or Proxy-

Require headers.

o New methods can be added. If the recipient of the message does

not understand the request, it must respond with error code 501

(Not Implemented) so that the sender can avoid using this method

again. A client may also use the OPTIONS method to inquire about

methods supported by the server. The server must list the methods

it supports using the Public response-header.

Schulzrinne, et al. Standards Track [Page 20]

剩余317页未读，继续阅读

Robert_NORM

粉丝: 2
资源: 29

Real-Time Streaming Protocol (RTSP) Version 2.0

RTSPv2_CHS:Real-Time Streaming Protocol Version 2.0 中文翻译项目

网络rtsp直播视频播放器

RTSPPLAYER.zip

RFC for RTSP V1.0 Document

RTSP 2.0 协议 PDF 带书签

FFMPEG/OpenCV实现RTSP码流解码显示的程序V2.0(可工程应用)

onvif spec v2.0

RTSP协议版本2.0详解

ZLMediaKit运营级流媒体服务框架 v2.0.zip

多媒体控件MMTools.Combo.Pro.v2.0.Full.Source

最新资源