FFmpeg 4.3 音视频-多路H265监控录放C++开发二十一.2，RTP协议-RTP协议概述，协议详情

前提: 为什么要学习 RTP（Real-time Transport Protocol）重点

• 简介：RTP是一个实时传输媒体数据的协议，通常与RTSP一起使用。它负责在网络上传输音视频数据。
• 特点：RTP通过UDP或TCP传输媒体数据，提供时间戳和序列号等机制以保证实时性。它支持多种视频编码格式，且具有良好的扩展性和兼容性。

应用场景：

常与RTSP一起用于音视频流传输，确保媒体数据能够准确、高效地传输到目标终端并进行解码播放。

1. 视频会议

• 应用场景：在视频会议中，RTP被用于将来自不同位置的多个音视频流混合在一起，并实时传输给所有参与者。它确保了音视频数据的同步性和实时性，使得远程会议如同面对面交流一般。
• 优势：RTP的高实时性和精确的时间戳机制，使得音视频数据在传输过程中能够保持低延迟和同步性，从而提高了会议的质量和效率。

2. 直播服务

• 应用场景：在直播场景中，RTP协议为高质量的音视频传输提供了保障，RTP能确保观众能够实时观看到流畅、清晰的视频内容。
• 优势：RTP支持多种音视频编码格式，并且可以根据网络状况动态调整传输参数，以适应不同的直播需求。同时，它还可以与RTCP（Real-time Transport Control Protocol，实时传输控制协议）配合使用，实现传输质量的监控和反馈。

3. 流媒体服务

• 应用场景：流媒体服务如在线视频点播、网络电视等也广泛采用RTP协议。它允许用户随时随地访问和播放音视频内容，而无需等待整个文件下载完成。
• 优势：RTP的流式传输特性使得音视频数据可以边下载边播放，大大节省了用户的时间和带宽资源。同时，它还可以根据用户的网络状况自动调整播放质量，以提供最佳的观看体验。

4. IP电话

• 应用场景：在IP电话通信中，RTP用于传输语音数据。它确保了语音数据的实时性和清晰度，使得用户能够像使用传统电话一样进行通话。
• 优势：RTP的低延迟和高效传输特性使得IP电话通信具有与传统电话相似的通话质量，并且不受地理位置的限制。

5. 监控录像

• 应用场景：在监控系统中，RTP协议被用于实时传输监控视频数据。它确保了监控画面的实时性和清晰度，使得监控人员能够及时发现并处理异常情况。
• 优势：RTP的实时传输能力和高可靠性使得监控系统能够稳定运行并发挥最大效用。同时，它还可以与其他监控设备和技术相结合，形成更加完善的监控体系。

RTP 协议详解

RTP报⽂由两部分组成：报头和有效载荷

RTP头部 大小为 ：固定的 12字节 + [0-60个字节]

0-60个字节 是 0-15个CSRC组成，每个CSRC 都是4个字节--- 也就是32位组成

RTP报头格式如下图所示

V：RTP协议的版本号， 占2位 ，当前协议版本号为2。

P：填充标志， 占1位 ，如果P=1，则在该报⽂的尾部填充⼀个或多个额外的⼋位组，它们不是有效载荷的⼀部分。其作用是：有些加密算法，需要是16位的倍数才能加密。不过一般都是0

X：扩展标志， 占1位 ，如果X=1，则在RTP报头后跟有⼀个扩展报头。只在webrtc中会用到，如果这个有值，那么 报文会变成  RTP头部 + 扩展报头 + 有效载荷

CC：CSRC计数器， 占4位 ，指示CSRC 标识符的个数。一般为0，标识 特约信源(CSRC)的个数。

M: 标记， 占1位 ，不同的有效载荷有不同的含义，对于视频，标记⼀帧的结束；对于⾳频，标记帧的开始。

PT: 有效载荷类型， 占7位 ，⽤于说明RTP报⽂中有效载荷的类型，如GSM⾳频、JPEM图像等。

