RTSP-(1)通信基础、协议簇

最新推荐文章于 2024-04-27 22:35:53 发布
最新推荐文章于 2024-04-27 22:35:53 发布
阅读量783 收藏 2
点赞数
分类专栏： 音视频 文章标签： tcp/ip 视频处理
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/wanzheng_96/article/details/120137226
版权

文章目录

RTSP 协议概述

RTSP(Real-TimeStream Protocol )是一种基于文本的应用层协议，在语法及一些消息参数等方面，RTSP 协议与 HTTP 协议类似。

RTSP 被用于建立的控制媒体流的传输，它为多媒体服务扮演“网络远程控制”的角色。尽管有时可以把 RTSP 控制信息和媒体数据流交织在一起传送，但一般情况 RTSP 本身并不用于转送媒体流数据。媒体数据的传送可通过RTP/RTCP等协议来完成。

  • RTSP协议：负责服务器与客户端之间的请求与响应
  • RTP协议：负责传输媒体数据
  • RTCP协议：在 RTP 传输过程中提供传输信息

rtsp 承载与 rtp 和 rtcp 之上，rtsp 并不会发送媒体数据，而是使用 rtp 协议传输
rtp 并没有规定发送方式，可以选择 udp 发送或者 tcp 发送。

基本通信流程

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

RTSP 协议与 HTTP 协议区别

  1. RTSP 引入了几种新的方法，比如 DESCRIBE、PLAY、SETUP 等，并且有不同的协议标识符，例如：RTSP 为 rtsp 1.0（版本号，现在有 2.0）,HTTP 为 http 1.1；
  2. HTTP 是无状态的协议，而 RTSP 为每个会话保持状态；
  3. RTSP 协议的客户端和服务器端都可以发送 Request 请求，而在 HTTPF 协议中，只有客户端能发送 Request 请求。
  4. 在 RTSP 协议中，载荷数据一般是通过带外方式来传送的(除了交织的情况)，及通过 RTP 协议在不同的通道中来传送载荷数据。而 HTTP 协议的载荷数据都是通过带内方式传送的，比如请求的网页数据是在回应的消息体中携带的。
  5. 使用 ISO10646(UTF-8) 而不是 ISO 8859-1，以配合当前 HTML 的国际化；
  6. RTSP 使用 URI 请求时包含绝对 URI。而由于历史原因造成的向后兼容性问题，HTTP/1.1 只在请求中包含绝对路径，把主机名放入单独的标题域中；

重要术语

  1. 集合控制(Aggregatecontrol )

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

  1. 实体(Entity)

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

  1. 容器文件（Containerfile）

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

  1. RTSP 会话(RTSP session )

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

RTSP 协议详解

RTSP 请求消息

RTSP 协议格式与 HTTP 协议格式类似

method url vesion\r\n
CSeq: x\r\n
xxx\r\n
...
\r\n
  • method：方法，表明这次请求的方法，包括 OPIONS、DESCRIBE、SETUP、PLAY、TEARDOWN 等.
  • url：格式一般为 rtsp://ip:port/session，ip 表主机 ip，port 表端口好，如果不写那么就是默认端口，rtsp 的默认端口为 554，session 表明请求哪一个会话
  • version：表示 rtsp 的版本，常见的是 RTSP/1.0
  • CSeq：序列号，每个 RTSP 请求和响应都对应一个序列号，序列号是递增的

每行后面的 CR LF(\r\n)表示回车换行，需要接受端有相应的解析，最后一个消息头需要有两个 CR LF

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

RTSP 服务端响应消息

vesion 200 OK\r\n
CSeq: x\r\n
xxx\r\n
...
\r\n
  • version：表示 rtsp 的版本，常见为 RTSP/1.0
  • CSeq：序列号，这个必须与对应请求的序列号相同
方法方向描述要求
OPTIONSC->S, C->S获取服务端提供的可用方法必须(S->C:可选)
DESCRIBEC->S向服务端获取对应会话的媒体描述信息建议
SETUPC->S向服务端发起建立请求，建立连接会话必须
PLAYC->S向服务端发起播放请求必须
TEARDOWNC->S向服务端发起关闭连接会话请求必须
PAUSEC->S向服务端发起媒体流传输的暂时中断可选
ANNOUNCEC->S, S->C可选
GET_PARAMERTEC-S, S->C可选
RECORDC->S可选
REDIRECTS->C可选
SET_PARAMETERC->S, S->C可选

重要请求头参数

  1. Accept:

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

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

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

  1. CSeq：

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

  1. Range：

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

  1. Session:

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

  1. Transport:

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

