RTSP协议详解

最新推荐文章于 2024-01-12 22:21:41 发布
最新推荐文章于 2024-01-12 22:21:41 发布
阅读量4k 收藏 1
点赞数
分类专栏： RTSP
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/weixin_39736022/article/details/117307622
版权

RTSP协议详解

文章目录

前言

RTSP为流媒体技术的基础常识，初次学习其RFC文档，做下笔记

一、什么是RTSP协议？

RTSP是一个实时传输流协议，是一个应用层的协议
通常说的RTSP包括RTSP协议、RTP协议、RTCP协议
对于这些协议的作用简单的理解如下
RTSP协议：负责服务器与客户端之间的请求与响应
RTP协议：负责传输媒体数据
RTCP协议：在RTP传输过程中提供传输信息
rtsp承载与rtp和rtcp之上，rtsp并不会发送媒体数据，而是使用rtp协议传输
rtp并没有规定发送方式，可以选择udp发送或者tcp发送

二、RTSP协议参数

1.RTSP版本

采用主从版本来表示RTSP版本，
RTSP-Version = “RTSP” “/” 1DIGIT “.” 1DIGIT

2.RTSP URL的语法和语义

rtsp_URL= ( “rtsp:” | “rtspu:” ) “//” host [ “:” port ] [ abs_path ]
host为域名或ip，port为端口（若port为空或不存在，表示默认554端口）
rtsp表示传输层使用tcp，rtspu表示传输层使用udp
URL可以指的是一个流的集合（音视频流），也可以指的是一个单独的视频流。
rtsp://media.example.com:554/twister/audiotrack 可以指的是音频流
rtsp://media.example.com:554/twister 可以指的是音视频流

3.会议标识

会议标识允许RTSP会话从媒体服务器参与的多媒体会议中获取数据，多媒体会议的建立不属于本协议内容，具体参加H.323或SIP协议。固定8位bit长度
conference-id = 1*xchar

4.会话标识

会话标识符必须随机产生并且至少应有8字节长以保证其难以被猜出。
session-id = 1*( ALPHA | DIGIT | safe )

5.SMPTE相对时间戳

表示相对于开始剪辑的时间。以SMPTE时间编码形式表示而可以达到帧级量级的精度。时间编码的格式为：时：分：秒：帧.子帧，并以剪辑开始为起点。缺省的SMPTE格式为“SMPTE 30 drop”格式，其帧速是29.97帧每秒。可通过选择使用不同“SMPTE time”来选择其他SMPTE编码格式（如“SMPTE 25”格式）。帧域的时间值在0到29之间。30帧每秒和29.97帧每秒的不同之处在于后者除每第十分钟外的每分钟都要丢掉头两个帧（00和01）。忽略帧值为0的帧，子帧以百分之一帧为单位。

smpte-range = smpte-type "=" smpte-time "-" [ smpte-time ]
smpte-type = "smpte" | "smpte-30-drop" | "smpte-25" ; 还可以加入其他时间编码
smpte-time = 1*2DIGIT ":" 1*2DIGIT ":" 1*2DIGIT [ ":" 1*2DIGIT ] [ "." 1*2DIGIT ]

比如：
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

6.正常播放时间

正常播放时间(NPT)指出了流相对于表示(presentation)开始时的绝对位置。时间戳由一个十进制小数组成，以秒为单位，小数点左边可以直接以秒表示或者以小时：分：秒的形式表示。

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

比如：
npt=123.45-125
npt=12:05:35.3-
npt=now-

7.绝对时间

绝对时间表示为ISO 8601时间戳，使用UTC(GMT)小数法表示。

utc-range= "clock" "=" utc-time "-" [ utc-time ]
utc-time = utc-date "T" utc-time "Z"
utc-date = 8DIGIT; < YYYYMMDD >
utc-time = 6DIGIT [ "." fraction ] ; < HHMMSS.fraction >

比如，1996年11月8日14点37分20.25秒UTC时间为：
19961108T143720.25Z

三、RTSP消息

RTSP是基于文本的协议，采用ISO 10646 字符集，使用UTF-8编码方案。每行以CRLF终止

1.消息类型

RTSP由请求和响应组成。

