流媒体-RTP-RTCP协议解析-RTSP流的传输与控制（二）

已于 2023-02-08 21:56:17 修改
阅读量2.3k 收藏 9
点赞数 3
分类专栏： 流媒体 文章标签： 流媒体 RTSP流传输与控制 RTP RTCP
于 2021-01-23 16:58:03 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/bwangk/article/details/113058155
版权
  1. 流媒体-RTSP协议-live555学习-打开RTSP流（一）
  2. 流媒体-RTP-RTCP协议解析-RTSP流的传输与控制（二）

文章目录

RTP(real-time transport protocol),实时传输协议

相关概念

RTP 在多点传送(多播)或单点传送(单播)的网络服务上,提供端对端的网络传输功能,适合应用程序传输实时数据,如:音频,视频或者仿真数据。RTP没有为实时服务提供资源预留的功能,也不能保证QoS(服务质量)。数据传输功能由一个控制协议(RTCP)来扩展,通过扩展,可以用一种方式对数据传输进行监测控制,该协议(RTCP)可以升级到大型的多点传送(多播)网络,并提供最小限度的控制和鉴别功能。RTP 和 RTCP 被设计成和下面的传输层和网络层无关。协议支持 RTP 标准的转换器和混合器的使用。

同步源(SSRC,Synchronization source)

RTP 包流的源,用 RTP 报头中 32 位数值的 SSRC 标识符进行标识,使其不依赖于网络地址。一个同步源的所有包构成了相同计时和序列号 空间的一部分,这样接收方就可以把一个同步源的包放在一起,来进行重放。举些同步源的例子,像来自同一信号源的包流的发送方,如麦克风、摄影机、RTP 混频器(见下文)就是同步源。一个同步源可能随着时间变化而改变其数据格式,如音频编码。SSRC 标识符是一个随机选取的值,它在特定的 RTP 会话中是全局唯一(globally unique)的。参与者并不需要在一个多媒体会议的所有 RTP 会话中,使用相同的 SSRC 标识符;SSRC 标识符的绑定通过RTCP(见章节 6.5.1)。如果参与者在一个 RTP 会话中生成了多个流,例如来自多个摄影机,则每个摄影机都必须标识成单独的同步源。

作用源(CSRC,Contributing source )

若一个 RTP 包流的源,对由 RTP 混频器生成的组合流起了作用,则它就是一个作用源。对特定包的生成起作用的源,其 SSRC 标识符组成的列表,被混频器插入到包的 RTP 报头中。这个列表叫做 CSRC 表。相关应用的例子如,在音频会议中,混频器向所有的说话人(talker)指出,谁的话语(speech)将被组合到即将发出的包中,即便所有的包都包含在同一个(混频器的)SSRC 标识符中,也可让听者(接收者)可以清楚谁是当前说话人。

混频器和转换器(Mixers and Translators)

混频器(Mixer)：一种中间系统,它从一个或多个源中接收 RTP 包,可能改变其数据格式,再按某种方式把这些包组合成一个新的包,然后转发出去。由于多个输入源的计时一般不会同步,所以混频器会对各个流的计时作出调整,并为组合流生成一个新的计时。因此,混频器将被标识成它所产生所有数据包的同步源。

转换器(Translator)：一种中间系统,它转发 RTP 包而不改变各包的同步源标识符。转换器的例子如下:不作混频地转变编码的设备,把多播复制到单播的重复装置,以及防火墙里应用层次的过滤器。

考虑一下这种情况,一个地方的参与者只能低速接入会议,而其他大部分参与者都能享受高速连接。与其让强迫大家都忍受低带宽,不如在只能低速接入的地方,放置一个减质量音频编码的RTP层次的中继(称作混频器)。混频器将重新同步输入的音频包,重建发送方产生的20ms固定间隔,混频已重建过的音频流为单一的流,转换音频编码为低带宽格式,最后通过低带宽连接转发数据包流(package stream)。这些包可能被单播到一个接收方,也可能多播到另一个的地址而发给多个接收方。RTP 报头为混频器提供了一种方法,使其能辨识出对混频后的包有用的源,从而保证提供给接收方正确的说话者指示。

在音频会议中,一些预定参与者尽管有高带宽连接,但不能通过IP多播直接接入会议。例如,他们可能位于一个不允许任何 IP 包通过的应用层防火墙后面。对这些站点,可能就不需要混频,而需要另一种称为转换器的RTP层次中继。可以在防火墙两侧分别安装一个转换器,外侧转换器将所有多播包通过安全连接转入内侧转换器,
内侧转换器再转发给内部网的一个多播组(multicast group)。

混频器和转换器可以设计成用于各种目的。比如,一个视频混频器在测量多个不同视频流中各人的单独影像后,将它们组合成一个单一视频流来模拟群组场景。又如,在只用 IP/UDP和只用ST_II的两个主机群之间通过转换建立连接。再如,在没有重新同步或混频时,用packet-by-packet 编码转换来自各个独立源的视频流。

