自定义UDP视频传输中的处理层设计：分片、重传与抖动缓冲实战解析

这活儿我干过不少次了——领导丢来一句“要做一个能在低延时下传视频的模块，网络条件不好也得凑合看”，然后你打开文档一看：不能用TCP，不能上RTSP那套，得自己定UDP协议。自定义UDP协议视频传输，听起来很自由，真正动手之后你会发现，编解码反而是最不用操心的部分，最容易被写烂、最考验功底的是中间那层“处理层”。

所谓处理层，就是夹在编解码器和sendto/recvfrom之间的所有逻辑：分片、编号、排序、去重、重传、抖动缓冲、流控。协议头设计得再漂亮，如果处理层做得糙，画面照样花屏、卡顿、延迟爆炸。这篇文章就把我在这层上踩过的坑、验证过靠谱的方案、可以直接抄的代码骨架全部倒出来，给同样在做自定义UDP视频传输的同行当个参考。

1. 为什么不用现成方案，以及处理层到底在管什么

先聊清楚出发点。自定义UDP视频传输通常出现在两类场景：一类是局域网内的低延时投屏/采集传输，延时要求做到几十毫秒级；另一类是公网环境下要对抗不可控的丢包和抖动，但又不想要完整RTC那套信令和ICE的负担。在这两种场景下，现成方案各有各的别扭。

TCP的问题在于头阻塞和重传机制。网络一抖动，一个segment丢了，后面的数据全部卡在缓冲区里等重传，对音视频来说这个“等”是致命的。TCP的重传语义是“必须送达”，而视频帧是有生命周期的，超过显示时间没到，送到了也没意义。UDP把控制权完全交给你，丢不丢、怎么补、补几次，都自己说了算，这正是实时传输需要的。

直接用RTP呢？RTP本身也只定义了数据包头格式，分片、序号、时间戳这些它确实给了标准，但实际工程里你仍然需要自己写会话管理、丢包统计、重传决策、接收端重组逻辑。RTP不是“拿来就能用”，它是一套需要继续造轮子的规范。与其被它的字段约束，不如按自己的业务场景设计一套更精简的协议。WebRTC倒是功能齐全，但SRTP、ICE、DTLS、拥塞控制全堆上来，代码复杂度和调试成本都翻倍，搞一个内部系统或者专用设备链路属于杀鸡用牛刀，而且很多场景根本不需要浏览器互通。

1.1 处理层的边界

一个完整的UDP视频传输链路大概是这个顺序：

• 采集/解码层：摄像头、屏幕捕获或者解码器输出的帧数据。
• 编码层：H.264/H.265软硬编码，输出原始码流。
• 处理层：拿到编码后的帧，做分片、打包、加序号、加时间戳、维护发送窗口、处理对端反馈、控制发送节奏。
• 对端处理层：收包、排序、去重、组帧、丢包发现、触发重传请求、做抖动缓冲。
• 解码渲染层：把重组后的完整帧交给解码器。

可以看到，处理层是唯一同时接触“码流语义”和“网络特性”的地方。它要懂编码出的帧有多大、是不是关键帧，也要懂MTU、RTT、丢包率、抖动。协议层规定的只是包长什么样，而处理层决定这套协议在真实网络里能不能跑起来。

我见过太多“demo能做通，一上复杂网络就卡死”的项目，问题几乎都出在处理层的边界没划清楚：有人把分片逻辑写进编码线程，导致编码帧率抖动；有人把重传决策放在接收端的主循环里，结果一丢包整个解码进程跟着卡顿；还有人把处理层和协议头混在一起，想加一个字段就得改所有收发模块。

处理层应该做到两件事：对上提供“输入完整帧、按序输出完整帧”的接口，对下屏蔽网络细节。发送侧处理层的接口是SendFrame(frame_data, frame_len, frame_type)，接收侧处理层的接口是OnFrameReady(frame_data, frame_len)。至于中间用的是多少次重传、怎么排序、怎么调速，对于上层的解码器和采集器来说应该是透明的。

1.2 “协议格式”与“处理逻辑”是两件事

一个常见误区是：设计了一套看起来很严密的包头结构，就认为协议做完了。实际上，协议格式只是“静止的约定”，处理层才是“动态的行为”。

