引言
在实时音视频系统中，RTSP（Real-Time Streaming Protocol）负责会话与控制，而 RTP（Real-time Transport Protocol）负责媒体数据承载。开发者在实现跨平台、低延迟的 RTSP 播放器或轻量级 RTSP 服务时，难点往往不在“能跑通”，而在弱网稳态、异构设备兼容、低延迟与可维护性的长期平衡。
本文以规范为主线（关键参考：RTSP/1.0: RFC 2326、RTSP/2.0: RFC 7826、RTP: RFC 3550、RTP A/V Profile: RFC 3551、H.264 over RTP: RFC 6184、HEVC(H.265) over RTP: RFC 7798、RTCP-FB: RFC 4585/5104、RTP FEC: RFC 5109），系统讲清 RTP 打包/解包 的必知要点，并穿插 大牛直播SDK 在跨平台低延迟实践中的工程做法与调参建议。
0. 会话控制与协商：RTSP 与 SDP 在 RTP 之前要解决什么
0.1 RTSP 基本流程（RFC 2326 / RFC 7826）
典型拉流序列（简化）
DESCRIBE rtsp://...→ 服务器返回 SDP，其中包含媒体类型、编码、负载类型（PT）、时钟、a=rtpmap、a=fmtp等；SETUP（单路或双路，UDP 或 TCP interleaved）→ 确认 传输通道（Transport:头），为 RTP/RTCP 建立承载；PLAY→ 开始传输 RTP/RTCP；TEARDOWN→ 释放会话。
工程建议
UDP 优先以追求极低时延；内网/专网或已打通 NAT 的环境优先选；
TCP interleaved（在 RTSP 控制连接上
$打头的内嵌通道）用于穿越复杂网络/NAT，代价是拥塞时更易累计时延；保留回退：UDP 失败自动切 TCP，或反之。
0.2 SDP 里与 RTP 打包/解包密切相关的字段
m=：媒体描述（如m=video 0 RTP/AVP 96）；a=rtpmap:96 H264/90000：时钟频率（视频通常 90000 Hz）；a=fmtp:：分层参数与打包模式（H.264: RFC 6184）：packetization-mode：0=Single NAL unit；1=Non-Interleaved（常用）；2=Interleaved（极少用）；profile-level-id：编码配置（影响解码器一致性）；sprop-parameter-sets：Base64 的 SPS/PPS（可 out-of-band 下发）；
HEVC/H.265: RFC 7798：
sprop-vps/sprop-sps/sprop-pps（Base64）；亦有聚合/分片的负载格式（与 6184 思路相似但细节不同）。
工程建议
优先 packetization-mode=1（Non-Interleaved）：实现复杂度适中、设备兼容性最好；
对仅在码流内带 SPS/PPS 的源，播放器端需支持从流内提取参数集，并在解码前做参数注入/刷新。
1. RTP 基础：头部、时间戳、标记位与 AV Profile
1.1 RTP 固定头（RFC 3550，12 字节）
V=2、P（padding）、X（扩展）、CC（CSRC 计数）、M（Marker）、PT（Payload Type）、seq（16bit 序号）、timestamp（32bit）、SSRC（32bit）。视频 M 位：常用于“帧结束”标记（但非强制，需容忍厂商差异）。
timestamp：视频典型 90kHz；音频随编码不同（如 AAC 常 48kHz）。
1.2 A/V Profile（RFC 3551）
定义静态 PT、时钟等通用规则；
**动态 PT（>=96）**常用于 H.264/H.265，具体由 SDP 的
a=rtpmap、a=fmtp配置。
工程建议
不依赖 M 位唯一判帧；结合 NALU 边界、FU 重组完成点、服务器行为 做多条件判定；
timestamp 用于 A/V 对齐；视频端若 B 帧/重排序，需处理 DTS/PTS 映射（播放器侧常以到达时序+timestamp 做平滑）。
2. H.264 / H.265 的 RTP 打包（Sender 侧）
2.1 H.264（RFC 6184）常见负载模式
Single NAL Unit：单个 NALU 直接承载，适用于不超过 MTU的片段；
Aggregation Packets（STAP-A 等）：把多个小 NALU（如 SPS+PPS+IDR 组合）聚合到一个 RTP 包，降低包头开销；
Fragmentation Units（FU-A）：将超 MTU 的 NALU 分片，带 S/E 起止标记。
打包策略
计算可用负载：
payload_budget = MTU - (IP+UDP+RTP+ext)（UDP 常见），IPv4 典型：1500 - (20+8+12) = 1460左右（保守再减一些头扩展空间）；NALU ≤
payload_budget→ Single NALU；NALU >
payload_budget→ FU-A 分片：片头携带 S/E 标志；
中间片均为未置位；
最后一片可置
M=1（依服务器/实现策略）；
关键帧起始处，可选发送 STAP-A（SPS+PPS+IDR），提高首包解码成功率（兼顾 SDP 中 sprop-parameter-sets）。
2.2 HEVC/H.265（RFC 7798）负载模式
同样存在聚合与分片思路；
HEVC NALU 头为 2 字节，分片/聚合单元的格式字段与 H.264 有别（实现时严依 7798）；
参数集为 VPS/SPS/PPS，可 SDP 下发，也可随流内送达。
工程建议（发端）
MTU：内网 1500、公网/隧道环境可下探 1200/1300 以降低分片；
聚合策略：仅在明显收益时启用（如首帧 SPS/PPS/IDR 或大量极小 NALU），避免增加复杂度；
时间戳与序号：帧内统一 timestamp，包内 seq 递增；
M 位：按服务器/下游解析习惯配置，注意与“帧结束”的一致性。
3. RTP 解包（Receiver 侧）：重排序、重组与抖动缓冲
3.1 序列号重排序与丢包检测
基于
seq做乱序重排，窗口大小与 端到端延迟预算正相关（窗口大 → 延迟高但更稳）；追踪 wrap-around（16 位回绕）；
判定丢包/超时：在 窗口/时间阈值内未等到缺失 seq，即判缺，触发丢包策略。
3.2 NALU 重组
Single NAL：直接入帧缓存；
FU：按 S..E 顺序拼接，中间缺包 → 本帧弃或错误隐藏（看策略）；
Aggregation：逐个子 NAL 拆解后顺序交付。
3.3 抖动缓冲（JitterBuffer）与时钟
典型做法：到达时间戳（arrival ts） + RTP timestamp 双线索；
启动阶段：从小缓冲开始（如 30–80ms），根据网络抖动自适应增减；
Lip-sync：RTCP SR（带 NTP ↔ RTP 映射）可用于音画同步（RFC 3550/3551）。
3.4 弱网策略
错误隐藏：丢帧/丢片时尽量保持解码连续；
自适应丢弃：超过等待阈值的帧/片及时丢弃，避免全链路“背压”；
码流修复：容忍 M 位异常、AUD 断裂、非标 STAP，用启发式补偿。
工程建议（收端）
多条件判帧（NALU 边界 + FU 终止 + M 位 + Heuristic）；
分路线程：网络接收、重排序、重组、解码/渲染分离，降低锁竞争；
零拷贝：避免频繁 memcpy，环形缓冲结合引用计数。
4. RTCP 的价值：质量测量与反馈
SR/RR（Sender/Receiver Report）：带 NTP↔RTP timestamp 映射、丢包/抖动统计；
AVPF 扩展（RFC 4585）：NACK（重传请求）、PLI/FIR（关键帧请求，RFC 5104）；
FEC（RFC 5109）/RTX（RFC 4588）：丢包恢复机制（RTSP 场景下适配度视服务器/设备而定）。
工程建议
内网/低延迟场景：轻 RTCP（周期性 SR/RR）即可；
公网/弱网：若链路与设备支持，启用 NACK/PLI 能显著改善体验；
注意 RTSP 场景下重传代价：TCP 内嵌更易“放大抖动”，UDP+NACK 要平衡时延与修复。
5. 传输模式与 MTU：UDP vs TCP Interleaved
UDP：抖动小、等待少 → 最低时延；需处理 NAT、端口放通；
TCP Interleaved：穿越性好，报文以
$ <channel> <len> <RTP/RTCP payload>在控制连接内复用；在拥塞/丢包时更易积压并拉高时延。MTU 选择：
IPv4/UDP/RTP 典型 MTU=1500 时，建议单包负载 ≤ 1400 左右；
VPN/隧道/公网环境，1200–1300 更稳妥。
RTP Header Extension：如需统计或打点，控制扩展开销，避免二次分片。
6. 安全与认证（简述）
RTSP 认证：Basic / Digest（参考上篇）；
RTSPS/SRTP：RTSP over TLS、RTP 加密（SAVP/SAVPF），在强安全场景考虑，注意终端/设备一致性与 CPU 开销。
7. 大牛直播SDK的工程实现要点（发端+收端）
安卓轻量级RTSP服务采集摄像头，PC端到安卓拉取RTSP流
7.1 轻量级 RTSP 服务模块（发端/RTP 打包侧）
内置打包器：按 RFC 6184/7798 选择 Single/FU/聚合；
自适应 MTU：配置可调，默认保守避免外层再分片；
参数集策略：首帧 STAP-A（或 HEVC 聚合包）携带 VPS/SPS/PPS + 关键帧，兼容更多播放器；
UDP/TCP 双栈：SETUP 时自适应协商，失败回退；
事件回调：RTP 出包回调、码流统计、录制/转发钩子，便于对接 AI 分析或链路监控。
7.2 跨平台 RTSP 播放器（收端/RTP 解包侧）
统一重排序/重组引擎：Windows/Linux/Android/iOS/Unity 共享核心代码；
自适应 JitterBuffer：以抖动统计动态调延；首屏与卡顿恢复使用不同策略；
多条件判帧：M 位不可靠时依靠 FU 终止+NALU 语义校验；
零拷贝与池化：RTP 缓冲、片段拼接、帧缓存均采用池化与引用计数；
弱网容错：FU 缺片快速放弃、错误隐藏、按“可解码最小集合”尽快交付解码；
调参面板：MTU、抖动窗口、NACK/PLI（若上游支持）、TCP/UDP 强制切换、日志级别。
实践效果（方法论而非绝对值）：
内网 UDP：端到端可做到 <150–200 ms 的播放体验；
公网/蜂窝网络：视网络而定，在 100–300 ms 之间通过抖动缓冲/NACK/PLI 可达更稳态；
CPU/功耗：零拷贝/池化 + 硬解（可选）对多路并发收益显著。
Android平台RTSP播放器时延测试
8. 关键算法草图（示意伪代码）
发端：H.264 FU-A 打包（简化）
budget = mtu - (IP+UDP+RTP+ext)
for each NALU in access_unit:
if size(NALU) <= budget:
send_rtp_single_nal(NALU, M = is_last_nalu_of_frame)
else:
bytes_left = size(NALU) - 1 // skip NAL header
nal_hdr = NALU[0]
fu_hdr.S = 1; fu_hdr.E = 0; fu_hdr.Type = nal_hdr.type
while bytes_left > 0:
chunk = min(budget - FU_HEADER_LEN, bytes_left)
fu_hdr.S = (first_fragment ? 1 : 0)
fu_hdr.E = (bytes_left - chunk == 0 ? 1 : 0)
payload = [FU_INDICATOR(nal_hdr), fu_hdr] + next(chunk)
send_rtp(payload, M = fu_hdr.E && is_last_nalu_of_frame)
bytes_left -= chunk
收端：重排序 + FU 重组（简化）
on_rtp_packet(pkt):
if out_of_order(pkt.seq): insert_and_reorder(pkt)
frame_key = (pkt.ssrc, pkt.timestamp)
if is_single_nal(pkt): append_to_frame(frame_key, pkt.payload)
else if is_fu(pkt):
update_fu_state(frame_key, pkt)
if fu_complete(frame_key): append_reassembled_nal(frame_key)
if frame_complete(frame_key) or timeout(frame_key):
deliver_if_decodable(frame_key)
抖动缓冲自适应（简化）
jitter_ms = ewma(jitter_ms, measured_interarrival_jitter)
target_delay = clamp(base_delay + k * jitter_ms, min_delay, max_delay)
if underflows(): increase_delay_fast()
if stable(): decrease_delay_slow()
9. 调试与互通清单（落地必备）
Wireshark 过滤：
rtsp || rtp || rtcp；检查seq/timestamp/M/SSRC/PT、FU 连续性；SDP 校验：
rtpmap/fmtp/packetization-mode/profile-level-id/sprop-*是否与编码器一致；边界条件：IDR 前参数集是否齐备、跨帧 FU 是否越界、M 位不可靠时能否判帧；
MTU/分片：公网/隧道调低单包负载，避免下层再分片；
UDP/TCP 回退：确保 SETUP 失败后有兜底路径；
RTCP：开启 SR/RR 统计，必要时 PLI/NACK（设备支持时）。
结语
RTP 的打包与解包不是“写几百行代码”就能一劳永逸的模块，它承载了跨平台互通、弱网韧性、低延迟体验三者之间的长期权衡。遵循 RFC 3550/3551、RFC 6184、RFC 7798 等核心规范，结合 JitterBuffer 自适应、FU/STAP 正确实现、UDP/TCP 模式取舍、RTCP 反馈与工程化零拷贝，才能把“能播”做成“播得稳、播得顺、播得优”。
大牛直播SDK 在轻量级 RTSP 服务与跨平台 RTSP 播放器中，已将上述要点沉淀为可复用的能力：发端自适应打包、收端稳态重组与抖动控制、双栈传输与安全认证、可观测与调参。这类“底层稳定器”，正是 AI 原生与行业落地的必要前提。
📎 CSDN官方博客：音视频牛哥-CSDN博客