RTP 负载（RTP payload）

通过 RTP 传输的包中的数据，例如，音频样本或压缩好的视频数据。RTP负载由RTP负载头和RTP负载数据构成。

  1. [负载参数：Real-Time Transport Protocol (RTP) Parameters]：
  • RTP Payload Types (PT) for standard audio and video encodings - Closed:0-127，其中：
PT 值状态
0-34已分配
35-71Unassigned
72-76Reserved for RTCP conflict avoidance
77-95Unassigned
96-127dynamic
  • RTCP Control Packet Types (PT)
PT 值-说明
1-191Specification Required or Expert Review-
194-199Specification Required or Expert ReviewIf 200-223 is fully occupied
200-223Specification Required or Expert ReviewPrimary Assignments range
224-254Specification Required or Expert Review-
RTP 包（RTP packet）

一种数据包，其组成部分有：一个固定 RTP 报头（12字节），一个可能为空的作用源（contributing sources）列表，以及RTP负载。

RTP 包解析

RTP 包头格式
0                  1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X|   CC  |M|     PT      |         sequence number       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            timestamp                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            synchronization source (SSRC) identifier           |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|             contributing source (CSRC) identifiers            |
|                             ....                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

前 12 个字节出现在每个 RTP 包中,仅仅在被混合器插入时,才出现 CSRC 识别符列表。这些域有以下意义:

类型长度（位）描述
版本(V)2 bits此域定义了 RTP 的版本。此协议定义的版本是 2。(值 1 被 RTP 草案版本使用,值 0 用在最初"vat"语音工具使用的协议中。)
填充§1 bits若填料比特被设置,则此包包含一到多个附加在末端的填充比特,填充比特不算作负载的一部分。填充的最后一个字节指明可以忽略多少个填充比特。填充可能用于某些具有固定长度的加密算法,或者用于在底层数据单元中传输多个 RTP 包。
扩展(X)1 bits若设置扩展比特,固定头(仅)后面跟随一个头扩展。
CSRC 计数(CC)4 bitsCSRC 计数包含了跟在固定头后面 CSRC 识别符的数目。
标志(M)1 bits标志的解释由具体协议规定。它用来允许在比特流中标记重要的事件,如对于视频，标记一帧的结束；对于音频，标记会话的开始
负载类型(PT)7 bits此域定义了负载的格式,由具体应用决定其解释。协议可以规定负载类型码和负载格式之间一个默认的匹配。其他的负载类型码可以通过非 RTP 方法动态定义（如H264使用96）。 RTP发送端在任意给定时间发出一个单独的 RTP 负载类型;此域不用来复用不同的媒体流。
序列号(sequence number)16 bits每发送一个 RTP 数据包,序列号加 1,接收端可以据此检测丢包和重建包序列。序列号的初始值是随机的(不可预测),以使即便在源本身不加密时(有时包要通过翻译器,它会这样做),对加密算法泛知的普通文本攻击也会更加困难。
时间戳(timestamp)32 bits时间戳计算的单位不是秒之类的单位，而是由采样频率所代替的单位，这样做的目的就是为了是时间戳单位更为精准，时间戳反映了 RTP 数据包中第一个字节的采样时间，在一次会话开始时的时间戳初值也是随机选择的。时钟频率依赖于负载数据格式,并在描述文件(profile)中进行描述。也可以通过 RTP 方法对负载格式动态描述。
SSRC32 比特用以识别同步源。标识符被随机生成,以使在同一个 RTP 会话期中没有任何两个同步源有相同的 SSRC 识别符。尽管多个源选择同一个 SSRC 识别符的概率很低,所有RTP实现工具都必须准备检测和解决冲突。若一个源改变本身的源传输地址,必须选择新的SSRC识别符,以避免被当作一个环路源
CSRC 列表0 到 15项,每项32 bitsCSRC列表识别在此包中负载的所有贡献源。识别符的数目在 CC 域中给定。若有贡献源多于 15 个,仅识别 15 个。CSRC 识别符由混合器插入,并列出所有贡献源的SSRC识别符。例如语音包,混合产生新包的所有源的SSRC标识符都被列出,以在接收端处正确指示参与者
RTP 头扩展

RTP扩展头:rtc8285:A General Mechanism for RTP Header Extensions，可以同时扩展为1或2个字节

RTP 提供扩展机制以允许实现个性化:某些新的与负载格式独立的功能要求的附加信息在RTP 数据包头中传输。设计此方法可以使其它没有扩展的交互忽略此头扩展。RTP 头扩展的格式如下所示。

0                  1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      defined by profile       |             length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         header extension                      |
|                             ....                              |

若 RTP 头中的扩展比特位置 1,则一个长度可变的头扩展部分被加到 RTP 固定头之后，RTP固定头之后只允许有一个头扩展。为允许多个互操作实现独立生成不同的头扩展,或某种特定实现有多种不同的头扩展：

