RTSP协议详解

最新推荐文章于 2024-08-05 00:00:00 发布
最新推荐文章于 2024-08-05 00:00:00 发布
阅读量1.8k 收藏 5
点赞数 2
分类专栏： 协议&标准 音视频
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/qq_28258885/article/details/119610381
版权

目录

RTSP协议概述

RTSP(Real-TimeStream Protocol )是一种基于文本的应用层协议，RTSP 在体系结构上位于 RTP 和 RTCP 之上， 其使用 TCP 或 UDP 完成数据的传输。在语法及一些消息参数等方面，RTSP协议与HTTP协议类似。RTSP 在体系结构上位于 RTP 和 RTCP 之上， 其使用 TCP 或 UDP 完成数据的传输

它主要用来控制具有实时特性的数据的发送，但其本身并不用于传送流媒体数据，而必须依赖下层传输协议(如RTP/RTCP)所提供的服务来完成流媒体数据的传送

RTSP 是用来控制声音或影像多媒体串流协议， 并允许同时多个串流需求控制， 传输时所用的网络通信协定并不在其定义范围内

RTSP 协议默认端口： 554， 默认承载协议为 TCP
在这里插入图片描述

五六年前，所有厂家的SC交互是自定义的，不同厂家不兼容。RTSP的流行就是制定了SC交互的标准，保证兼容

RTSP和HTTP的区别

  • HTTP 请求由客户机发出， 服务器作出响应， HTTP单向；使用 RTSP 时， 客户机和服务器都可以发出请求， 即RTSP 可以是双向的

  • RTSP引入了几种新的方法，比如DESCRIBE、PLAY、SETUP 等，并且有不同的协议标识符，RTSP为rtsp 1.0,HTTP为http 1.1；

  • HTTP是无状态的协议，而RTSP为每个会话保持状态；

  • 在RTSP协议中，载荷数据一般是通过带外方式来传送的(除了交织的情况)，即通过RTP协议在不同的通道中来传送载荷数据。而HTTP协议的载荷数据都是通过带内方式传送的，比如请求的网页数据是在回应的消息体中携带的。

  • RTSP使用ISO10646(UTF-8) 而不是HTTP的ISO 8859-1，以配合当前HTML的国际化；

RTSP重要术语

  1. 集合控制(Aggregatecontrol):
    对多个流的同时控制。对音频/视频来讲，客户端仅需发送一条播放或者暂停消息就可同时控制音频流和视频流。

  2. 实体(Entity)：
    作为请求或者回应的有效负荷传输的信息。由以实体标题域（entity-header field）形式存在的元信息和以实体主体（entity body）形式存在的内容组成

  3. 容器文件（Containerfile）：
    可以容纳多个媒体流的文件。RTSP服务器可以为这些容器文件提供集合控制。

  4. RTSP会话(RTSP session)：
    RTSP交互的全过程。对一个电影的观看过程,会话(session)包括由客户端建立媒体流传输机制(SETUP)，使用播放(PLAY)或录制(RECORD)开始传送流，用停止(TEARDOWN)关闭流。

RTSP特性

  • 流控分离
    从逻辑控制上来说，RTSP和FTP相似，流控和数据流是分开的（见下一张图）
  • 可扩展性
    RTSP协议是基于文本的协议，所以既有较强的可扩展性
  • 安全机制
    RTSP使用王爷安全机制
  • 记录设备控制
    协议可控制记录和回放设备
  • 代理和防火墙友好
    协议可由应用和传输防火墙代理，防火墙需要理解SETUP方法，为UDP流打开一个“缺口”

RTSP传输流程简介

一次基本的RTSP操作过程是:

  • 1、首先，客户端连接到流服务器并发送一个RTSP描述命令（DESCRIBE）。流服务器通过一个SDP描述来进行反馈，反馈信息包括流数量、媒体类型等信息。
  • 2、客户端再分析该SDP描述，并为会话中的每一个流发送一个RTSP建立命令(SETUP)，RTSP建立命令告诉服务器客户端用于接收媒体数据的端口。
  • 3、流媒体连接建立完成后，客户端发送一个播放命令(PLAY)，服务器就开始在UDP上传送媒体流（RTP包）到客户端。
  • 4、在播放过程中客户端还可以向服务器发送命令来控制快进、快退和暂停等。
  • 5、最后，客户端可发送一个终止命令(TERADOWN)来结束流媒体会话


下图为RTSP状态转换图解

RTSP信息

请求信息


