📚 课程目录第4章 RTP与RTCP协议

4. RTP与RTCP协议

在无人机RTSP低延迟视频传输链路中，RTSP负责会话建立与控制，而真正承载H.264/H.265视频码流的是RTP，负责传输质量反馈与统计的是RTCP。理解RTP/RTCP，是判断“画面卡顿、花屏、延迟抖动”根因的关键。本节围绕RTP数据包结构、时间戳与序列号、RTCP反馈机制以及丢包与抖动统计展开，帮助你把协议字段与无人机图传的实际现象对应起来。

一、RTP数据包结构：视频码流的运输单元

RTP运行在UDP之上，每个RTP包由固定头和载荷组成。固定头通常12字节，关键字段包括：版本V、填充P、扩展X、CSRC计数CC、标记M、载荷类型PT、序列号、时间戳、同步源SSRC。对于无人机视频，PT常见为96（动态载荷类型，SDP中映射为H.264）或98等，M位用于标识一帧的最后一个RTP包，接收端据此判断帧边界。

当一帧H.264数据大于MTU时，需要分片。常用FU-A分片方式：起始分片携带FU indicator与FU header，S位标识分片开始，E位标识分片结束，中间分片依次拼接。若分片丢失，接收端无法重组完整帧，解码器就会报错，表现为花屏或绿屏。因此RTP层丢包对视频质量的影响，往往比TCP层重传更直接。

RTP固定头（12字节）：
 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            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

二、时间戳与序列号：同步与顺序的双坐标

序列号是16位无符号整数，每发送一个RTP包递增1，用于接收端检测丢包、乱序和重复包。时间戳是32位无符号整数，表示该包载荷第一个字节的采样时刻，单位由时钟频率决定。H.264视频常用90000Hz时钟，即时间戳每增加90000代表1秒。接收端通过时间戳差值计算帧间隔，再结合本地时钟做播放调度，实现音视频同步与平滑播放。

在无人机图传中，序列号和时间戳共同构成“顺序+时间”的双坐标。序列号告诉你“包有没有丢、顺序对不对”，时间戳告诉你“这一帧该在什么时候显示”。如果只关注序列号而忽略时间戳，接收端可能把乱序包按到达顺序播放，造成画面节奏错乱；如果只关注时间戳而忽略序列号，则无法发现丢包，解码器会持续等待缺失分片。

判断丢包的简单方法：接收端维护期望序列号expected_seq，每收到一个包，若seq == expected_seq，则expected_seq++；若seq > expected_seq，则中间缺失(seq - expected_seq)个包；若seq < expected_seq，则可能是乱序或重复包。结合RTCP RR中的丢包率，可以进一步区分偶发丢包与持续拥塞。

三、RTCP反馈机制：让发送端“看见”接收质量

RTCP与RTP配合使用，不承载视频数据，而是周期性发送控制报文。常见类型包括：SR（发送者报告）、RR（接收者报告）、SDES（源描述）、BYE（结束）、APP（应用自定义）。在无人机图传中，最核心的是RR，它携带接收端统计的丢包率、累计丢包数、最高序列号、抖动估计和LSR/DLSR时间戳，发送端据此调整码率、分辨率或重传策略。

RTCP反馈周期通常为几秒，但在低延迟场景中可缩短到几百毫秒。若反馈周期过长，发送端无法及时感知链路恶化；若过短，又会增加控制开销。实际部署中，常结合REMB、PLI、FIR等反馈消息：PLI请求关键帧，FIR请求特定帧，REMB用于带宽估计。无人机链路带宽波动大，RTCP RR中的丢包率和抖动值，是自适应码率算法的直接输入。

四、丢包与抖动统计：从数字到画面现象

RTCP RR中的丢包率是区间丢包率，计算方式为：期望接收包数减去实际接收包数，再除以期望接收包数。累计丢包数则记录从会话开始到现在的总丢失包数。抖动估计采用RFC 3550定义的算法：对每对相邻包，计算到达时间差与RTP时间戳差的差值，再取绝对值并做指数平滑。抖动值越大，说明网络排队时延变化越剧烈，接收端需要更大的抖动缓冲，但缓冲越大延迟越高。