类型长度描述
识别标识符或参数16 bits这16 bits 的格式由具体实现的上层协议定义。基本的RTP明并不定义任何头扩展本身。
长度域(length)16 bits指示扩展项中 32 bits 字的个数,不包括 4 个字节扩展头(因此零是有效值)。

RTCP（RTP 控制协议）

RFC版本号名称备注
3550RTP: A Transport Protocol for Real-Time Applications (RTP/AVP)
-SR: Sender report, for transmission and reception statistics from participants that are active senders
-RR: Receiver report, for reception statistics from participants that are not active senders and in combination with SR for active senders reporting on more than 31 sources
-SDES: Source description items, including CNAME
-BYE: Indicates end of participation
-APP: Application-specific functions
现用RTP协议,定义RTP和RTCP协议的最基本内容
4585Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)
- Transport layer FB messages:(RTPFB/205)
0: unassigned
1: Generic NACK
2-30: unassigned
31: reserved for future expansion of the identifier number space
- Payload-specific FB messages:(PSFB/206)
0: unassigned
1: Picture Loss Indication (PLI)
2: Slice Loss Indication (SLI)
3: Reference Picture Selection Indication (RPSI)
4-14: unassigned
15: Application layer FB (AFB) message
16-30: unassigned
31: reserved for future expansion of the sequence number space
- Application layer FB messages		增加了 feedback NACK等定义，通过实时的RTCP进行丢包重传
5104Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)
-Transport Layer Feedback Messages
Assigned in AVPF [RFC4585]:
1:Generic NACK
31:reserved for future expansion of the identifier number space
Assigned in this memo:
2:reserved (see note below)
3:Temporary Maximum Media Stream Bit Rate Request (TMMBR)
4:Temporary Maximum Media Stream Bit Rate Notification (TMMBN)
- Payload-specific FB messages:(PSFB/206)
Assigned in [RFC4585]:
1: Picture Loss Indication (PLI)
2: Slice Lost Indication (SLI)
3: Reference Picture Selection Indication (RPSI)
15: Application layer FB message
31: reserved for future expansion of the number space
Assigned in this memo:
4: Full Intra Request (FIR)
5: Temporal-Spatial Trade-off Request (TSTR)
6: Temporal-Spatial Trade-off Notification (TSTN)
7: Video Back Channel Message (VBCM)
Unassigned:
0: unassigned
8-14: unassigned
16-30: unassigned
基于4585实时RTCP消息，来控制音视频编码器
3611RTP Control Protocol Extended Reports (RTCP XR)
BT name
– ----
1 Loss RLE Report Block
2 Duplicate RLE Report Block
3 Packet Receipt Times Report Block
4 Receiver Reference Time Report Block
5 DLRR Report Block
6 Statistics Summary Report Block
7 VoIP Metrics Report Block
RTCP的拓展报文即XR报文定义

rfc3550：RTP: A Transport Protocol for Real-Time Applications

SR并不是发送者发送多少包告诉对方，而是发送者这端接收了多少包，接收过程中丢了多少包。将这些信息传送给对端。
所以SR包含两个信息，将发送者自己发送的信息告诉对端，同时将自己接收的信息也告诉对端。而RR是当报文发送方只作为接收者，而不发送媒体数据时，发给对端自己作为接收方接收到的数据的统计信息