Transport: RTP/AVP;multicast;ttl=127;mode="play"
Transport: RTP/AVP;unicast;client_port=3456-3457;mode="play"

交互过程举例

根据一般的 RTSP 流媒体播放流程大致讲解前 5 个方法，一般摄像头 RTSP 会设计到认证加密，请参考本人其他文章讲解。

1. OPTIONS

  • C->S
OPTIONS rtsp://192.168.31.115:8554/live RTSP/1.0\r\n
CSeq: 2\r\n
\r\n

客户端向服务器请求可用方法

  • S->C
RTSP/1.0 200 OK\r\n
CSeq: 2\r\n
Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY\r\n
\r\n

服务端回复客户端，当前可用方法OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY

2. DESCRIBE

  • C–>S
DESCRIBE rtsp://192.168.31.115:8554/live RTSP/1.0\r\n
CSeq: 3\r\n
Accept: application/sdp\r\n
\r\n

客户端向服务器请求媒体描述文件，格式为 sdp，客户端通过 Accept 头指定客户端可以接受的媒体述信息类型。

  • S–>C
RTSP/1.0 200 OK\r\n
CSeq: 3\r\n
Content-length: 146\r\n
Content-type: application/sdp\r\n
\r\n
// 这里为一个空行， 以下为具体的SDP信息//
v=0\r\n
o=- 91565340853 1 in IP4 192.168.31.115\r\n
t=0 0\r\n
a=contol:*\r\n
m=video 0 RTP/AVP 96\r\n
a=rtpmap:96 H264/90000\r\n
a=framerate:25\r\n
a=control:rtsp://192.168.31.115:8554/live/track0\r\n

服务器回复了 sdp 文件，这个文件告诉客户端当前服务器有哪些音视频流，有什么属性，sdp 具体稍后再讲解.

这里只需要直到客户端可以根据这些信息得知有哪些音视频流可以发送.

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

a)  通过DESCRIBE方法；

b)  其它一些协议（HTTP，email附件，等）；

c)  通过命令行或标准输入设备

3. SETUP

UDP 方式：需要发送两个端口信息

  • C–>S
SETUP rtsp://192.168.31.115:8554/live/track0 RTSP/1.0\r\n
CSeq: 4\r\n
Transport: RTP/AVP;unicast;client_port=54492-54493\r\n
\r\n

客户端发送建立请求，请求建立连接会话，准备接收音视频数据，请求的 URI 地址从上一步 sdp 的 control 属性 获得，如果已知该 URI，可以直接发起 SETUP 请求建立连接。

解析一下 Transport: RTP/AVP;unicast;client_port=54492-54493\r\n

  • RTP/AVP：表示 RTP 通过 UDP 发送，如果是RTP/AVP/TCP则表示 RTP 通过 TCP 发送

  • unicast：表示单播，如果是multicast则表示多播

  • client_port=54492-54493：由于这里希望采用的是 RTP OVER UDP，所以客户端发送了两个用于传输数据的端口，客户端已经将这两个端口绑定到两个 udp 套接字上，54492 表示是 RTP 端口，54493 表示 RTCP 端口(RTP 端口为某个偶数，RTCP 端口为 RTP 端口+1)，如果是 RTP/AVP/TCP 则可以不用 client_port 声明两个端口，直接复用该 RTSP 协议的端口，即整个过程只用到一个端口。

  • S–>C

RTSP/1.0 200 OK\r\n
CSeq: 4\r\n
Transport: RTP/AVP;unicast;client_port=54492-54493;server_port=56400-56401\r\n
Session: 66334873\r\n
\r\n

服务器端对 SETUP Request 产生一个Session Identifiers。

服务端接收到请求之后，得知客户端要求采用 RTP OVER UDP 发送数据，单播，客户端用于传输 RTP 数据的端口为 54492，RTCP 的端口为 54493

服务器也有两个 udp 套接字，绑定好两个端口，一个用于传输 RTP，一个用于传输 RTCP，这里的端口号为 56400-56401

之后客户端会使用 54492-54493 这两端口和服务器通过 udp 传输数据，服务器会使用 56400-56401 这两端口和这个客户端传输数据

4. PLAY

PLAY方法告知服务器通过SETUP中指定的机制开始发送数据。

在尚未收到SETUP请求的成功应答之前，客户端不可以发出PLAY请求。

PLAY请求将正常播放时间（npt=normal play time）定位到指定范围的起始处，并且传输数据流直到播放范围结束。

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

  • C–>S