start-line  //起始行（分为请求行和状态行），必填  
//请求行Request-Line格式：Method SP Request-URI SP RTSP-Version CRLF
//状态行Status-Line格式：RTSP-Version SP Status-Code SP Reason-Phrase CRLF
*message-header  //一个或多个头域
CRLF  //一行表示标题域结束的空行
[message-body]  //消息主体，可选

2.消息头域

头域包含：通用头域、请求头域、响应头域和实体头域

RTSP-header = field-name ":" [field-value] CRLF //注意SP空格
//域名是大小写敏感的，虽然不提倡，头域还是可以扩展成多行使用，只要这些行以一个以上的SP或HT开头

头域的顺序不重要，良好习惯是通用头域——请求头域——响应头域——实体头域
通用头域：请求和响应都要使用，不用于实体，如Date、Pragma、Cache-Control、Connection、Via等
在这里插入图片描述

请求头域：请求中使用，如
在这里插入图片描述
响应头域：响应中使用的头域，如
在这里插入图片描述
实体头域：
在这里插入图片描述

3.消息主体

4.消息长度

1.任何响应消息，如如1××，204和304状态，都不应包含消息主体Body。其它的回应必须包
括实体主体或其内容长度标题（Content-Length header）域的定义值为0
2.如果Content-Type存在，其值就是消息主体的长度，如果不存在则假定长度为0
RTSP不支持http的块传输编码，因为没有必要，RTSP的消息主体长度没那么大。

四、连接

1.流水线操作

支持持久连接或无连接的客户端可能给其请求排队。服务器必须以收到请求的同样顺序发出回应

2.可靠性及确认

如果采用无连接方式，发送者可在超过一个来回时间RTT后重发同一信息。
如果采用可靠传输协议，请求不允许重发，RTSP依赖传输层的可靠传输提供可靠性，如果在应用层也进行重发的话，可能会导致重传次数过多，加重阻塞。用CSeq表示是否为同一信息

五.方法定义

方法名区分大小写，下图为方法概述，包含名称、传输方向及操作的实体（P为描述信息，S为媒体流）
在这里插入图片描述

1. OPTIONS

可以在任何时候发出，不影响服务器状态，如心跳、向服务端请求可用方法等
在这里插入图片描述

2. DESCRIBE

客户端向服务器请求媒体描述文件。RTSP没有要求必须使用该方法获取SDP文件，也可以使用http方法等

	C->S: DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/1.0
           CSeq: 312
           Accept: application/sdp, application/rtsl, application/mheg  //客户端接受的格式

     S->C: RTSP/1.0 200 OK
           CSeq: 312
           Date: 23 Jan 1997 15:35:06 GMT
           Content-Type: application/sdp
           Content-Length: 376

           v=0
           o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4
           s=SDP Seminar
           i=A Seminar on the session description protocol
           u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps
           e=mjh@isi.edu (Mark Handley)
           c=IN IP4 224.2.17.12/127
           t=2873397496 2873404696
           a=recvonly
           m=audio 3456 RTP/AVP 0
           m=video 2232 RTP/AVP 31
           m=whiteboard 32416 UDP WB
           a=orient:portrait

3. ANNOUNCE

支持双向，当从客户端发往服务端，用于从客户端向服务端推流前，发送媒体描述文件
当从服务端发往客户端时，用于更新媒体流的媒体描述文件

	C->S: ANNOUNCE rtsp://server.example.com/fizzle/foo RTSP/1.0
           CSeq: 312
           Date: 23 Jan 1997 15:35:06 GMT
           Session: 47112344
           Content-Type: application/sdp
           Content-Length: 332

           v=0
           o=mhandley 2890844526 2890845468 IN IP4 126.16.64.4
           s=SDP Seminar
           i=A Seminar on the session description protocol
           u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps
           e=mjh@isi.edu (Mark Handley)
           c=IN IP4 224.2.17.12/127
           t=2873397496 2873404696
           a=recvonly
           m=audio 3456 RTP/AVP 0
           m=video 2232 RTP/AVP 31

     S->C: RTSP/1.0 200 OK
           CSeq: 312

4. SETUP