类型名称描述
200SR（Sender Report）发送者报告：描述作为活跃发送者成员的发送和接收统计数字
201RR（Receiver Report）接收者报告：描述非活跃发送者成员的接收统计数字
202SDES（Source Description Items）源描述项：其中包括规范名 CNAME
203BYE结束传输：表明参与者将结束会话
204APP应用描述功能
SR（Sender Report）
0                  1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|    RC   |   PT=SR=200   |              length           |头部8字节==》版本(V)|填充(P)|接收报告块计数(RC）|包类型(PT)|长度
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        SSRC of sender                         |SR 包发送者的同步源标识符
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|               NTP timestamp, most significant word            |发送者信息20字节==》NTP 时间戳8字节
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               NTP timestamp, least significant word           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          RTP timestamp                        |RTP 时间戳
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        sender's packet count                  |发送的报文数
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         sender's octet count                  |发送的字节数
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|                 SSRC_1 (SSRC of first source)                 |接收报告块==》SSRC_n(同步源标识符)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| fraction lost |       cumulative number of packets lost       |丢包率 | 累计包丢失数
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           extended highest sequence number received           |接收到的扩展的最高序列号
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      interarrival jitter                      |到达间隔抖动
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           last SR (LSR)                       |上一 SR 报文
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    delay since last SR (DLSR)                 |自上一 SR 的时间
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|                SSRC_2 (SSRC of second source)                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              ...                              |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|                   profile-specific extensions                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
第一部分：头部（8字节）
类型长度描述
版本(V)2 bitsRTP 版本识别符,在 RTCP 包内的意义与 RTP 包中的相同。此协议中定义的版本号为 2。
填充§1 bits若设置填充比特,该RTCP包在末端包含一些附加填充比特,并不是控制信息的基本部分。填充的最后一个比特统计了多少个字节必须被忽略。填充可能会用于需要固定长度块的加密算法。在复合 RTCP 包中,复合包作为一个整体加密,填料比特只能加在最后一个单个 RTCP 包的后面。
接收报告块计数(RC)5 bits特该包中所含接收报告块的数目。零值有效。
包类型(PT)8 bits包含常数 200,用以识别这个为 SR 包。
长度16 bits该 RTCP 包的长度减 1。其单位是 32 比特字,包括头和任何填充字节。(偏移量 1 保证零值有效,避免了在扫描 RTCP 包长度时可能发生的无限循环,同时以 32 比特为单位避免了对以 4 为倍数的有效性检测。)
SSRC32 bitsSR 包发送者的同步源标识符。
第二部分：发送者信息（20 字节）

在每个发送者报告包中出现。它概括了从此发送者发出的数据传输情况。此域有以下意义:

类型长度描述
NTP 时间戳64 bits网络时间戳，用于音视频同步，64 位时间戳也叫NTP时间戳，它的前32位是从1900 年1 月1 日0 时开始到现在的以秒为单位的整数部分，后32 位是此时间的小数部，因此，它可以肯定的表示了数据发送出去的绝对时间，指示了此报告发送时的背景时钟(wallclock)时刻,它可以与从其它接收者返回的接收报告块中的时间标志结合起来,计算往返每个接收者所花的时间。接收者应让 NTP 时间戳的精度远大于其他时间戳的精度。一个系统可能没有背景时钟的概念,而只有系统指定的时钟,如系统时间(system uptime)。在这样的系统中,此时钟可以作为参考计算相对 NTP 时间戳。选择一个公用的时名是非常重要的。这样多个独立的应用都可以使用相同的时钟，一个发送者,如果不用背景时钟时间或逝去时间,可以设置此项为零。
RTP 时间戳32 bits与以上的 NTP 时间标志对应同一时刻。与数据包中的RTP时间戳具有相同的单位和偏移量。这个一致性可以用来让 NTP 时间标志已经同步的源之间进行媒体内/间同步,还可以让与媒体无关的接收者估计名义 RTP 时钟频率。注意在大多数情况下此时间戳不等于任何临近的 RTP 包中的时间戳。RTP 时间戳可以由相应的 NTP 时间戳计算得到。依据的是―RTP时间戳计数器和―在采样时通过周期性检测背景时钟时间得到的实际时两者之间的关系。
发送的报文数32 bits从开始传输到此 SR 包产生时该发送者发送的 RTP 数据包总数。若发送者改变 SSRC 识别符,该计数器重设
发送的字节文数32 bits从开始传输到此 SR 包产生时该发送者在RTP数据包发送的字节总数(不包括头和填充)。若发送者改变 SSRC 识别符,该计数器重设。此域可以用来估计平均的负载数据发送速率。

在 RTCP SR 包中有 NTP 时间戳、RTP 时间戳,它们可以计算背景时钟和 RTP 时钟之间的对应关系,通过这个关系,可以由 RTP 数据包中的 RTP 时间戳计算也相应的回放时刻。这样就可以进行多个流的同步了。之所以要有 NTP 时间戳,是因为不同流的 RTP 时间戳有不同的随机偏移量,无法直接进行同步。

第三部分：零到多个接收报告块

块数等于从上一个报告以来该发送者侦听到的其它源(不包括自身)的数目。每个接收报告块传输从某个同步源来的数据包的接收统计信息。若数据源因冲突而改变其 SSRC 标识符,接收者重新设置统计信息。这些统计信息有:

类型长度描述
SSRC_n(同步源标识符)32 bits在此接收报告块中信息所属源的 SSRC 标识符。
丢包率8 bits自从前一 SR 包或 RR 包发送以来,从SSRC_n传来的RTP数据包的丢失比例。以定点小数的形式表示。该值定义为损失包数/期望接收的包数。若由于包重复而导致包丢失数为负值,丢包率设为零。注意在收到上一个包后,接收者无法知道以后的包是否丢失。如:若在上一个接收报告间隔内从某个源发出的所有数据包都丢失,那么将不为此数据源发送接收报告块。
累计包丢失数24 bits从开始接收到现在,从源SSRC_n发到本源的RTP数据包的丢包总数。该值定义为:期望接收的包数-实际接收的包数。接收的包括复制的或迟到的。由于迟到的包不算作损失,在发生复制时丢包数可能为负值。期望接收的包数定义为:扩展的上一接收序号(随后定义)减去最初接收序号。
接收到的扩展的最高序列号32 bits低16 bits 包含从源SSRC_n来的最高接收序列号,高16 bits 用相应的序列号周期计数器扩展该序列号，防止数据值大溢出，注意在同一会议中的不同接收者,若启动时间明显不同,将产生不同的扩展项。
到达间隔抖动32 bitsRTP 数据包到达时刻统计方差的估计值。测量单位同时间戳单位,用无符号整数表达。到达时间抖动定义为一对包中接收者相对发送者的时间间隔差值的平均偏差(平滑后的绝对值)。如以下等式所示,该值等于两个包相对传输时间的差值。相对传输时间是指:包的 RTP 时间戳和到达时刻接收者时钟时间的差值。
上一 SR 报文(LSR)32 bits接收到的来自源 SSRC_n 的最新 RTCP 发送者报告(SR)的 64 位 NTP 时间标志的中间 32 位。若还没有接收到 SR,该域值为零。
自上一 SR 的时间(DLSR)32 bits是从收到来自 SSRC_n 的 SR 包到发送此接收报告块之间的延时,以 1/65536 秒为单位。若还未收到来自 SSRC_n 的 SR 包,该域值为零。
RR（Receiver Report）

接收者报告包(RR)与发送者报告包基本相同,除了包类型域包含常数 201 和没有发送者信息的 5 个字(NTP 和 RTP 时间标志和发送者包和字节计数)。余下区域与 SR 包意义相同。若没有发送和接收据报告,在 RTCP 复合包头部加入空的 RR 包(RC=0)。

0                  1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|    RC   |   PT=RR=201   |              length           |头部8字节==》版本(V)|填充(P)|接收报告块计数(RC）|包类型(PT)|长度
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        SSRC of sender                         |SR 包发送者的同步源标识符
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|                 SSRC_1 (SSRC of first source)                 |接收报告块==》SSRC_n(同步源标识符)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| fraction lost |       cumulative number of packets lost       |丢包率 | 累计包丢失数
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           extended highest sequence number received           |接收到的扩展的最高序列号
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      interarrival jitter                      |到达间隔抖动
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           last SR (LSR)                       |上一 SR 报文
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    delay since last SR (DLSR)                 |自上一 SR 的时间
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|                SSRC_2 (SSRC of second source)                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              ...                              |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|                   profile-specific extensions                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
SDES（Source Description Items）

源描述(SDES)包由一个头及 0 个或多个块组成。每个块都由块中所标识的数据源的标识符及其后的各个描述构成。

0                  1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|    SC   |  PT=SDES=202  |           length            |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|                            SSRC/CSRC_1                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            SDES items                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                             ...                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           SSRC/CSRC_2                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            SDES items                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                             ...                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

描述信息如：

SDES items描述
CNAMECNAME与SSRC对应，为源的唯一标识（SSRC可能会发生变化）
NAME名字
EMAIL邮箱
PHONE电话
LOC位置
TOOL
NOTE备注
PRIV私有扩展
0                  1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     CNAME     |    length     |  user and domain name ...
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
BYBE

BYE 包表明一个或多个源将要离开。如果混合器收到 BYE 包,混合器应当发送这个 BYE 包,并保持 SSRC/CSRC 不变。如果混合器关闭,应向贡献源列表中的所有 SSRC,包括它自己的SSRC 发送 BYE 包。BYE 包可能会有选择的包含 8 个字节的统计字段,其后跟上几个字节的文本表明离开的原因。文本字符串编码格式和 SDES 中描述的相同。

0                  1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|    SC   |   PT=BYE=203  |             length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          SSRC/CSRC                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                             ...                               :
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|    length     |             reason for leaving (opt)    ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
APP
0                  1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| subtype |   PT=APP=204  |            length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              SSRC/CSRC                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            name (ASCII)                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   application-dependent data        ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
类型长度描述
子类型（subtype ）5 bits可以用作子类型，以允许在一个唯一名称下定义一组应用程序包
名称（name ）32 bits由定义应用程序数据包集的人员选择的名称，该数据包集相对于此应用程序可能接收的其他应用程序包。应用程序创建者可以选择使用应用程序名称，然后协调将子类型值分配给希望为应用程序定义新的数据包类型。或者，建议其他人根据他们所代表的实体选择一个名称，然后协调名称的使用在该实体内。名称被解释为四个ASCII字符的序列，其中视为不同的大小写字符。
应用程序相关数据可变长度应用程序相关数据可能出现在应用程序包中，也可能不出现。它被解释为而不是RTP本身。它必须是32位长的倍数。

rfc4585：Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)

Feedback 消息公共头
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |V=2|P|   FMT   |       PT      |          length               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  SSRC of packet sender                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  SSRC of media source                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :            Feedback Control Information (FCI)                 :
   :                                                               :

           Figure : Common Packet Format for Feedback Messages
类型长度描述
Feedback message type (FMT)5 bits消息类型
Payload type (PT)8 bitspt值
   Payload type (PT): 8 bits
      This is the RTCP packet type that identifies the packet as being
      an RTCP FB message.  Two values are defined by the IANA:

            Name   | Value | Brief Description
         ----------+-------+------------------------------------
            RTPFB  |  205  | Transport layer FB message
            PSFB   |  206  | Payload-specific FB message
Transport Layer Feedback Messages
0:    unassigned
1:    Generic NACK
2-30: unassigned
31:   reserved for future expansion of the identifier number space
Generic NACK
0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            PID                |             BLP               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Figure : Syntax for the Generic NACK message
类型长度描述
Packet ID (PID)16 bits丢包编号，设置为 RTP sequence number
bitmask of following lost packets (BLP)16 bits位图：第 i 个位置设置 1，则 PID+i 序号的包丢失
Payload-Specific Feedback Messages

FMT 参数如下：

0:     unassigned
1:     Picture Loss Indication (PLI)
2:     Slice Loss Indication (SLI)
3:     Reference Picture Selection Indication (RPSI)
4-14:  unassigned
15:    Application layer FB (AFB) message
16-30: unassigned
31:    reserved for future expansion of the sequence number space
Picture Loss Indication (PLI)

图像丢失指示消息，其中 PT=PSFB，FMT=1，解码器通知编码器图像数据丢失，接收PLI的编码器意识到预测链可能被破坏。发送方可以通过发送帧内编码图片来对PLI作出反应以完成解码。此消息的 FCI 数据为空。

Slice Loss Indication (SLI)

slice 丢失指示消息，其中 PT=PSFB，FMT=2：

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            First        |        Number           | PictureID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Figure : Syntax of the Slice Loss Indication (SLI)
类型长度描述
First13 bits丢失的 slice 的起始 macroblock (MB) 编号
Number13 bits丢失宏块的数量
PictureID6 bits参考帧 ID
Reference Picture Selection Indication (RPSI)

参考图片选择指示消息，其中 PT=PSFB，FMT=3，在发生丢包或解码错误时，请求对端发送关键帧

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      PB       |0| Payload Type|    Native RPSI bit string     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   defined per codec          ...                | Padding (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure : Syntax of the Reference Picture Selection Indication (RPSI)
类型长度描述
PB8 bits填充位的位数
01 bits传输时必须设置为 0 接收时忽略
Payload Type7 bitsNative RPSI bit string 表示的载荷类型
Native RPSI bit string可变长度本端视频编解码器定义的 RPSI 信息
Padding填充位
Application layer FB (AFB) message

rfc5104：Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)

Transport Layer Feedback Messages
Assigned in AVPF [RFC4585]:
1:    Generic NACK
31:   reserved for future expansion of the identifier number space

Assigned in this memo:
2:    reserved (see note below)
3:    Temporary Maximum Media Stream Bit Rate Request (TMMBR)
4:    Temporary Maximum Media Stream Bit Rate Notification (TMMBN)

Available for assignment:
0:    unassigned
5-30: unassigned
Temporary Maximum Media Stream Bit Rate Request (TMMBR)

临时最大媒体比特率请求消息，其中 PT=RTPFB，FMT=3：

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              SSRC                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MxTBR Exp |  MxTBR Mantissa                 |Measured Overhead|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Figure  - Syntax of an FCI Entry in the TMMBR Message

MxTBR Exp (6 bits):  [0..63].
MxTBR Mantissa (17 bits)：2^17 = 131072
Measured Overhead (9 bits):  测量的平均开销
MxTBR = mantissa * 2^(Exp)
能够表示的范围：0 ~ 131072*2^63(approximately 1.2*10^24).
Temporary Maximum Media Stream Bit Rate Notification (TMMBN)

临时最大媒体比特率通知响应消息，其中 PT=RTPFB，FMT=4：同上

Payload-Specific Feedback Messages
Assigned in [RFC4585]:
1:     Picture Loss Indication (PLI)
2:     Slice Lost Indication (SLI)
3:     Reference Picture Selection Indication (RPSI)
15:    Application layer FB message
31:    reserved for future expansion of the number space

Assigned in this memo:
4:     Full Intra Request (FIR) Command
5:     Temporal-Spatial Trade-off Request (TSTR)
6:     Temporal-Spatial Trade-off Notification (TSTN)
7:     Video Back Channel Message (VBCM)

Unassigned:
0: unassigned
8-14: unassigned
16-30: unassigned
Full Intra Request (FIR)

完整帧请求消息，其中 PT=RTPFB，FMT=4,新的参与者加入，就需要发送一个 FIR，通知其他的参与者发送一个关键帧，从而实现解码

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              SSRC                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seq nr.       |    Reserved                                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Figure  - Syntax of an FCI Entry in the FIR Message
类型长度描述
SSRC32 bits被请求发送解码器刷新点的媒体发送器的 SSRC 值
Seq nr.8 bits命令序列号
Temporal-Spatial Trade-off Request (TSTR)

时空交换请求

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              SSRC                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Seq nr.      |  Reserved                           | Index   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                Figure - Syntax of the TSTR
类型长度描述
SSRC32 bits被请求应用索引中给定的折衷值的媒体发送方的 SSRC 值
Seq nr.8 bits请求序列号，每一个新的命令该序列号加一
Reserved19 bits保留位
Index5 bits指示请求的相对折衷值
Temporal-Spatial Trade-off Notification (TSTN)

时空交换响应，同上

H.271 Video Back Channel Message (VBCM)
0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              SSRC                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seq nr.       |0| Payload Type| Length                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    VBCM Octet String....      |    Padding    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        Figure  - Syntax of an FCI Entry in the VBCM

rfc3611：RTP Control Protocol Extended Reports (RTCP XR)

参考文献

  1. RTP/RTCP的RFC协议汇总
  2. WebRTC中RTCP协议详解
bwangk
关注
  • 3
    点赞
  • 踩
  • 9
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
流媒体协议介绍（rtp_rtcp_rtsp_rtmp_mms_hls）.doc
07-17
介绍RTP( Real-time Transport Protocol) RTCP（实时传输控制协议（Real-time Transport Control Protocol））安全实时传输协议（Secure Real-time Transport Protocol或SRTP）等协议
跨路由器 网段访问rtsp_实验演示：三层交换机与路由器对接
weixin_39784195的博客
11-29 958
(一)实验拓扑及描述(二)实验需求1. 在交换机上创建VLAN10及VLAN20；2. 将PC1所在端口分配到VLAN10；PC2所在端口分配到VLAN20。配置vlanif 10及vlanif 20作为VLAN10及VLAN20用户的网关，使得VLAN10及VLAN20的用户能够互相访问；3. 在交换机上创建VLAN200并配置vlanif 200接口，作为与路由器对接的VLAN及三层接口；4....
rtsp转发
最新发布
诗筱涵的博客
02-22 391
（已经源码编译安装了gst-rtsp-server的前提下，在~/gst-rtsp-server/examples目录下打开终端运行下面命令）命令中的rtsp://192.168.2.119:554/stream0是品灵吊舱原本的拉流地址。对应的推流地址为rtsp://127.0.0.1:8554/test。
流媒体相关协议标准(RTP_RTSP_RTCP).txt
06-23
流媒体相关协议标准(RTP_RTSP_RTCP).txt
c++之流媒体传输--Live555源码解读(第一季)
06-09
Live555是一个为流媒体提供解决方案的跨平台的C++开源项目，它实现了对标准流媒体传输是一个为流媒体提供解决方案的跨平台的C++开源项目，它实现了对标准流媒体传输协议如RTP/RTCP、RTSP、SIP等的支持。Live555实现了对多种音视频编码格式的音视频数据的流化、接收和处理等支持，包括MPEG、H.263+、DV、JPEG视频和多种音频编码。
两个网段在同一个交换机_告诉你PC不能通过二层交换机实现跨网段通信的小秘密：你很难想到...
weixin_39856589的博客
12-08 7345
概述我们都知道不同网段的PC之间要实现互通，中间必须要接个具有三层功能的设备，因为只有三层设备(通常是路由器)才能在不同的网段之间查找路由，实现跨网段互访，如下图所示：PC通过路由器实现跨网段通信但是如果将拓扑图中的路由器换成二层交换机，就没有办法互访了，小伙伴有没有想过其中的原因呢？我也是回答了一个悟空问答，梳理它们之间的通信流程以后才知道的，今天和大家分享一下！不同网段之间通信拓扑PC和二层交...
RTSP网络控制组件
12-31
RTSP组件 自己写好的组件，可直接使用，有RTP基于UDP传输和基于TCP传输两种方式，并且有相关控制函数
流媒体传输协议介绍
machh的专栏
07-01 5528
流媒体传输协议介绍一、RTSP协议介绍什么是rtsp? RTSP协议以客户服务器方式工作，，如：暂停/继续、后退、前进等。它是一个多媒体播放控制协议，用来使用户在播放从因特网下载的实时数据时能够进行控制, 因此 RTSP 又称为“因特网录像机遥控协议”。         RTSP(Real-Time Stream Protocol)是一种基于文本的应用层协议，在语法及一些消息参数等方面，R
RTP/RTCP协议介绍
RationalGo的专栏
03-12 1268
1．流媒体( Streaming Media) 1.1流媒体概念 流媒体技术是网络技术和多媒体技术发展到一定阶段的产物。术语流媒体既可以指在网上传输连续时基媒体的流式技术,也可以指使用流式技术的连续时基媒体本身。在网上传输音频、视频等多媒体信息目前主要有两种方式:下载和流式传输。采用下载方式,用户需要先下载整个媒体文件,然后才能进行播放。由于网络带宽的限制,下载常常要花很长时间,所以这
rtp/rtcp/rtsp资料精华！
HULIHONG的专栏
05-19 3954
7.3 流媒体技术 　　流媒体是指在网络中使用流式（Sreaming）传输技术进行传输的连续时基媒体，如音频数据流或视频数据流，而不是一种新的媒体。流媒体技术（或称为流式媒体技术）就是把连续的影像和声音信息经过压缩处理后放到网络服务器上，让浏览者一边下载一边观看、收听，而不需要等到整个多媒体文件下载完成就可以即时观看的技术。流媒体技术并不是单一的技术，它是融合流媒体数据的采集、压缩、存储、传输以
RTSP 协议 01
01-13 1201
 rtsp简介(ZT)Real Time Streaming Protocol或者RTSP（实时流媒体协议），是由Real network 和Netscape共同提出的如何有效地在IP网络上传输流媒体数据的应用层协议。RTSP提供一种可扩展的框架，使能够提供能控制的，按需传输实时数据，比如音频和视频文件。源数据可以包括现场数据的反馈和存贮的文件。rtsp对流媒体提供了诸如暂停，快进等控制，
模拟RTSP访问和控制，用来播放视频流
02-20
模拟RTSP访问和控制，用来播放视频流，可用来刷电信业务的视频
RTSP&RTP&RTCP&RTMP_RTSP-RTP-RTCP-RTMP_
09-30
RTSP&RTP&RTCP&RTMP 协议栈介绍
RTP报文头中的SSRC和CSRC
jingjiankai5228的博客
01-29 690
图像数据打包
RTP和RTCP详解
技术控的笔记
09-19 5681
在流媒体相关的领域，我们进场会看到RTP/RTCP，其用于流式传输的最常见的码流传输协议，位于传输层之上，控制流媒体码流传输。RTP经常与RTCP成对使用，广泛应用于流媒体相关的通讯和娱乐，包括电话、视频会议、电视和基于网络的一键通业务。RTCP（Realtime Transport Control Protocol）实时传输控制协议，实现服务质量的监视与反馈、媒体间的同步，以及多播组中成员的标识，其协议规范在IETF RFC3550中定义。
RTSP音视频传输频笔记
楷尘·极客
09-25 3435
《音视频应用开发系列文章目录》 RTSP在音视频传输中的位置 RTSP协议是一个应用层协议，主要针对媒体流传输过程的控制和配置，提供OPTIONS,DESCRIBE,SETUP,TEARDOWN,PLAY,GET_PARAMETER,SET_PARAMETER等操作命令。 下图是客户端请求rtsp服务器音视频数据的大致过程 client通过RTSP协议对远程服务器发起连接请求，连接成功...
rtp和rtcp协议详解
大白的博客
01-04 4329
RTP被定义为传输音频、视频、模拟数据等实时数据的传输协议，与传统的注重的高可靠的数据传输的传输层协议相比，它更加侧重的数据传输的实时性，此协议提供的服务包括数据顺序号、时间标记、传输控制等。 RTP一般与传输控制协议RTCP一块工作，RTP只负责实时数据的传输，RTCP负责对RTP的通讯和会话进行带外管理（如流量控制、拥塞控制、会话源管理等）。 RTP使用一个偶数端口号，而相应RTCP流使用下一个(奇数，递增)端口号。 先来看一下rtp和rtcp网络结构图： RTP的数据包由RTP Header + R
局域网无纸化会议封装，只需三步实现推流和播放
weixin_34306676的博客
11-22 888
又名 基于rstp的录屏直播 上篇文章 步骤： 1.下载lib到本地，然后依赖 RtspServerAndVlcPlay git clone https://github.com/wobiancao/RtspServerAndVlcPlay.git 如果只是推流端，只需要依赖 rtsplibrary 如果只是播放端，只需要依赖 libvlc-android 重点声明: rtspli...
rtp协议流转 rtsp协议流
04-01
RTP（Real-time Transport Protocol）和RTSP（Real-time Streaming Protocol）是用于实时音视频流传输的协议。在实际应用中，它们经常一起使用。 RTP协议流通常用于传输音/视频数据。它是一个协议套件，包括RTP、RTCP（Real-time Transport Control Protocol）和SRTP（Secure Real-time Transport Protocol）。RTP协议提供了一种标准的方法来将音频和视频数据打包并传输到网络上。RTP协议流可以通过UDP或TCP传输。 RTSP协议流通常用于控制媒体流的传输。它是一种客户端-服务器协议，用于控制流媒体服务器上的媒体资源。RTSP协议流允许客户端控制媒体流的开始、暂停、停止和重新定位。RTSP协议流可以通过TCP或UDP传输。 在实际应用中，通常使用RTSP协议流来控制媒体流的传输，使用RTP协议流来传输音/视频数据。当客户端向服务器请求媒体流时，服务器会使用RTSP协议流将媒体流的地址和控制信息发送给客户端。客户端使用RTP协议流从服务器接收媒体流数据。

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

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

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值