举个例子，包头里定义了序号字段，这只是格式。真正的问题是：接收端发现序号不连续时应该怎么办？是立刻发NACK，还是再等两个包？等待多久？重传请求要不要合并？接收端的重组缓冲区最多容忍多少乱序？这一系列决策都是处理层的逻辑，和包头定义无关，难做的恰恰是这些决策。

很多人被卡住，就是因为把精力全花在“位对齐”“字段顺序”上，结果最核心的重传决策、缓冲管理、节奏控制完全没设计，一跑起来就发现：丢包之后画面直接卡死、乱序之后解码器报错、长时间运行内存涨个不停。

从这层意义上说，处理层才是自定义UDP视频传输里真正决定体验的部分。所以这篇文章的重点会放在处理层的设计和实现细节上，包头设计只挑最必要的部分讲。

2. 协议头设计：处理层的地基

没有一套统一标准的自定义协议头，但处理层的所有逻辑都建立在包头字段之上。你要做排序就需要序号，做重组就需要分片信息，做时间戳同步就需要时间字段，做关键帧请求就需要帧类型标志。这些东西不是拍脑袋定的，每一个字段背后都有对应的处理逻辑需求。

2.1 一套够用的包头结构

我在项目里用的包头结构大概是这样的：

#pragma pack(push, 1) struct VideoPacketHeader { uint16_t magic; // 固定 0x5A5A，快速过滤非本协议包 uint8_t version; // 协议版本，方便后续兼容 uint8_t flags; // bit0: 帧起始包, bit1: 帧结束包, bit2: 关键帧, bit3: 重传包 uint16_t stream_id; // 流ID，区分多路视频/音频/数据 uint8_t pkt_type; // 0: 数据包, 1: NACK, 2: ACK, 3: 心跳/关键帧请求 uint32_t frame_seq; // 帧序号，每帧递增 uint16_t pkt_idx; // 包在帧内的索引，从0开始 uint16_t total_pkts; // 当前帧一共分成多少个包 uint32_t frame_len; // 整个帧的字节数 uint32_t timestamp; // 相对会话开始的时间戳，单位ms uint16_t payload_len; // 本包数据长度 uint16_t checksum; // 对包头做简单校验 }; #pragma pack(pop)

逐个说下为什么需要这些字段。

• magic和version：实战中UDP端口可能被其他程序占用，或者收到网络里扫描器的乱包，magic字段能在接收端第一道关就过滤掉垃圾数据。version字段看起来鸡肋，但协议迭代时能救命——老版本接收端遇到新版本包，可以直接丢弃并打日志，而不是解析出错。
• flags：关键帧标志特别重要。H.264的IDR帧体积是P帧的好几倍，丢包后接收端需要主动请求关键帧重置参考关系，处理层如果不知道当前帧是不是关键帧，这事情就没法做。帧起始和结束标志可以加速接收端判断“一个完整帧是否齐了”，有了它就不用傻等所有分片到齐。
• frame_seq和pkt_idx：这里我特意用了“帧序号+帧内包索引”的组合，而不是一个全局的包序号。好处是接收端重组时逻辑非常清晰：同一帧的包凑齐了就是完整帧，不需要额外记录帧边界。有些设计用全局包序号，想省字段，结果接收端反而要维护“包序号到帧归属”的映射，得不偿失。
• frame_len：这个字段让接收端可以预先知道要分配多大的重组缓冲区。UDP包到达顺序是乱的，但有了frame_len，第一帧起始包一到就能把缓冲准备好，不用等所有包到了再拼接，性能差距很明显。
• timestamp：视频渲染需要时间戳，发送端采集时打好时间戳，接收端根据它决定等待渲染，或者做音视频同步。注意我强调的是“相对会话开始的时间”，而不是系统绝对时间，原因后面说。
• checksum：IP层和UDP层的校验和只覆盖头部不保证数据内容，所以在高误码率的无线环境里，数据包内容可能被篡改。对包头做个轻量校验，发现坏包直接丢弃，避免污染重组缓冲。