客户端能够发出一个SETUP请求为正在播放的媒体流改变传输参数，服务器可能同意这些参数的改变。若是不同意，它必须响应错误"455 Method Not Valid In This State"。

	C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/1.0
          CSeq: 302
          Transport: RTP/AVP;unicast;client_port=4588-4589
//解释一下Transport: RTP/AVP;unicast;client_port=4588-4589\r\n
//RTP/AVP：表示RTP通过UDP发送，如果是RTP/AVP/TCP则表示RTP通过TCP发送
//unicast：表示单播，如果是multicast则表示多播
//client_port=4588-4589：由于这里希望采用的是RTP OVER UDP，所以客户端发送了两个用于传输数据的端口，客户端已经将这两个端口绑定到两个udp套接字上，4588表示是RTP端口，4589表示RTCP端口(RTP端口为某个偶数，RTCP端口为RTP端口+1)
    S->C: RTSP/1.0 200 OK
          CSeq: 302
          Date: 23 Jan 1997 15:35:06 GMT
          Session: 47112344
          Transport: RTP/AVP;unicast;
          client_port=4588-4589;server_port=6256-6257
//服务端接收到请求之后，得知客户端要求采用RTP OVER UDP发送数据，单播，客户端用于传输RTP数据的端口为4588，RTCP的端口为4589
//服务器也有两个udp套接字，绑定好两个端口，一个用于传输RTP，一个用于传输RTCP，这里的端口号为6256-6257,之后客户端会使用4588-4589这两端口和服务器通过udp传输数据，服务器会使用6256-6257这两端口和这个客户端传输数据

5. PLAY

PLAY方法告知服务器通过SETUP中指定的机制开始发送数据 。在尚未收到SETUP请求的成功应答之前，客户端不可以发出PLAY请求。PLAY请求将正常播放时间（normal play time）定位到指定范围的起始处，并且传输数据流直到播放范围结束。PLAY请求可能被管道化（pipelined），即放入队列中（queued）；服务器必须将PLAY请求放到队列中有序执行。也就是说，后一个PLAY请求需要等待前一个PLAY请求完成才能得到执行。
比如，在下例中，不管到达的两个PLAY请求之间有多紧凑，服务器首先play第10到15秒，然后立即第20到25秒，最后是第30秒直到结束。

C->S: PLAY rtsp://audio.example.com/audio RTSP/1.0
CSeq: 835
Session: 12345678
Range: npt=10-15

 
C->S: PLAY rtsp://audio.example.com/audio RTSP/1.0
CSeq: 836
Session: 12345678
Range: npt=20-25


C->S: PLAY rtsp://audio.example.com/audio RTSP/1.0
CSeq: 837
Session: 12345678
Range: npt=30-

不含Range首部域的PLAY请求也是合法的。它从媒体流开头开始播放，直到媒体流被暂停。如果媒体流通过PAUSE暂停，媒体流传输将在暂停点（the pause point）重新开始。
如果媒体流正在播放，那么这样一个PLAY请求将不起更多的作用，只是客户端可以用此来测试服务器是否存活。
Range头域可能包含一个时间参数，该参数以UTC格式指定播放的开始时间。如果在这个指定时间后收到消息，那么播放立即开始。时间参数可能用来帮助同步从不同数据源获取的数据流。

下面的示例将播放从SMPTE时间0:10:20直到结束的视频。从1997年1月23号，15点36分开始回放

	C->S: PLAY rtsp://audio.example.com/twister.en RTSP/1.0
           CSeq: 833
           Session: 12345678
           Range: smpte=0:10:20-;time=19970123T153600Z

	S->C: RTSP/1.0 200 OK
           CSeq: 833
           Date: 23 Jan 1997 15:35:06 GMT
           Range: smpte=0:10:22-;time=19970123T153600Z

如果要回放直播，建议使用clock

	C->S: PLAY rtsp://audio.example.com/meeting.en RTSP/1.0
           CSeq: 835
           Session: 12345678
           Range: clock=19961108T142300Z-19961108T143520Z

    S->C: RTSP/1.0 200 OK
           CSeq: 835
           Date: 23 Jan 1997 15:35:06 GMT

媒体服务器必须支持npt，可以选择支持clock和smpte

6. PAUSE