PLAY rtsp://192.168.31.115:8554/live RTSP/1.0\r\n
CSeq: 5\r\n
Session: 66334873\r\n
Range: npt=0.000-\r\n
\r\n

客户端请求播放媒体

  • S–>C
RTSP/1.0 200 OK\r\n
CSeq: 5\r\n
Range: npt=0.000-\r\n
Session: 66334873; timeout=60\r\n
\r\n

服务器回复之后，会开始使用 RTP 通过 udp 向客户端的 54492 端口发送数据。如果是 TCP 方式建立的请求，则复用该 TCP 端口。

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

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

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

* Server 开始发送 RTP 数据

  • S-> C

    服务端发送 PLAY 响应后，立刻发送RTP媒体数据包。RTP 包格式请看下文。

* PAUSE

PAUSE 请求引起媒体流传输的暂时中断。如果请求 URL 中指定了具体的媒体流，那么只有该媒体流的播放和记录被暂停（halt）。比如，指定暂停音频，播放将会无声。如果请求 URL 指定了一组流，那么在该组中的所有流的传输将被暂停。如

  • C->S:
PAUSE rtsp://example.com/fizzle/foo RTSP/1.0
CSeq: 834
Session: 66334873
  • S->C
RTSP/1.0 200 OK
CSeq: 834
Date: 23 Jan 1997 15:35:06 GMT

PAUSE 请求中可能包含一个 Range 头用来指定何时媒体流暂停，我们称这个时刻为暂停点（pause point）。该头必须包含一个精确的值，而不是一个时间范围。媒体流的正常播放时间设置成暂停点。当服务器遇到在任何当前挂起（pending）的 PLAY 请求中指定的时间点后，暂停请求生效。如果 Range 头指定了一个时间超出了任何一个当前挂起的 PLAY 请求，将返回错误"457 Invalid Range" 。如果一个媒体单元（比如一个音频或视频禎）正好在一个暂停点开始，那么表示将不会被播放或记录。如果 Range 头缺失，那么在收到暂停消息后媒体流传输立即中断，并且暂停点设置成当前正常播放时间。

5. TEARDOWN

  • C–>S
TEARDOWN rtsp://192.168.31.115:8554/live RTSP/1.0\r\n
CSeq: 6\r\n
Session: 66334873\r\n
\r\n

  • S–>C

    服务端也可能不返回响应

RTSP/1.0 200 OK\r\n
CSeq: 6\r\n
\r\n

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

总结

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

SDP 协议格式

我们上面避开没有讲 sdp 文件，这里来好好补一补

协议说明

SDP(SessionDescription Protocol )会话描述协议，用于描述多媒体会话，它为会话通知、会话初始和其它形式的多媒体会话初始等操作提供服务。

SDP 的设计宗旨是通用性协议，所有它可以应用于很大范围的网络环境和应用程序，但 SDP 不支持会话内容或媒体编码的协商操作。

SDP 信息包括：

  • 会话名称和目标；
  • 会话活动时间；
  • 构成会话的媒体；
  • 有关接收媒体的信息、地址等。

Key-Value 字段说明

sdp 格式由多行的type=value组成，SDP 信息是文本信息，UTF-8 编码采用 ISO 10646 字符设置。

sdp 会话描述由一个会话级描述和多个媒体级描述组成。会话级描述的作用域是整个会话，媒体级描述描述的是一个视频流或者音频流.

  • 会话级描述由v=开始到第一个媒体级描述结束

  • 媒体级描述由m=开始到下一个媒体级描述开始之前

  1. SDP 会话描述如下（标注*符号的表示可选字段）

    • v= （协议版本）
    • o= （一系列会话参数）
    • s= （会话名称）
    • i=* （会话信息）
    • u=* （URI 描述）
    • e=* （Email 地址）
    • p=* （电话号码）
    • c=* （连接信息 ― 如果包含在所有媒体中，则不需要该字段）
    • b=* （带宽信息）

  2. 一个或更多时间描述

    • z=* （时间区域调整）
    • k=* （加密密钥）

  3. 时间描述

    • t= （会话活动时间）
    • r=* （0 或多次重复次数）

  4. 0 个或多个媒体描述

    • m= （媒体名称和传输地址）
    • i=* （媒体标题）
    • c=* （连接信息 — 如果包含在会话层则该字段可选）
    • b=* （带宽信息）
    • k=* （加密密钥）
    • a=* （0 个或多个会话属性线路）