其中方法包括OPIONS、DESCRIBE、SETUP、PLAY、TEARDOWN等,URI是接受方的地址,例如:rtsp://192.168.0.1/video1.3gp。

RTSP版本一般都是 RTSP/1.0。每行后面的CR LF表示回车换行，需要接受端有相应的解析，最后一个消息头需要有两个CR LF

消息体是可选的，有的Request消息并不带消息体。

回应消息


其中RTSP版本一般都是RTSP/1.0,状态码是一个数值，用于表示Request消息的执行结果,比如200表示成功,解释是与状态码对应的文本解释.

RTSP传输流程详解

标准流程methods


下面一边详解流程一边详解分析方法

  • OPTIONS

OPTIONS请求时客户端向服务器询问可用的方法，请求和回复实例如下

C->S:  OPTIONS rtsp://example.com/media.mp4 RTSP/1.0
       CSeq: 1
       Require: implicit-play
       Proxy-Require: gzipped-messages
 
S->C:  RTSP/1.0 200 OK
       CSeq: 1     /* 每个回应消息的cseq数值和请求消息的cseq相对应 */
       Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE
  • DESCRIBE

客户端向服务器请求媒体资源描述，服务器端通过SDP(Session Description Protocol)格式回应客户端的请求。资源描述中会列出所请求媒体的媒体流及其相关信息，典型情况下，音频和视频分别作为一个媒体流传输。实例如下

C->S: DESCRIBE rtsp://example.com/media.mp4 RTSP/1.0
      CSeq: 2
 
S->C: RTSP/1.0 200 OK
      CSeq: 2
      Content-Base: rtsp://example.com/media.mp4
      Content-Type: application/sdp		/*表示回应是SDP信息*/
      Content-Length: 460
 
      m=video 0 RTP/AVP 96				/* 以下为具体的SDP信息 */
      a=control:streamid=0
      a=range:npt=0-7.741000
      a=length:npt=7.741000
      a=rtpmap:96 MP4V-ES/5544
      a=mimetype:string;"video/MP4V-ES"
      a=AvgBitRate:integer;304018
      a=StreamName:string;"hinted video track"
      m=audio 0 RTP/AVP 97
      a=control:streamid=1
      a=range:npt=0-7.712000
      a=length:npt=7.712000
      a=rtpmap:97 mpeg4-generic/32000/2
      a=mimetype:string;"audio/mpeg4-generic"
      a=AvgBitRate:integer;65790
      a=StreamName:string;"hinted audio track"

媒体初始化是任何基于RTSP系统的必要条件，但RTSP规范并没有规定它必须通过DESCRIBE方法完成。RTSP客户端可以通过以下方法来接收媒体描述信息：

  • a) 通过DESCRIBE方法；
  • b) 其它一些协议（HTTP，email附件，等）；
  • c) 通过命令行或标准输入设备
  • SETUP

用于确定转输机制，建立RTSP会话，建立完了才能PLAY。SETUP请求包含媒体流的URL和客户端用于接收RTP数据(audio or video)的端口以及接收RTCP数据(meta information)的端口。服务器端的回复通常包含客户端请求参数的确认，并会补充缺失的部分，比如服务器选择的发送端口。每一个媒体流在发送PLAY请求之前，都要首先通过SETUP请求来进行相应的配置。

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

C->S: SETUP rtsp://example.com/media.mp4/streamid=0 RTSP/1.0
      CSeq: 3
      Transport: RTP/AVP;unicast;client_port=8000-8001
 
S->C: RTSP/1.0 200 OK
      CSeq: 3
      Transport: RTP/AVP;unicast;client_port=8000-8001;server_port=9000-9001;ssrc=1234ABCD
      Session: 12345678	/*服务端对SETUP请求城市一个Session Identifiers*/
  • PLAY

PLAY方法告知服务器通过SETUP中指定的机制开始发送数据 。在尚未收到SETUP请求的成功应答之前，客户端不可以发出PLAY请求。

PLAY请求将正常播放时间（normal play time）定位到指定range的起始处，并且传输数据流直到播放范围结束；若未指定，则从媒体流的开始播放到结束。

PLAY请求可能被管道化（pipelined），即放入队列中（queued）；服务器必须将PLAY请求放到队列中有序执行。也就是说，后一个PLAY请求需要等待前一个PLAY请求完成才能得到执行。

C->S: PLAY rtsp://example.com/media.mp4 RTSP/1.0
      CSeq: 4
      Range: npt=5-20 /*播放媒体流的5-20秒*/
      Session: 12345678
 