PAUSE请求用于媒体流传输暂停。支持暂停一个完整的媒体流（包含视频音频等），也支持仅暂停音频流，此时视频无声音。

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

请求中支持携带Range头域，用来指定何时暂停媒体流，该头域此时必须为一个精确的时间点，而不是一个时间段。
比如，如果服务器有两个挂起的播放请求，播放范围（range）分别是10到15和20到29，这时收到一个暂停请求，暂停点是NPT21，那么它将会开始播放第二个范围，并且在NPT21处停止。如果服务器正在服务第一个请求播放到NPT13位置，收到暂停请求，暂停点NPT12，那么它将立即停止。如果请求在NPT16暂停，那么服务器在完成第一个播放请求后停止，放弃了第二个播放请求。
再如，服务器收到播放请求，播放范围从10到15和13到20（即之间有重叠），PAUSE暂停点是NPT14，则当服务器播放第一段范围时，PAUSE请求将生效，而第二个PLAY请求会被忽略重叠部分，就好像服务器在开始播放第二段前收到PAUSE请求。不管PAUSE请求何时到达，它总是设置NPT到14。

7. TEARDOWN

TEARDOWN请求终止了给定URI的媒体流传输，并释放了与该媒体流相关的资源。

C->S: TEARDOWN rtsp://example.com/fizzle/foo RTSP/1.0
CSeq: 892
Session: 12345678

S->C: RTSP/1.0 200 OK
CSeq: 892

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  //"text/parameters"段只是参数类型的一个例子,支持用户自定义报文类型和消息主体格式
Session: 12345678
Content-Length: 15
packets_received
jitter

C->S: RTSP/1.0 200 OK
CSeq: 431
Content-Length: 46
Content-Type: text/parameters
packets_received: 10
jitter: 0.3838

9. SET PARAMETER

SET PARAMETER请求设置指定URI媒体流的参数值（非SETUP的传输参数，只有SETUP能设置传输参数）。

C->S: SET_PARAMETER rtsp://example.com/fizzle/foo RTSP/1.0
CSeq: 421
Content-length: 20
Content-type: text/parameters
barparam: barstuff

S->C: RTSP/1.0 451 Invalid Parameter
CSeq: 421
Content-length: 10
Content-type: text/parameters
barparam

10. REDIRECT

重定向请求告知客户端连接到另一个服务器，包含头域Location。如果客户端希望继续获取媒体流，需要发送TEARDOWN关闭当前会话，并向重定向URL发送SETUP以建立新会话

S->C: REDIRECT rtsp://example.com/fizzle/foo RTSP/1.0
CSeq: 732
Location: rtsp://bigserver.com:8001
Range: clock=19960213T143205Z-     //表示重定向URL的生效时间范围

11. RECORD

此方法用于告知服务器开始记录媒体数据，支持头域timestamp表示记录的起始和结束时间（UTC格式），如果没有给定时间范围，则使用PLAY中的起始和结束时间。服务器来决定是否存储媒体数据到请求URL下还是其他URL下，如果存储到其他URL下，需要服务器返回201状态（创建），并包含一个Location头域表示新的URL
允许在直播场景下使用clock头域，不支持smpte格式

C->S: RECORD rtsp://example.com/meeting/audio.en RTSP/1.0
CSeq: 954
Session: 12345678
Conference: 128.16.64.19/32492374  //定位到指定会议中

六、RTSP协议的有限状态机

协议实现时，客户端和服务端分别需要在请求变化时改变其状态，通常使用有限状态机来实现。

1.客户端状态机

Init：已发送SETUP，等待应答
Ready：已接收到SETUP应答 或 在PLAY过程中接收到PAUSE应答
Playing：已接收到PLAY应答
Recording：已接收到RECORD应答

在这里插入图片描述

2.服务端状态机

Init：未收到有效的SETUP请求
Ready：最近一次的SETUP请求已成功接收并完成应答 或 在PLAY过程中接收到PAUSE请求并完成应答
Playing：最近一次的PLAY请求已成功接收并完成应答
Recording：服务器正在记录媒体数据
在这里插入图片描述

七、SDP使用方法

协议实现时，客户端和服务端分别需要在请求变化时改变其状态，通常使用有限状态机来实现。

1.客户端状态机