在无人机图传中，丢包和抖动常常同时出现。链路信号弱时，丢包率上升，画面出现马赛克或卡顿；链路拥塞时，抖动增大，画面出现忽快忽慢的节奏变化。通过RTCP RR，发送端可以区分“丢包主导”还是“抖动主导”，从而选择重传、降码率或调整缓冲策略。

统计量	来源字段	典型阈值	画面现象	建议动作
区间丢包率	RR fraction lost	< 1% 良好；> 5% 恶化	花屏、马赛克、绿屏	降码率、请求关键帧
累计丢包数	RR cumulative lost	持续增长需关注	画面断续、解码失败	检查链路、切换信道
抖动估计	RR interarrival jitter	< 30ms 良好；> 100ms 明显	画面忽快忽慢、音画不同步	增大抖动缓冲、调整调度
最高序列号	RR extended highest seq	用于计算期望包数	辅助判断丢包范围	结合seq差值定位
LSR/DLSR	RR last SR / delay since last SR	用于计算RTT	反馈延迟大则调整滞后	缩短RTCP周期

五、案例与排障：一次图传花屏的协议层复盘

某无人机在执行巡检任务时，地面站画面每隔几秒出现一次花屏，持续约200ms后恢复。抓包发现：RTP序列号在花屏时段出现连续缺失，缺失数量约等于一帧的分片数；RTCP RR中区间丢包率从0.3%跃升到8%，抖动从15ms升到120ms。进一步检查发现，图传链路在切换信道时出现短暂拥塞，导致同一帧的FU-A分片部分丢失。由于接收端无法重组完整帧，解码器丢弃该帧，直到下一个I帧到达才恢复。

处理措施包括：第一，发送端根据RR丢包率触发PLI请求关键帧，缩短花屏持续时间；第二，启用自适应码率，在丢包率超过5%时降低分辨率或帧率；第三，接收端适当增大抖动缓冲，但需权衡延迟；第四，检查无线信道干扰，避免频繁切换。复盘结论是：RTP层丢包是现象，RTCP反馈是诊断依据，自适应策略是解决手段，三者缺一不可。

常见误区：把RTCP当作“可选协议”而关闭。关闭RTCP后，发送端无法获知接收质量，自适应码率失效，弱网下画面会持续恶化。另一个误区是只看丢包率不看抖动，实际上抖动过大时，即使丢包率为0，接收端也可能因为缓冲溢出而丢帧。

六、实操建议：如何观测与调优

使用Wireshark过滤rtp与rtcp，查看序列号跳变和RR报文中的丢包率、抖动值。
在接收端维护expected_seq、highest_seq、jitter三个变量，实时打印统计日志。
RTCP发送周期建议在低延迟场景设为200ms～500ms，兼顾反馈速度与开销。
抖动缓冲初始值可设为50ms，根据RR抖动值动态调整，避免固定大缓冲引入额外延迟。
当丢包率持续高于5%时，优先降码率而非盲目重传，避免加剧拥塞。

# 接收端统计日志示例
[RTCP] fraction_lost=0.03  cumulative_lost=127  jitter=42ms
[RTP]  expected_seq=10231  highest_seq=10245  lost=14  recovered=2
[ADAPT] loss=3%  jitter=42ms  action=keep_bitrate
[ADAPT] loss=8%  jitter=120ms action=reduce_bitrate_20% + request_PLI

总结来说，RTP负责把视频码流切成可传输的包，序列号和时间戳分别解决“顺序”和“时间”问题；RTCP负责把接收端的丢包与抖动反馈给发送端，形成闭环。只有把RTP包结构、时间戳与序列号、RTCP反馈机制、丢包与抖动统计四者串起来，才能在无人机低延迟图传中快速定位问题、动态调整策略，保证画面稳定流畅。