S->C: RTSP/1.0 200 OK
      CSeq: 4
      Session: 12345678
      RTP-Info: url=rtsp://example.com/media.mp4/streamid=0;seq=9810092;rtptime=3450012

Range头可能包含一个时间参数。该参数以UTC格式指定了播放开始的时间。如果在这个指定时间后收到消息，那么播放立即开始。时间参数可能用来帮助同步从不同数据源获取的数据流。

不含Range头的PLAY请求也是合法的。它从媒体流开头开始播放，直到媒体流被暂停。如果媒体流通过PAUSE暂停，媒体流传输将在暂停点（the pause point）重新开始。

如果媒体流正在播放，那么这样一个PLAY请求将不起更多的作用，只是客户端可以用此来测试服务器是否存活。

  • PAUSE

PAUSE请求会暂停一个或所有媒体流，后续可通过PLAY请求恢复播放。PAUSE请求中携带所请求媒体流的URL，若参数range存在，则指明在何处暂停，若该参数不存在，则暂停立即生效，且暂停时长不确定。

可以通过URL指定具体的媒体流，如只暂停音频，那么播放将会变成无声。URL也可以指定一组流，这组流全会被暂停

C->S: PAUSE rtsp://example.com/media.mp4 RTSP/1.0
      CSeq: 5
      Session: 12345678
 
S->C: RTSP/1.0 200 OK
      CSeq: 5
      Session: 12345678

PAUSE请求中可能包含一个Range头用来指定何时媒体流暂停，我们称这个时刻为暂停点（pause point）。
该头必须包含一个精确的值，而不是一个时间范围。媒体流的正常播放时间设置成暂停点。当服务器遇到在任何当前挂起（pending）的PLAY请求中指定的时间点后，暂停请求生效。

如果Range头指定了一个时间超出了任何一个当前挂起的PLAY请求，将返回错误"457 Invalid Range"
如果一个媒体单元（比如一个音频或视频禎）正好在一个暂停点开始，那么表示将不会被播放或记录
如果Range头缺失，那么在收到暂停消息后媒体流传输立即中断，并且暂停点设置成当前正常播放时间。

  • TERDOWN
    结束会话请求，该请求会停止所有媒体流，并释放服务器上的相关会话数据
C->S: TEARDOWN rtsp://example.com/media.mp4 RTSP/1.0
      CSeq: 8
      Session: 12345678
 
S->C: RTSP/1.0 200 OK
      CSeq: 8

功能请求methods

  • SET_PARAMETER

用于设置指定媒体流的参数。

C->S: SET_PARAMETER rtsp://example.com/media.mp4 RTSP/1.0
      CSeq: 10
      Content-length: 20
      Content-type: text/parameters
 
      barparam: barstuff
 
S->C: RTSP/1.0 451 Invalid Parameter
      CSeq: 10
      Content-length: 10
      Content-type: text/parameters
 
      barparam
  • REDIRECT

重定向请求，用于服务器通知客户端新的服务地址，客户端需要向这个新地址重新发起请求。重定向请求中可能包含Range参数，指明重定向生效的时间。客户端若需向新服务地址发起请求，必须先teardown当前会话，再向指定的新主机setup一个新的会话。

S->C: REDIRECT rtsp://example.com/media.mp4 RTSP/1.0
      CSeq: 11
      Location: rtsp://bigserver.com:8001
      Range: clock=19960213T143205Z-
  • ANNOUNCE

ANNOUNCE请求有两个用途：
(1)C->S：客户端向服务器端发布URL指定的媒体信息描述；
(2) S->C：实时更新对话描述。若媒体表示中新增了一个媒体流，例如在直播过程中，则整个媒体表示的description都要被重新发送，而不是只发送新增部分

C->S: ANNOUNCE rtsp://example.com/media.mp4 RTSP/1.0
      CSeq: 7
      Date: 23 Jan 1997 15:35:06 GMT
      Session: 12345678
      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: 7
  • RECORD

请求录制指定范围的媒体数据，请求中可指定录制的起止时间戳；若未指定时间范围，则使用presentation description中的开始和结束时间，这种情况下，如果会话已开始，则立即启动录制操作。

C->S: RECORD rtsp://example.com/media.mp4 RTSP/1.0
      CSeq: 6
      Session: 12345678
 
S->C: RTSP/1.0 200 OK
      CSeq: 6
      Session: 12345678

重要头字段参数

  • ACCEPT