SDP 示例

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)
b=AS:5050
c=IN IP4 224.2.17.12/127
t=2873397496 2873404696
a=recvonly
m=audio 49170 RTP/AVP 0
m=video 51372 RTP/AVP 31
m=application 32416 udp wb
a=orient:portrait
a=rtpmap:96 H264/90000
a=control:rtsp://10.86.77.14:554/h264/ch1/sub/av_stream/trackID=1


//字段解释
V=0     ;Version 给定了SDP协议的版本
 o=<用户名> <会话id> <会话版本> <网络类型><地址类型> <地址>
<address>； Origin ,给定了会话的发起者信息
s=<sessionname> ;给定了Session Name
i=<sessiondescription> ; Information 关于Session的一些信息
u=<URI> ; URI
b=<modifier>:<value>; AS:5050：带宽5050 kb/s
e=<emailaddress>    ;Email
c=<networktype> <address type> <connection address> ;Connect Data包含连接数据
t=<会话起始时间> <结束时间>
a=<属性>:<值>
m=<媒体类型> <端口号> <传输协议> <媒体格式
a=rtpmap:96 H264/90000
格式为a=rtpmap:<媒体格式><编码格式>/<时钟频率>
a=framerate:25
表示帧率
a=control:rtsp://10.86.77.14:554/h264/ch1/sub/av_stream/trackID=1
表示这路视频流在这个会话中的编号

RTP 协议

RTP 包格式

rtp 包由 rtp 头部和 rtp 荷载构成

RTP 固定头部

rtpHeader

  • 版本号(V)：

    2Bit，用来标志使用 RTP 版本，当前协议版本号为 2。

  • 填充位§：

    1Bit，若 P=1 则在该报文的尾部填充一个或多个额外的八位组，数值为一串 0，它们不是有效载荷的一部分，表示报文对齐。RTP 报文的最后一个字节（8bit) 指明可以忽略多少个填充比特，填充可能用于某些具有固定长度的加密算法，或者用于在底层数据单元中传输多个 RTP 包。当一个 TCP 报文 携带多个 RTP 包的时候，由于每个 RTP 包的载荷长度不固定，RTP 报文需要将长度填充为 8 的倍数，即填充一串 0，来方便报文解析。

  • 扩展位(X)

    1Bit，若 X=1，则在 RTP 报头后跟有一个扩展头。

  • CSRC 技术器(CC)：

    4Bit，含有固定头部后面跟着的 CSRC 的数据, 指示 CSRC 标识符的个数

  • 标记位(M)：

    1Bit，不同的有效载荷有不同的含义，对于视频，标记一帧的结束；对于音频，标记会话的开始。

  • 载荷类型(PT)：

    7Bit，标识了 RTP 载荷的类型，如 GSM 音频、JPEM 图像等。

    注：rfc 里面对一些早期的格式定义了这个 payload type。但是后来的，如 h264 并没有分配，那就用 96 来代替。因此现在 96 以上都不表示特定的格式，具体表示什么要用 sdp 或者其他协议来协商。

  • 序列号(SN)：

    16Bit，序列号的初始值是随机的， 发送方在每发送完一个 RTP 包后就将该域的值增加 1，接收者用序列号来检测报文丢失，排序报文，恢复数据。

  • 时间戳：

    32 比特，反映该 RTP 报文的第一个八位组的采样时刻。接收者使用时戳来计算延迟和延迟抖动，并进行同步控制。时钟频率依赖于负载数据格式，并在描述文件（profile）中进行描述。也可以通过 RTP 方法对负载格式动态描述。

  • 同步源标识符(SSRC)：

    32 比特，同步源就是 RTP 包源的来源。该标识符是随机选择的，在同一个 RTP 会话中不能有两个相同的 SSRC 值。参加同一视频会议的两个同步信源不能有相同的 SSRC。

  • 贡献源列表(CSRC List)：

    可以有 0 ～ 15 个，每个 32 比特，这个不常用。

    每个 CSRC 标识了包含在该 RTP 报文有效载荷中的所有特约信源。CSRC 识别符由混合器插入，并列出所有贡献源的 SSRC 识别符。

    在共流源标识并且没有拓展头部（X=0）的情况下，RTP 头部为 12 个字节。