还有两点工程细节。第一，所有字段用网络字节序，如果只在Linux小端机器上跑，你可能觉得没必要，但一旦接收端是ARM板子、解码器是Windows或者Android，大小端问题会让你排查到怀疑人生。统一用htonl/htons转换，成本极低。第二，用#pragma pack(1)压缩对齐，这个头不带任何填充，总共26字节。别小看这26字节，一个4MB的关键帧分1400字节一个包，就要多出接近三分之一的包数，每一包多26字节头，带宽浪费不小。

2.2 序列号和时间戳的那些坑

序列号最大的坑是回绕。如果你用16位序号，最大只有65535，按每秒25帧来算，每帧可能分成几十个包，全局包序号几秒钟就回绕一次。接收端判断“序号是否连续”时必须用带符号差值比较：

// 判断 a 是否在 b 之前，考虑回绕 bool is_older(uint32_t a, uint32_t b) { return (int32_t)(a - b) < 0; }

这个技巧是用无符号减法再强转有符号数，利用二进制补码的天然回绕特性。很多人直接写if (seq > last_seq)判断连续性，回绕一出就出大问题——明明是新的序号却比旧的还小，被当成重传包丢掉，画面莫名花屏。

时间戳的坑更隐蔽。我最早用gettimeofday直接打时间戳，结果系统时间一被NTP调整，整条链路的渲染节奏全乱了，画面上视频一下子快进一下子暂停。后来改成从会话开始时用clock_gettime(CLOCK_MONOTONIC)累计，单调递增时钟不受系统时间跳变影响。

时间戳有精度问题。帧间隔是40毫秒（25fps），如果精度只到毫秒，时间戳能区分帧序但不够做精确渲染。有条件的话打到微秒级，接收端做插值更平滑。另外，多路流同步（比如一路视频加一路音频）时，要保证两路都用同一个单调时钟源，否则各自偏移一点，唇形同步根本对不上。

3. 分片、重组与乱序处理：核心中的核心

处理层最繁重的任务就是分片和重组。编码器吐出来的帧是连续的缓冲区，而UDP包有最大长度限制，中间夹着一个MTU的概念，不理解MTU就谈不上分片。

3.1 分片大小怎么定

标准以太网MTU是1500字节，IP头20字节，UDP头8字节，所以UDP负载最多1472字节。如果你的协议头26字节，分片数据体最多1446字节。大多数工程上会再保守一点，数据体控制在1400字节，给实际网络中的额外开销留余地。

这个数字怎么来的：1500 - 20 - 8 - 26 = 1446，取整到1400是因为有些场景中间还隔着隧道或者虚拟网卡，MTU可能比你期望的小。分片大小设大了，触发IP层分片，后果是：路由器可能丢弃分片包，接收端靠IP层重组也会大幅增加处理开销和丢包概率。

分片逻辑其实很直接：

int pack_frame(uint8_t *frame_data, size_t frame_len, uint32_t frame_seq, uint8_t flags, uint8_t *out_buf, size_t out_size) { const size_t max_payload = 1400; uint16_t total_pkts = (frame_len + max_payload - 1) / max_payload; size_t offset = 0; for (uint16_t i = 0; i < total_pkts; i++) { VideoPacketHeader *hdr = (VideoPacketHeader *)out_buf; size_t payload = min(max_payload, frame_len - offset); hdr->magic = 0x5A5A; hdr->flags = flags; if (i == 0) hdr->flags |= PKT_FLAG_START; if (i == total_pkts-1) hdr->flags |= PKT_FLAG_END; hdr->frame_seq = frame_seq; hdr->pkt_idx = i; hdr->total_pkts = total_pkts; hdr->frame_len = frame_len; hdr->payload_len = payload; memcpy(out_buf + 26, frame_data + offset, payload); offset += payload; out_buf += 26 + payload; } return total_pkts; }

有个细节值得单独提：分片结果里，每个包的payload是否完整覆盖帧数据，接收端重组时直接按pkt_idx拼接就行，不需要像H.264那样识别NAL边界。因为你的处理层只管“完整帧的可靠到达”，至于帧内部是不是从SPS/PPS开头、有没有完整NAL单元，那是编码器输出格式的事。传输前你可以选择对齐NAL切分以支持部分转发，但对大多数“整帧发送、整帧解码”的架构，按长度切分最简单可靠。