用于指定客户端可以接受的媒体描述信息类型

Accept: application/rtsl, application/sdp;level=2
  • Bandwidth

用于描述客户端可用的带宽值

  • CSeq

制定了RTSP请求会有对的序列号在每个请求或回应中都必须包括这个头字段。对每个包含一个给定序列号的请求消息，都会有一个相同序列号的回应消息

  • Range

用于指定一个时间范围，可以使用SMPTE、NTP或clock时间单元

  • Session

Session头字段标识了一个RTSP会话。Session ID 是由服务器在SETUP的回应中选择的，客户端一当得到Session ID后，在以后的对Session 的操作请求消息中都要包含Session ID.

  • Transport

Transport头字段包含客户端可以接受的转输选项列表，包括传输协议，地址端口，TTL等。服务器端也通过这个头字段返回实际选择的具体选项

Transport: RTP/AVP;multicast;ttl=127;mode="PLAY",

RTP/AVP;unicast;client_port=3456-3457;mode="PLAY"

RTSP传输流程实例

最后，来看一段实际使用的RTSP命令交互过程，该过程是通过PC对海康摄像头视频流的拉取和播放，并通过Wireshark抓取客户端的数据得到的

OPTIONS rtsp://10.3.8.202:554 RTSP/1.0		/*C询问S有哪些方法可用*/
CSeq: 2
User-Agent: LibVLC/2.2.8 (LIVE555 Streaming Media v2016.02.22)
 
RTSP/1.0 200 OK
CSeq: 2
Public: OPTIONS, DESCRIBE, PLAY, PAUSE, SETUP, TEARDOWN, SET_PARAMETER, GET_PARAMETER	/*S回应C的publuc头字段中包含S提供的所有可用方法*/
Date:  Mon, Jan 29 2018 16:56:47 GMT
 
DESCRIBE rtsp://10.3.8.202:554 RTSP/1.0		/*C要求得到S提供的媒体描述信息*/
CSeq: 3
User-Agent: LibVLC/2.2.8 (LIVE555 Streaming Media v2016.02.22)
Accept: application/sdp						/*表示S回应是SDP信息*/
 
RTSP/1.0 401 Unauthorized
CSeq: 3
WWW-Authenticate: Digest realm="IP Camera(10789)", nonce="6b9a455aec675b8db81a9ceb802e4eb8", stale="FALSE"	/*S回应媒体描述信息，由于是加密的，没输密码，S返回临时随机数nonce*/
Date:  Mon, Jan 29 2018 16:56:47 GMT
 
DESCRIBE rtsp://10.3.8.202:554 RTSP/1.0		/*再次要求媒体描述信息*/
CSeq: 4
Authorization: Digest username="admin", realm="IP Camera(10789)", nonce="6b9a455aec675b8db81a9ceb802e4eb8", uri="rtsp://10.3.8.202:554", response="3fc4b15d7a923fc36f32897e3cee69aa"	/*验证用户名、域、随机数、URL、按照加密后的user+password+URL的MD5编码*/
User-Agent: LibVLC/2.2.8 (LIVE555 Streaming Media v2016.02.22)
Accept: application/sdp
 
RTSP/1.0 200 OK		/*认证成功*/
CSeq: 4
Content-Type: application/sdp
Content-Base: rtsp://10.3.8.202:554/
Content-Length: 551
 
v=0					/* 以下为具体SDP格式的DESCRIBE信息 */
o=- 1517245007527432 1517245007527432 IN IP4 10.3.8.202
s=Media Presentation
e=NONE
b=AS:5050
t=0 0
a=control:rtsp://10.3.8.202:554/
m=video 0 RTP/AVP 96
c=IN IP4 0.0.0.0
b=AS:5000
a=recvonly
a=x-dimensions:2048,1536
a=control:rtsp://10.3.8.202:554/trackID=1
a=rtpmap:96 H264/90000
a=fmtp:96 profile-level-id=420029; packetization-mode=1; sprop-parameter-sets=Z00AMp2oCAAwabgICAoAAAMAAgAAAwBlCA==,aO48gA==
a=Media_header:MEDIAINFO=494D4B48010200000400000100000000000000000000000000000000000000000000000000000000;
a=appversion:1.0
 