//RTP固定头
typedef struct RTP_FIXED_HEADER{
	/* byte 0 */
	unsigned char csrc_len:4;       /* expect 0 */
	unsigned char extension:1;      /* expect 1 */
	unsigned char padding:1;        /* expect 0 */
	unsigned char version:2;        /* expect 2 */
	/* byte 1 */
	unsigned char payload:7;
	unsigned char marker:1;        /* expect 1 */
	/* bytes 2, 3 */
	unsigned short seq_no;
	/* bytes 4-7 */
	unsigned  long timestamp;
	/* bytes 8-11 */
	unsigned long ssrc;            /* stream number is used here. */
} RTP_FIXED_HEADER;

RTP 荷载 Payload

rtp 载荷为压缩编码过的压缩编码过的音频或者视频数据。

RTP 拓展头部

RTP 提供拓展机制以允许实现个性化，某些与常规负载格式功能要求相独立的附加信息在 RTP 拓展头的定义中实现。

rtpExample

若 RTP 固定头中的扩展标志位 X 置 1，则一个长度可变的扩展头部分被加到 RTP 固定头之后。扩展包含 16 比特的长度域，指示扩展项中 32 比特字的个数，不包括 4 个字节扩展头(因此零是有效值)。RTP 固定头之后只允许有一头个头扩展。为了使拓展头具有特定的含义,扩展头的前 16 比特用来作为特定含义的识别标识符或参数。这 16 比特的格式由具体实现的上层协议定义。基本的 RTP 说明并不定义任何头扩展本身。

RTP 规格级别(profile)

profile 定义了一系列负载类型和对应的负载格式，也定义了特定于具体应用的 RTP 扩展和修改。典型地，某个应用仅基于一个规格级别运行。IETF 针对 RFC3550 在档次方面定义了一系列扩展协议。

rtpExample

RFC3551(RTP/AVP)在 RFC3550 的基础上针对 RTP 档次进行补充形成 RTP/APVP 档次，被用在具有最小会话控制的音视频会议中，是其它扩展档次的基础。该档次在没有参数协商和成员控制的会话中非常有用。该档次也为音视频定义一系列编码和负载格式。对于具体的流媒体负载格式，IETF 也定义一系列协议详细描述，如 VP8 视频负载格式[6]和 H264 视频负载格式[7]，等等。

RFC3711(SRTP，也即 RTP/SAVP)是 RTP/AVP 在安全方面进行扩展形成的档次，为 RTP/RTCP 提供数据加密、消息认证、重放保护等功能。SRTP 具有高吞吐量和低数据膨胀等特点，是异构环境下对 RTP/RTCP 数据的有效保护。

RFC4585(RTP/AVPF)是 RTP/AVP 在及时反馈方面进行扩展形成的档次，使得接收端能够向发送端提供及时反馈，实现短时调整和基于反馈的修复机制。该协议定义早期 RTCP 报文以实现及时反馈，并定义一系列通用 RTCP 反馈报文和特定于应用的反馈报文，如 NACK、PLI、SLI、RPSI 等。

RFC5124(RTP/SAVPF)则是 RTP/SAVP 和 RTP/AVPF 的综合。SAVP 和 AVPF 在使用时，需要参与者借助于 SDP 协议[8]就档次和参数信息达成一致。但是对一个 RTP 会话来说，这两种档次不能同时被协商。而实际应用中，我们有同时使用这两种档次的需要。因此，RTP/SAVPF 档次应运而生，它能够使得 RTP 会话同时具有安全和及时反馈两方面的特性。

3.2 RTP OVER TCP