关键帧值得特殊对待。IDR帧通常几百KB甚至几MB，分片数可能是P帧的几十倍，丢包概率随之升高。我会在flags里标记关键帧，接收端发现关键帧缺失时，不是漫无目的地等，而是立刻触发“关键帧请求”消息回传给发送端，让编码器强制出一个新的IDR帧。

3.2 重组缓冲设计

接收端重组缓冲的核心是一个“按帧索引的等待表”。每一帧需要记录：总包数、已收到的包位图、数据缓冲、首包到达时间。

struct FrameBuffer { uint32_t frame_seq; uint32_t frame_len; uint16_t total_pkts; std::vector<uint8_t> data; std::vector<bool> received; // 位图，标记每个分片是否收到 uint64_t first_pkt_time_ms; // 第一个包到达时间 bool is_keyframe; };

每收到一个包，处理逻辑是：

1. 解析包头，用frame_seq找到对应的FrameBuffer；不存在就新建。
2. 如果pkt_idx已经收到过，直接丢弃（重复包）。
3. 否则把payload拷到data[pkt_idx * 1400]位置，标记received[pkt_idx] = true。
4. 检查位图，如果全为true，说明整个帧齐了，把data交给解码线程，释放FrameBuffer。
5. 如果first_pkt_time_ms距当前超过超时阈值（比如300ms）还没齐，判定这帧无法组齐，清空并触发重传或关键帧请求。

乱序是常态，不是异常。UDP在不同网络路径下会乱序，所以重组缓冲必须容忍乱序，允许范围取决于你的窗口大小。实际开发中我用的是一个std::map<uint32_t, FrameBuffer>，按frame_seq排序，容量限制比如8个帧；超过容量时丢弃最旧帧。这个设计简单、稳定，性能在帧率不高时完全够用，不需要上超高效率的Hash表。

重组缓冲有个必须处理的内存问题：关键帧很大，如果同时有多个大帧在缓冲里等待，内存会暴涨。假设缓冲容量8帧，每帧最大4MB，最坏情况占32MB，这在嵌入式设备上是不可接受的。所以要限制单帧最大长度——超过比如8MB的帧直接拒绝组包并发送关键帧请求，同时限制在缓冲的帧总字节数，超过阈值就把最老的丢帧。

3.3 抖动缓冲：给解码一个稳定节奏

网络到达间隔不规则，如果每收到一个完整帧就立刻送解码，输出帧率会忽高忽低，这就是为什么处理层要有一个抖动缓冲。

抖动缓冲的原理很简单：不达阈值不解码。接收侧维护一个完整帧队列，队列里的帧先攒着，只有当最早帧的时间戳与当前时间差达到目标延迟（比如60ms）时才开始出队。网络抖动大的时候，缓冲会消耗掉一部分延时来换取平滑；网络平稳的时候，缓冲值可以适当减小。

更进阶的做法是自适应抖动缓冲：统计最近200个包的到达间隔方差，方差大就自动加大缓冲，方差小就减小。但自适应调节要小心滞后效应，调太猛会造成延迟来回摆动，观感比固定延迟还差。工程上我建议先固定一个50~100ms的缓冲，跑通之后再有针对性地做自适应。

4. 丢包重传与发送节奏控制

处理层的重传决策直接决定了画面“卡不卡”。重传做太狠，网络里全是重传包，正常数据被挤占；重传做太松，一丢包就花屏，还得靠请求关键帧救场。

4.1 视频场景下该用NACK而不是ACK

TCP的ACK方式是“全部确认到最后”，它的问题在于不知道具体丢在哪儿，只能靠超时重传整个队列。自定义UDP下，视频传输应该用选择性重传，也就是NACK（Negative ACK）机制。

接收端发现序号出现空洞时，不等待立即发NACK，携带缺失的包序号列表，发送端收到后只重传缺失包。视频里我们关心的是“补齐这一帧”，而不是“确保所有历史包都到达”。这种机制配合前面的重组缓冲设计非常简洁：重组缓冲里标记缺失的pkt_idx名单，超过NACK重传阈值后补发。

NACK请求必须合并。一个4MB关键帧分了3000个包，中间丢了三段，如果每发现一个空洞就发一次NACK，接收端能在几十毫秒内打出上百个NACK包，发送端处理NACK的CPU开销反而成了瓶颈。实战做法是：接收端每20ms集中扫描一次重组缓冲，把所有缺失包合并成一条NACK发出去。丢包率10%以内时，这种合并策略完全可接受。

4.2 重传的“保质期”概念

视频包有deadline。假设当前RTT是30ms，一个包的剩余生命周期只剩20ms，重传它已经没有意义——等到重传包到达，解码时机早就过了。所以每个待重传的包都要计算剩余有效时间：

bool should_retransmit(uint64_t sent_time_ms, uint64_t now_ms, uint64_t deadline_ms) { uint64_t elapsed = now_ms - sent_time_ms; return elapsed + estimated_rtt_ms < deadline_ms; }

超过deadline直接放弃重传，接收端那边依靠帧不完整超时机制去请求关键帧。这个策略总结成一句话：小丢包靠NACK兜底，大丢包靠关键帧重置。

重传次数要限制，一般不超过2次。NACK风暴的原因通常是接收端疯狂请求已经放弃的包，或者发送端把同一包重传多次。我在发送端维护一个重传窗口，记录每个包的重传次数，超过阈值就不再重传并且向上层反馈“丢帧了”。

4.3 发送节奏与Pacing

用UDP传视频最忌讳“一次性把一个帧的几百个包全部甩给网卡”。内核发送缓冲区不一定能吞下这么大的突发，即使能吞下，也会在短时间内大量占用路由器队列，造成真正的网络拥塞。好做法是Pacing——把一帧的包均匀分布到帧周期内发送。

计算很简单。假设帧率25fps，每帧间隔40ms，一个P帧分了80个包，那么每个包间隔40ms / 80 = 0.5ms：

uint32_t frame_period_ms = 1000 / frame_rate; uint32_t pkt_interval_us = frame_period_ms * 1000 / total_pkts;

用1000微秒级精度的定时器控制发送。注意不能用usleep这种粗精度方式，Linux下用timerfd或者nanosleep。发送时还要兼顾重传包和心跳/控制包，可以把它们的优先级提高。实测下来，同样3000kbps码率，不分包突发发送和均匀pacing发送，接收端抖动能差出两三倍。

4.4 拥塞控制不能完全放弃

有人说局域网里丢包率低就不用做拥塞控制，这是错的。即使一开始是1Gbps内网，如果接收端解码能力跟不上，或者无线链路的干扰导致突发丢包，没有流控的系统就会不断把码率拉高，把网络打爆。

简易的AIMD就够用：每收到一轮接收端的“累计确认”而无重传，就把发送码率上调5%；每次触发NACK或接收端报告丢包率超过阈值，就下调15%~20%。而且发出去的码率变化一定要反馈给编码器，让编码器的目标码率跟着变。我见过最蠢的做法是发送端自己pacing，但编码器还按固定码率出流，码率降不下去，网络拥塞依旧。

整套重传和流控逻辑需要实时感知RTT和丢包率。怎么估？发送端记录每个包的发送时间，接收端在ACK/NACK里带回“最近收到的最后一个包序号”，发送端用这个序号对应的时间差就能算出RTT。丢包率用(应到包数 - 实际到包数) / 应到包数统计，以每秒为一个窗口。

5. 发送端与接收端的处理层实现骨架

理论说了不少，直接上可运行的骨架逻辑。我这套结构在Linux上用C++实现，关键是职责分离——发送线程只负责从队列拿帧、分片、发送、维护重传窗口；接收线程只负责收包、解析、入重组缓冲、定时扫描。不要让编解码线程碰网络I/O。

5.1 发送端处理流程

void SendSession::SendFrame(uint8_t *frame, size_t len, bool keyframe) { uint32_t seq = frame_seq_++; uint16_t total = (len + MAX_PAYLOAD - 1) / MAX_PAYLOAD; auto burst_start = now_us(); for (uint16_t i = 0; i < total; i++) { // 填充包头，拷入分片数据 PackOnePacket(frame, len, seq, i, total, keyframe); // 存入重传窗口，等待可能的重传请求 retrans_win_.AddPacket(seq, i, packet_buf, packet_len); // 发送 sendto(sockfd_, packet_buf, packet_len, 0, ...); // pacing间隔 SleepUntil(burst_start + i * pkt_interval_us_); } }

重传窗口用环形数组实现，按包序号索引。收到接收端NACK时，在窗口里查对应包，如果还在有效期内就重发。重传包和正常数据包要复用同一个SendFrame发送流程吗？不。重传包绕过pacing，直接立即发送，因为它本身就是在抢时间。

发送端还要持续更新码率参数。我单独开了一条控制通道（走同一个UDP socket，通过pkt_type区分），接收端每200ms上报一次丢包率、RTT和接收端抖动值。发送端汇总后做AIMD决策，把结果传给编码器接口：

void SendSession::OnReceiverReport(ReportMsg *msg) { rtt_ms_ = msg->rtt_ms; loss_rate_ = msg->loss_rate; if (loss_rate_ < 0.02) { target_bitrate_ = (uint32_t)(target_bitrate_ * 1.05); } else { target_bitrate_ = (uint32_t)(target_bitrate_ * 0.85); } encoder_->SetBitrate(target_bitrate_); }

5.2 接收端处理流程

接收端的核心是一个多线程协作模型：

1. 收包线程：recvfrom，只做包头解析，把有效包放入无锁队列。
2. 组装线程：从队列拿包，更新重组缓冲，扫描缺失包、发NACK。
3. 解码线程：从完整帧队列拿帧，交给解码器。

收包线程尽量短小精悍，不要在收包线程里做任何可能耗时的操作，比如内存分配。我用的做法是收包线程固定分配一块预置缓冲，解析完拷贝一份到帧缓冲后再返回。这样recvfrom的调用频率保持在极高状态，不太会因为处理慢导致内核缓冲区溢出丢包。

组装线程的伪代码大致是：

void AssembleThreadLoop() { while (running) { Packet pkt = pkt_queue_.Pop(); FrameBuffer *fb = GetOrCreateFrameBuffer(pkt.frame_seq); InsertPacket(fb, pkt); if (fb->AllReceived()) { deliver_queue_.Push(fb->data); release_frames_.erase(pkt.frame_seq); } // 每20ms扫描一次缺失包 if (now - last_nack_time > 20ms) { CollectMissingPkts(); // 合并缺失包列表 SendNack(missing_list); last_nack_time = now; } // 清理超时帧 CleanupTimeoutFrames(); } }

解码线程从deliver_queue_按时间戳顺序取帧，先过一层抖动缓冲，到时间后再送入解码器。这里有一个重要开关：是否允许丢帧。如果开启“跳帧模式”，解码线程发现队列里的帧落后太多，就直接跳过，保证渲染卡顿而不是越走越慢。

5.3 线程安全的几个关键点

处理层涉及多线程，最容易踩的坑是共享数据竞争。我的原则是每个线程只访问自己的核心数据结构，通过队列传递所有权，而不是共享指针。

重组缓冲只归组装线程所有，解码线程绝不直接改它。解码线程只从deliver_queue_拿“已经组装好的帧”，这个队列是SPSC（单生产者单消费者）无锁队列。NACK队列是组装线程向网络线程发消息用的，用一个列表加互斥锁就行，因为频率极低（20ms一次）。

发送端的重传窗口由发送线程独占，接收端上报的处理线程只把NACK消息塞进一个消息队列，发送线程每轮循环取消息处理。这样做的好处是：就算接收端抽风疯狂发NACK，发送线程也不会因此乱掉自己的分片节奏。

6. 常见问题与排查实录

自定义UDP视频传输调试起来比TCP痛苦得多，因为TCP有内核帮你排序、确认，UDP裸奔出去什么都可能发生。整理几个我实际遇到过的典型问题，做成一个速查表，方便你以后对照排查。

6.1 问题速查表

6.2 排查思路和工具

排查UDP视频传输我基本靠三板斧：抓包、打日志、画时间线。抓包工具首选tcpdump，过滤条件加上UDP端口：tcpdump -i eth0 -s 200 udp port 12345 -w dump.pcap。导出后用Wireshark看，重点看序列号是否连续、重传包分布、RTT趋势。Wireshark自带分析功能，把seq号作为序列过滤器能看到乱序和重传情况。

日志要打在关键决策节点：发送端记录每个帧的分片数、pacing间隔、NACK响应次数；接收端记录重组的等待时间、缺失包数量、抖动缓冲水位。用LD_PRELOAD或者直接打印到环形缓冲，运行结束后再导出来通过脚本统计。没有日志的UDP传输调试就是盲人摸象，TCP还能靠内核来帮你兜底，UDP下的每次丢包都要靠日志定位是网络丢的还是自己丢了。

画时间线的意思是，把接收端收到的包序号和时间戳对齐画一张散点图，能一眼看出网络抖动和突发。有时候抓包发现丢包其实发生在发送端，因为sendto失败，或者发送线程被更高优先级的任务打断，pacing逻辑断了，这些不看时间线根本发现不了。

6.3 几个印象深刻的坑

第一个坑是误用系统时间做时间戳。项目第一个版本在局域网测得好好的，部署到生产环境后，用户反映视频声音画面对不上。查了半天，发现是接收端所在的服务器时间被同步软件校准，导致接收端时间戳突然跳变了几百毫秒，抖动缓冲一算是“视频起死回生”，实际是时间轴跳变。改回单调时钟之后问题彻底消失。

第二个坑是大帧组包导致的内存毛刺。有一路4K视频的IDR帧特别大，峰值内存飙到快100MB，嵌入式设备直接OOM。后来把“单帧最大长度”和“缓冲内总字节数”两个上限加上，超过时直接静帧并发关键帧请求，内存曲线立刻平稳。这类问题在短视频传输测试里发现不了，一定要用极限场景压测。

第三个坑是NACK重传丢进同一个pacing队列。最开始我把重传包也放进正常pacing队列里发送，结果一个IDR帧丢包后，所有重传包都在排队，反而把后续的P帧发送延迟几十毫秒，画面越来越卡。后来重传包独立出去直接发，用单独的socket低优先级发送线路，整体反而稳定。

第四个坑是人多踩的：分片不带端序号，只靠全局序号自己推断帧边界。听起来很省字段，但重组逻辑会极其痛苦——你不知道某个序号是否属于上一帧，必须在帧头和帧尾插入标记，稍有不慎就是一帧错位，后面全乱。我用上面那套“frame_seq + pkt_idx”之后，这个问题再没出现过。协议头多两个字段，省下的是无数调试时间。

7. 最后说两个我后来才想明白的点

一个关于关键帧请求的细节。接收端请求关键帧，本质是要一个全新的IDR帧，但有些编码器在收到强制IDR请求后，会把下一个GOP编码得特别大，反而加剧网络拥塞。后来我发现，请求关键帧时要顺带把发送端的目标码率临时调低一档，等这个IDR帧发完再调回去，画面恢复会平滑很多。这个“关键帧和码率联动”的思路，在很多商用方案里都见过。

另一个是职业习惯问题。处理层代码调通后千万别急着跑功能测试，先用网络损伤工具模拟丢包率1%、3%、5%、10%和乱序延迟，看系统的表现曲线。如果没有损伤工具，可以用Linux的tc配合随机丢包netem模拟：tc qdisc add dev eth0 root netem loss 5% delay 20ms 10ms distribution normal，实测下来的结果比我预想的要残酷得多——很多功能测试里“正常”的系统，5%丢包率下画面几乎不可看。提前跑了这些极限测试，后期上线才不会被用户骂。

自定义UDP视频传输的坑，说到底是协议容易写、处理层难做精。别指望一次设计完美，把分片重组、重传决策、节奏控制这几块核心逻辑做扎实，然后用极限网络条件去砸它，比任何纸上谈兵都有用得多。

如果你正在做类似的东西，建议从这篇文章里的骨架起步，先把一个最小链路跑通，再逐步加上关键帧请求、自适应缓冲、流控这些进阶逻辑。每一步都要用抓包和统计数据说话，别用“感觉差不多”来验收——视频出问题的时候，用户可不会说“感觉差不多”。