SETUP rtsp://10.3.8.202:554/trackID=1 RTSP/1.0		/*C向S请求建立RTSP会话*/
CSeq: 5
Authorization: Digest username="admin", realm="IP Camera(10789)", nonce="6b9a455aec675b8db81a9ceb802e4eb8", uri="rtsp://10.3.8.202:554/", response="ddfbf3e268ae954979407369a104a620"
User-Agent: LibVLC/2.2.8 (LIVE555 Streaming Media v2016.02.22)
Transport: RTP/AVP;unicast;client_port=57844-57845
 
RTSP/1.0 200 OK		/*S建立会话，通过Transport头字段返回选择的具体传输选项，并返回建立的Session ID*/
CSeq: 5
Session:       1273222592;timeout=60
Transport: RTP/AVP;unicast;client_port=57844-57845;server_port=8218-8219;ssrc=5181c73a;mode="play"
Date:  Mon, Jan 29 2018 16:56:47 GMT
 
PLAY rtsp://10.3.8.202:554/ RTSP/1.0	/*C请求S开始发送数据，新版LIV555需要加密，用到之前DESCRIBE给出的随机数*/
CSeq: 6
Authorization: Digest username="admin", realm="IP Camera(10789)", nonce="6b9a455aec675b8db81a9ceb802e4eb8", uri="rtsp://10.3.8.202:554/", response="b5abf0b230de4b49d6c6d42569f88e91"
User-Agent: LibVLC/2.2.8 (LIVE555 Streaming Media v2016.02.22)
Session: 1273222592
Range: npt=0.000-
 
RTSP/1.0 200 OK		/*S回应请求的数据并播放*/
CSeq: 6
Session:       1273222592
RTP-Info: url=rtsp://10.3.8.202:554/trackID=1;seq=65373;rtptime=3566398668
Date:  Mon, Jan 29 2018 16:56:47 GMT
 
GET_PARAMETER rtsp://10.3.8.202:554/ RTSP/1.0	/*C向S请求获取参数*/
CSeq: 7
Authorization: Digest username="admin", realm="IP Camera(10789)", nonce="6b9a455aec675b8db81a9ceb802e4eb8", uri="rtsp://10.3.8.202:554/", response="bb2309dcd083b25991c13e165673687b"
User-Agent: LibVLC/2.2.8 (LIVE555 Streaming Media v2016.02.22)
Session: 1273222592
 
RTSP/1.0 200 OK			/*S回应*/
CSeq: 7
Date:  Mon, Jan 29 2018 16:56:47 GMT
 
TEARDOWN rtsp://10.3.8.202:554/ RTSP/1.0		/*C向S请求关闭会话*/
CSeq: 8
Authorization: Digest username="admin", realm="IP Camera(10789)", nonce="6b9a455aec675b8db81a9ceb802e4eb8", uri="rtsp://10.3.8.202:554/", response="e08a15c27d3daac14fd4b4bcab424a5e"
User-Agent: LibVLC/2.2.8 (LIVE555 Streaming Media v2016.02.22)
Session: 1273222592
 
RTSP/1.0 200 OK		/*S回应*/
CSeq: 8
Session:       1273222592
Date:  Mon, Jan 29 2018 16:57:03 GMT

RTSP传输流程总结

C表示RTSP客户端,S表示RTSP服务端

  • 1 第一步：查询服务器端可用方法
1.C->S:OPTIONrequest       //询问S有哪些方法可用
1.S->C:OPTIONresponse    //S回应信息的public头字段中包括提供的所有可用方法
  • 2 第二步：得到媒体描述信息
    新版本的LIVE555是加密的，第一次请求S会返回随机数，用于第二次请求的验证
    需要验证用户名、域、随机数、URL、按照加密后的user+password+URL的MD5编码
    此后的每一步C向S的请求都需要验证
2.C->S:DESCRIBE request      //要求得到S提供的媒体描述信息
2.S->C:DESCRIBE response    //S回应媒体描述信息，一般是sdp信息
  • 3 第三步：建立RTSP会话
3.C->S:SETUPrequest            //通过Transport头字段列出可接受的传输选项，请求S建立会话
3.S->C:SETUPresponse          //S建立会话，通过Transport头字段返回选择的具体转输选项，并返回建立的Session ID;
  • 4 第四步：请求开始传送数据
4.C->S:PLAY request        //C请求S开始发送数据
4.S->C:PLAYresponse            //S回应该请求的信息
  • 5第五步： 数据传送播放中
S->C:发送流媒体数据    // 通过RTP协议传送数据
  • 6第六步：关闭会话，退出
6C->S:TEARDOWN request      //C请求关闭会话
6.S->C:TEARDOWN response //S回应该请求

上述的过程只是标准的、友好的rtsp流程，但实际的需求中并不一定按此过程。