序列号： 占16位 ，⽤于标识发送者所发送的RTP报⽂的序列号，每发送⼀个报⽂， 序列号增1 。 接收者通过序列号来检测报⽂丢失情况，重新排序报⽂，恢复数据 。

时戳(Timestamp)： 占32位 ，时戳反映了该RTP报⽂的第⼀个⼋位组的采样时刻。接收者使⽤时戳来 计算延迟和延迟抖动，并进⾏同步控制。

同步信源(SSRC)标识符： 占32位 ，⽤于标识同步信源。该标识符是随机选择的，参加同⼀视频会议的 两个同步信源不能有相同的SSRC。

特约信源(CSRC)标识符：每个CSRC标识符 占32位 ，可以有0～15个。每个CSRC标识了包含在该RTP 报⽂有效载荷中的所有特约信源。

因此大小如下：

2+1+1+4+1+7+16+32+32 = 96 位  = 12bytes 固定大小

0-15 个 32位 不确定大小[0-60个字节]

同步信源(SSRC)标识符 的解释：

是指产⽣媒体流的信源， 例如⻨克⻛、摄像机、RTP混合器等。每个摄像头都是一个SSRC，每个麦克风都是一个SSRC， 它通过RTP报头中的⼀个32位数字SSRC标识符来标识，⽽不依赖于⽹络地址，接收者将根据 SSRC标识符来区分不同的信源 ， 进⾏RTP报 ⽂的分组 。

例如，有三个信号源各发出⼀路rtp流，

RTP1携带的SSRC是SSRC1，

RTP2携带的SSRC是SSRC2，

RTP3携带SSRC3，

这三路RTP流到达混合器时，混合器会将这三路流混合成⼀路流发出去，它会把这三路流的SSRC记录下来，形成⼀个列表，叫CSRC表，在发送的混合RTP流中，SSRC域填充的字段是混合器本身的SSRC4，⽽CSRC字段则会根据该包的负载的源来填⼊。

特约信源(CSRC) 标识符的解释：

特约信源是指当混合器接收到⼀个或多个同步信源的RTP报⽂后，经过混合处理产⽣⼀个新的组合RTP报 ⽂，并把混合器作为组合RTP报⽂的SSRC，⽽将原来所有的SSRC都作为CSRC传送给接收者，使接收者 知道组成组合报⽂的各个SSRC。

例如当前的RTP包的负载是来⾃SSRC1的，那么在当前RTP包的CSRC字段填⼊SSRC1。

这样接收者就可以根据CSRC来区分不同的信源；

⼀般的，混合的RTP流中，每隔⼀段时间，就会有⼀个RTP报⽂包含了完整的CSRC表。例如在发送混合流时的第⼀个RTP包，它的CSRC域把CSRC表都填⼊，此时该包的负载可能是⽆意义或者并不是媒体流；此后的RTP报⽂中则根据负载的来源来填⼊CSRC域。

RTP 协议代码上的表现形式：

typedef struct _rtp_header_t
{uint32_t v:2; /* protocol version */uint32_t p:1; /* padding flag */uint32_t x:1; /* header extension flag */uint32_t cc:4; /* CSRC count */uint32_t m:1; /* marker bit */uint32_t pt:7; /* payload type */uint32_t seq:16; /* sequence number */uint32_t timestamp; /* timestamp */uint32_t ssrc; /* synchronization source */
} rtp_header_t;

NEXT 使用RTP 协议 对 H264 封包和解包

为什么说RTP 协议重要呢？因为RTP协议不依赖于RTSP协议存在，在后面的webrtc中，会大量的使用到 RTP 协议，将编码好的h264包，发送给对端。因此要学习：

PCM-->编码成h264--->封装成RTP----->发送给对端------>对端将RTP解包成 h264--->解码成PCM播放

TODO

使用RTP 协议 对 H264 封包和解包-CSDN博客

NEXT 使用RTP 协议 对 AAC 封包和解包

TODO