Init：已发送SETUP，等待应答
Ready：已接收到SETUP应答 或 在PLAY过程中接收到PAUSE应答
Playing：已接收到PLAY应答
Recording：已接收到RECORD应答

是唯水啊
关注
  • 0
    点赞
  • 踩
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
RTSP交互命令简介及过程参数描述
08-31
RTSP 交互命令的简介及其过程参数描述
网络协议——RTSP（简介、搭建RTSP服务器）
最新发布
计算机硕士的博客
05-22 2158
网络协议——RTSP（简介、搭建RTSP服务器）。
实时流协议---RTSP【详解】
热门推荐
王木木
01-28 3万+
一、RTSP协议介绍 RTSP（Real Time Streaming Protocol 实时流协议）是一个有效地在IP网络上传输流媒体数据的应用层协议。RTSP对流媒体提供了诸如开始、暂停、快进、停止等控制，RTSP的作用相当于流媒体服务器的远程控制，而它本身并不传输数据。 官方指导文档参考：RFC 2326 - Real Time Streaming Protocol (RTSP) 它的语法和运作跟HTTP 1.1类似，但并不特别强调时间同步，所以比较能容忍网络延迟。 RTSP具有重新导...
rtsp协议详解
wangbuji的博客
01-10 6966
RTSP(Real-TimeStream Protocol )，RFC2326，实时流传输协议，是一种基于文本的应用层协议，在语法及一些消息参数等方面，RTSP协议与HTTP协议类似。RTSP被用于建立的控制媒体流的传输，它为多媒体服务扮演“网络远程控制”的角色。尽管有时可以把RTSP控制信息和媒体数据流交织在一起传送，但一般情况RTSP本身并不用于转送媒体流数据。媒体数据的传送可通过RTP/RTCP等协议来完成。 RTSP在制定时较多地参考了HTTP/1.1协议，甚至许多描述与HTTP/1...
RTSP协议详解.zip
09-16
RTSP协议的核心概念包括会话（Session）、播放器（Client）、服务器（Server）以及媒体源（Media Server）。客户端通过发送RTSP请求来控制服务器上的媒体流，服务器则响应这些请求，执行相应的操作。RTSP协议使用TCP...
RTSP协议详解-RTSP
05-20
RTSP协议允许客户端对媒体流进行播放、暂停、快进、快退等操作，而不仅仅局限于简单的下载。 RTSP协议的语法和HTTP有诸多相似之处，这使得可以复用一些HTTP协议分析的代码，降低了实现成本。两者都是基于文本的协议...
rtsp协议详解之中文版
03-25
在RTSP协议中，流媒体是指可以在接收过程中就开始播放的在线媒体内容，区别于需要下载完整内容才能播放的传统媒体。流媒体技术涉及一系列协议，包括RTP、RTCP、RTSP和RSVP。这些协议在不同的网络协议层中各有其职责...
RTSP协议详解中文版
05-06
RTSP协议详解中文版 详细介绍了rtsp协议 具体请看文档
RTSP协议详解中文
09-20
实时流协议（RTSP）是应用层协议，控制实时数据的传送 。RTSP提供了一个可扩展框架，使受控、按需传输实时数据（如音频与视频）成为可能。数据源包括现场数据与存储在剪辑中的数据。本协议旨在于控制多个数据发送...
android rtsp协议详解
12-02
android rtsp协议详解，想要开发在线视频直播的可以了解下
RTSP协议详解，中文版
07-22
RTSP协议的一个关键特性是它维护了会话的状态，这意味着服务器和客户端之间的连接不会在每次操作后立即断开。相反，RTSP命令通常是按顺序发送的，每个命令都依赖于之前的命令，以便在正确的状态下执行。例如，...
RTSP协议详解与实时流视频预览-第6/11季视频课程-海思
06-10
本季详细讲解RTSP协议的技术细节，并且编程实现基于RTSP协议的实时视频流传输，在局域网内浏览实时监控画面。RTSP是实时视频网络传输主流的实现方式，低延时高清晰度的RTSP视频流传输是网络直播、在线会议系统等行业...
RTSP网络视频协议
weixin_44651073的博客
01-12 1999
RTSP拉流字段分析

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值