其中第三和第四步是必需的！
第一步，只要服务器客户端约定好，有哪些方法可用，则option请求可以不要。
第二步，如果我们有其他途径得到媒体初始化描述信息（比如http请求等等），则我们也不需要通过rtsp中的describe请求来完成。

SDP协议

SERVER返回的DESCRIBE信息常用SDP格式

Spark！
关注
专栏目录
一文读懂RTSP协议-【RTSP协议详解】
yinshipin007的博客
09-03 4557
接下来的数据包头部第二个字节位置就是interleaved，它的值是每个通道都不同的，trackID＝0的interleaved值有两个0或1，0表示rtp包，1表示rtcp包，接受端根据interleaved的值来区别是哪种数据包。其中方法包括OPTIONS、SETUP、PLAY、TEARDOWN等待，URI是接收方（服务端）的地址，例如：rtsp://192.168.22.136:5000/v0，每行后面的CR LF表示回车换行，需要接收端有相应的解析，最后一个消息头需要有两个CR LF。
RTSP协议详解-RTSP
05-20
关于 RTSP. RTSP 协议是一个非常类似 HTTP 协议的流控制协议。它们都使用纯文本来发送信息，而且 rtsp 协议的语法也和 HTTP 类似。 Rtsp 一开始这样设计，也是为了能够兼容使用以前写的 HTTP 协议分析代码 。这是个好消息。
RTSP系列一：RTSP协议介绍
最新发布
不定期更新关于音视频的文章
08-05 2438
RTSP（Real Time Streaming Protocol），实时流传输协议，是TCP/IP 协议体系中的一个应用层协议，由哥伦比亚大学、网景和RealNetworks 公司提交的IETF RFC 标准。该协议定义了一对多应用程序如何有效地通过IP 网络传送多媒体数据。其语法和操作参考了HTTP/1.1，默认端口554。RTSP主要应用在视频监控领域，网络摄像头都支持RTSP协议。RTSP只是对媒体传输进行控制，真正传输音视频是RTP协议，将在后面介绍。
RTSP协议
chenchizhao的专栏
06-06 735
RTSP协议 因为项目需要，学习了一下RTSP协议，为了防止以后忘记，就把学习过程和成果记载下来。期间参考了一些网上的资料，并分析了VLC的RTSP报文。     RTSP（Real Time Streaming Protocol，实时流协议），是由Real Network和Netscape共同提出的如何有效地在IP网络上传输流媒体数据的应用层协议。RTSP提供一种可扩展的框架，能够提供可控制
rtsp协议笔记
04-25 2771
RTSP协议学习笔记... 1 第一部分:RTSP协议... 3 一、       RTSP协议概述... 3 二、       RTSP协议与HTTP协议区别... 3 三、       RTSP重要术语... 4 1.       集合控制(Aggregatecontrol ):. 4 2.       实体(Entity)：... 4 3.       容器文件
网络流媒体协议之——RTSP协议
热门推荐
牧羊女
01-29 6万+
RTSP(Real-Time Stream Protocol)协议是一个基于文本的多媒体播放控制协议，属于应用层。RTSP以客户端方式工作，对流媒体提供播放、暂停、后退、前进等操作。该标准由IETF指定，对应的协议是RFC2326。 RTSP作为一个应用层协议，提供了一个可供扩展的框架，使得流媒体的受控和点播变得可能，它主要用来控制具有实时特性的数据的发送，但其本身并不用于传送流媒体数据，而
RTSP协议详解.zip
09-16
RTSP协议的核心概念包括会话（Session）、播放器（Client）、服务器（Server）以及媒体源（Media Server）。客户端通过发送RTSP请求来控制服务器上的媒体流，服务器则响应这些请求，执行相应的操作。RTSP协议使用TCP...
rtsp协议详解
pingkai的专栏
09-09 274
<br />rtsp简介(ZT)<br /><br />Real Time Streaming Protocol或者RTSP（实时流媒体协议），是由Real network 和Netscape共同提出的如何有效地在IP网络上传输流媒体数据的应用层协议。RTSP提供一种可扩展的框架，使能够提供能控制的，按需传输实时数据，比如音频和视频文件。源数据可以包括现场数据的反馈和存贮的文件。rtsp对流媒体提供了诸如暂停，快进等控制，而它本身并不传输数据，rtsp作用相当于流媒体服务器的远程控制。传输数据可以通过传输层
评论 1
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

Spark！

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

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

余额充值