RTP 默认是采用 UDP 发送的，格式为 RTP 头+RTP 载荷，如果是使用 TCP，那么需要在 RTP 头之前再加上四个字节

  • 第一个字节：Magic(0x24)–辨识符

  • 第二个字节：Channel–通道，在 SETUP 的过程中获取

  • 第三第四个字节：Length–RTP 包(头部+载荷）的大小，最多只能 12 位，第三个字节保存高 4 位，第四个字节保存低 8 位

RTP OVER TCP 包示例

说明

本人使用 Wireshark 抓包工具，开始监听网口后，用 openCV 的 VideoCapture() 方法播放了一个网络摄像头的画面，代码如下。（按 q 退出播放）

import cv2
cap = cv2.VideoCapture('rtsp://admin:admin777@10.86.77.14:554/h264/ch1/sub/av_stream')

while (1):
    ret, img = cap.read()
    if not ret:
        print("Can't receive frame (stream end?). Exiting ...")
        break
    cv2.imshow("Image", img)
    if cv2.waitKey(1) & 0xFF == ord('q'):
        break
cap.release()  # 释放摄像头
cv2.destroyAllWindows()  # 释放窗口资源

如下是整个 RTSP 通信流程的 Wireshark 抓包界面，我们看到第一个 RTP 包的序号（SN），是随机的 64758，第一个报文展开后看到其携带了 3 个 RTP 包，所以下一个报文的序号是 64758 + 3 = 64761

rtpExample

一个报文中可以携带多个 RTP 包， 如下图显示为 3 个 RTP 包，每个包的序列号递增。
rtpExample

继续展开第一组 RTP 包

rtpExample

字段含义：

  • 版本 V=2
  • P=1 ，尾部填充对齐
  • X=0，无扩展头
  • M=0， 视频流的帧未结束。
  • PT=96：查阅RFC3551, 为 dynamicRTP 类型
  • SN=64758：包序列号
  • TimeStamp：2794043652 ，时间戳
  • PayLoad：载荷
  • Padding count=1：载荷最后有 1 个 0 是填充上去的。

RTCP 协议

RTCP 需要与 RTP 协议一起配合使用，当应用程序启动一个 RTP 会话时将同时占用两个端口（复用情况下占用同一个端口），分别供 RTP 和 RTCP 使用。RTP 本身并不能为数据包提供可靠传输的保证，也不提供流量控制和拥塞控制，这些都由 RTCP 来负责完成。通常 RTCP 会采用与 RTP 相同的分发机制，向会话中的所有成员周期性地发送控制信息，应用程序通过接收这些数据，从中获取会话参与者的相关资料，以及网络状况、分组丢失概率等反馈信息，从而能够对服务质量进行控制或者对网络状况进行诊断。

更多介绍

RTCP 功能概括

RTCP 的主要功能可以概括为 3 个方面，服务质量的监视与反馈、媒体间的同步、多播组中成员的标识。此外还可以进行丢包重传或者 I 帧重传的控制。下面是消息类型

TypeDescriptionReferences
0-191
192FIR, full INTRA-frame request.RFC 2032
193NACK, negative acknowledgement.RFC 2032
194SMPTETC, SMPTE time-code mapping.RFC5484
195IJ,extended inter-arrival jitter report.RFC 5450
196-199
200SR, sender report.RFC 3550
201RR, receiver report.RFC 3550
202SDES, source description.RFC 3550
203BYE, goodbye.RFC 3550
204APP, application defined.RFC 3550
205RTPFB, Generic RTP Feedback.
206PSFB, Payload-specific Feedback.
207XR, RTCP extension.RFC 3611
208AVB, AVB RTCP packet.IEEE 1733
209RSI, Receiver Summary Information.RFC 5760
210-255

其中以发送者报告举例

rtcp

  • 版本(V)：同 RTP 包头域.
  • 填充§：同 RTP 包头域.
  • 接收报告计数器(RC)：5 比特, 该 SR 包中的接收报告块的数目, 可以为零.
  • 包类型(PT)：8 比特, SR 包是 200.
  • 长度域(Length)：16 比特, 其中存放的是该 SR 包以 32 比特为单位的总长度减一.
  • 同步源(SSRC)：SR 包发送者的同步源标识符, 对应 RTP 包中的 SSRC 一样.
  • NTP timestamp：SR 包发送时的绝对时间值, NTP 的作用是同步不同的 RTP 媒体流, 一共 8 个字节，前 4 个字节代表
  • RTP timestamp：与 NTP 时间戳对应, 与 RTP 数据包中的 RTP 时间戳具有相同的单位和随机初始值.
  • Sender’s packet count：从开始发送包到产生这个 SR 包这段时间里, 发送者发送的 RTP 数据包的总数, SRC 改变时这个域清零.
  • Sender’s octet count：从开始发送包到产生这个 SR 包这段时间里, 发送者发送的净荷数据的总字节数(不包括头部和填充), 发送者改变其 SSRC 时这个域要清零.
  • 同步源 n 的 SSRC 标识符：该报告块中包含的是从该源接收到的包的统计信息.
  • 丢失率(Fraction Lost)：表明从上一个 SR 或 RR 包发出以来从同步源 n(SSRC_n)来的 RTP 数据包的丢失率.
  • 累计的包丢失数目：从开始接收到 SSRC_n 的包到发送 SR, 从 SSRC_n 传过来的 RTP 数据包的丢失总数.
  • 收到的扩展最大序列号：从 SSRC_n 收到的 RTP 数据包中最大的序列号.
  • 接收抖动(Interarrival jitter)：RTP 数据包接受时间的统计方差估计.
  • 上次 SR 时间戳(Last SR,LSR)：取最近从 SSRC_n 收到的 SR 包中的 NTP 时间戳的中间 32 比特, 如果目前还没收到 SR 包, 则该域清零.
  • 上次 SR 以来的延时(Delay since last SR,DLSR)：上次从 SSRC_n 收到 SR 包到发送本报告的延时.

参考：

RFC 文档：

wanzheng_96
关注
  • 0
    点赞
  • 踩
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
EasyPlayer-RTSP-Windows
01-12
rtsp播放器，同时支持OSD显示，最大支持64个画面同时显示
node-rtsp-stream-es6：流传输任何RTSP流并将其输出到websocket以供jsmpeg使用
02-05
节点-rtsp-stream-es6 首先，这是的分支 与原始模块的差异 用ES6代替CoffeeScript写 Github仓库 描述 流式传输任何RTSP流并将其输出到以供。 HTML5流视频！ 要求 您需要下载并安装 。 安装 npm i node-rtsp-stream-es6 服务器 const Stream = require ( 'node-rtsp-stream-es6' ) const options = { name : 'streamName' , url : 'rtsp://184.72.239.149/vod/mp4:BigBuckBunny_115k.mo
rtsp 协议 相关
visualdancing
09-24 332
资料  rtsp 协议与应用 http://wenku.baidu.com/link?url=shyACW3cGouh-GhnBpHWOFoj7If2B6ftYamdqdmCKwrIbWza9RPy9_QGN99Mr9KFqehj0w5KvBse3WLmBRjRgSxFgV7mJUOJF_ZKNVS73jm###
流媒体协议RTSP末篇之RTP（三）
weixin_42764231的博客
11-30 694
RTP协议分析
RTP 基于UDP和TCP协议传输数据的详解以及RTSP协议请求流程详解
qq_23552895的博客
03-06 4358
1、RTP over RTSP(TCP)优势 对于RTP包为什么用TCP来传输： ①UDP协议上的RTSP/RTP需要打开许多UDP端口,一个端口用于RTSP通信，n个端口用于RTP，n个端口用于RTCP ②中间网络路由器很容易就过滤或者忽略掉UDP数据包 ③UDP是不可靠传输协议，媒体包在因特网上传输时会面临着丢包 2、RTP over RTSP(TCP) 与 RTP over RTSP(...
流媒体协议详解：RTSP、RTP、RTCP、SIP、SDP、RTMP、WebRTC、WebSocket
zzhongcy的专栏
07-18 7039
流媒体相关著名项目1.1、多媒体信息的数据量往往很大例如音频：标准的PCM编码的立体声音乐(采样速率44.1kHz，采样脉冲16位编码)信号的比特率超过了1.4Mbit/s。例如视频：分辨率1280×720，每个像素采用24位RGB编码，帧率24fps，则其比特率将超过60Mbit/s。因此网络传输多媒体信息都无一例外地采用各种压缩技术，如MP3(128kbit/s)，MP4(40Mbit/s).
RTSP 协议漫谈，揭秘 RTSP 协议内幕
洪伟的专栏
12-09 1134
RTP 协议是为流媒体端到端的实时传输而设计的。该协议提供了抖动补偿和数据包丢失和乱序的检测功能，这些在 IP 网络上的 UDP 传输中很常见。RTP 允许通过 IP 组播将数据传输到多个目的地。RTP 被认为是 IP 网络中音频/视频传输的主要标准，并与相关的配置文件和有效载荷格式一起使用。RTP 的设计基于被称为应用层分帧的架构原则，其中协议功能在应用程序中实现，而不是在操作系统的协议栈中实现。实时多媒体流应用要求信息的及时传递，通常可以容忍一些丢包来达到这一目的。
基于车载以太网的音视频传输 AVB vs RTP
Life_I的博客
01-20 4078
基于车载以太网的音视频传输 AVB vs RTP背景方案选择RTPAVB结束语 背景 问：近些年，随着智能驾驶技术的发展和车内影音娱乐系统的丰富，越来越多的音视频数据需要在车内网络进行传输。现在车载以太网日渐成熟，那么，我们可以使用车载以太网在车内网络传输音视频数据吗？ 王师傅：答案是肯定的。而且由于成本、传输带宽等方面的因素，在有些场景下，也许只有车载以太网才能满足我们的传输需求。 问：既能传输普通数据又能传输音视频数据，感觉很方便啊。那么，传输音视频数据和其他普通数据采用的传输协议相同吗？ 王师傅：是不
基于实时传输控制协议 (RTCP) 的反馈 (RTP/AVPF) 的扩展 RTP 配置文件 （RFC-4585）
qq_33743182的博客
10-13 1018
本备忘录的状态
汽车以太网：AVB/TSN网络，IEEE_1733协议详解
Rimo_X的博客
08-04 1023
本文详细解读了IEEE 1733协议，包含协议英文原文和中文翻译，加上自己的理解。
rtmp-rtsp-stream-client-java
05-21
Android rtmp rtsp 推流客户端
rtsp-simple-server：即用型RTSPRTMP服务器和代理，允许读取，发布和代理视频和音频流
02-04
rtsp-简单服务器 rtsp-simple-server是一个简单，易于使用且零依赖的RTSP / RTMP服务器和代理，该软件允许用户发布，读取和代理实时视频和音频流。 RTSP是一个规范，描述了如何在服务器的帮助下执行这些操作，发布者...
EasyPlayer-RTSP-iOS-master.zip
02-10
EasyPlayer-RTSP- iOS源码，喜欢的欢迎下载。EasyPlayer RTSP是一款精炼、高效、稳定的RTSP流媒体播放器，视频支持H.264/H.265，音频支持G.711/G.726/AAC，支持RTP over UDP/TCP两种模式！
TCP/IP协议族中的TCP（二）：解析其关键特性与机制
希望自己从编程小白变成大佬
04-27 525
接收端（相当于超市老板）在收到数据包后，并不立即发送ACK确认报文（相当于告诉供货员需要多少箱冰红茶），而是等待一段时间，看看是否还有更多的数据包到达，或者根据自身的处理能力来决定是否可以接收更多的数据。这样做的好处是，通过一个报文同时完成了数据的确认和响应的发送，减少了网络中的传输次数，从而提高了网络的整体效率。例如，当接收方处理数据的速度远远跟不上发送方的发送速度时，为了防止数据溢出，接收方可能会将窗口大小调整为0，即告诉发送方暂停发送数据，直到接收方处理完当前数据并准备好接收新数据为止。
nginx配置ip_hash负载均衡策略
na_tion的专栏
04-24 264
nginx ip_hash算法介绍
Java 网络编程之TCP(五)：分析服务端注册OP_WRITE写数据的各种场景（二）
u013771019的专栏
04-24 156
2.注册OP_WRITE时：是使用key.interestOps(key.interestOps() + SelectionKey.OP_WRITE);在OP_WRITE事件来的时候，要把先把OP_WRITE事件去掉，key.interestOps(key.interestOps() & ~SelectionKey.OP_WRITE);3.注册OP_WRITE时，要写的数据，直接给到了原来channel对应的attachment里了；1.在注册OP_WRITE时，需要给所有其他客户端注册；
网络通信协议，UDP和TCP，初步了解
最新发布
wwwithin的博客
04-27 633
TCP 是一种面向连接的协议，它提供了可靠的、有序的数据流传输服务。TCP 在通信开始之前需要进行握手过程，建立起连接后，它通过序号和确认号来保证数据的可靠性、有序性和完整性。TCP 还实现了流量控制和拥塞控制机制，以确保网络的稳定性和公平性。TCP 适用于对数据可靠性和顺序性要求较高的应用场景，如网页浏览、文件传输和电子邮件。UDP 是一种简单的无连接协议，它提供了数据包的传输服务，但不提供像 TCP 那样的可靠性和错误检测机制。
SpringCloud系列（13）--Eureka服务名称修改和服务IP显示
m0_64284147的博客
04-24 729
在上一章节中我们把服务提供者做成了集群，而本章节则是一些关于服务信息的配置，这部分知识对集群整体影响不大，不过最好还是掌握，毕竟万一有用到的地方呢。
TCP/IP协议族中的TCP（一）：解析其关键特性与机制
希望自己从编程小白变成大佬
04-27 763
TCP（Transmission Control Protocol，传输控制协议）是一种面向连接的、可靠的、基于字节流的传输层通信协议。它是互联网协议族（TCP/IP协议族）中的重要组成部分，旨在适应支持多网络应用的分层协议层次结构。在不同的计算机通信网络的主计算机之间，TCP为各种进程提供可靠的通信服务。TCP协议的重要性在于其保证了数据在传输过程中的可靠性、顺序性和无差错。
linux运行rtsp-simple-server
03-26
1.下载并安装rtsp-simple-server 您可以从https://github.com/aler9/rtsp-simple-server/releases 下载适用于您的操作系统的rtsp-simple-server。 对于Ubuntu或Debian用户，可以使用以下命令下载和安装： ``` ...

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

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

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值