1. 从零开始：为什么需要V4L2 + WiFi实时视频传输？

大家好，我是Jerry，一个在嵌入式领域摸爬滚打了十多年的老码农。今天想和大家深入聊聊一个在安防监控、机器人视觉、远程实验室等领域非常核心的技术：基于V4L2与WiFi的嵌入式实时视频传输系统。

简单来说，这个系统就是让你手上的嵌入式开发板（比如常见的RK3588、树莓派、或者正点原子的板子），能够通过板载的MIPI摄像头“看到”东西，然后把看到的画面，通过WiFi网络，几乎无延迟地“直播”到你的电脑或者手机上。听起来是不是有点像家用监控摄像头？没错，原理类似，但我们要从底层开始，自己动手搭建，实现更灵活、更可控、性能更强的定制化方案。

为什么不用现成的方案，比如直接调用GStreamer的v4l2src配合udpsink？我在很多项目初期也这么干过，确实快。但当你需要应对复杂的网络环境（比如WiFi信号不稳定）、需要极致的低延迟（比如机器人避障）、或者需要对每一帧数据进行AI分析处理时，现成的“黑盒”管道就显得力不从心了。你需要清楚地知道数据从哪里来、经过了哪里、到哪里去，才能在出现卡顿、花屏、高延迟时，精准地定位问题并优化。

所以，自己动手搭建一个从V4L2采集到WiFi发送的完整数据流，是深入理解嵌入式视频处理、网络编程和系统优化的绝佳路径。这个过程会涉及到Linux驱动、多线程编程、网络协议、环形缓冲区设计等一系列核心知识。别担心，我会用最直白的方式，带你走通全流程，并分享我踩过的坑和优化经验。

2. 系统架构设计：多线程与缓冲队列是核心

一个稳定、高效的实时视频传输系统，绝不是简单地把摄像头数据读出来然后一股脑塞进网络。它的核心在于解耦和缓冲。想象一下，采集摄像头数据是一个工人（生产者），发送网络数据是另一个工人（消费者）。如果让一个工人干完采集立刻去发送，那么网络稍微一卡顿，整个流水线就停了，摄像头那边还在源源不断地生产新数据，旧数据没地方放就只能丢弃，导致“卡顿”和“丢帧”。

2.1 核心数据流与多线程模型

我们的系统架构，本质上是一个经典的生产者-消费者模型。下面这张图清晰地展示了数据是如何流动的：

[摄像头硬件] --> [V4L2驱动层] --> [采集线程] --> [环形缓冲区] --> [发送线程] --> [WiFi网络] --> [远程主机]

采集线程（生产者）：它的任务非常单纯，就是不停地从/dev/videoX这个设备节点，通过V4L2接口把视频帧“捞”上来。它不关心网络是否通畅，只关心能不能尽快拿到下一帧。为了高效，我们通常使用mmap内存映射方式，让驱动直接把帧数据映射到用户空间，避免read函数的拷贝开销。

发送线程（消费者）：它的任务是从环形缓冲区里取出已经采集好的帧，加上必要的包头信息（比如帧序号、时间戳），然后通过UDP Socket发送出去。它不关心这一帧是什么时候采集的，只关心缓冲区里有没有数据可发。

环形缓冲区（共享内存区）：这是连接生产者和消费者的桥梁，也是一个关键的“蓄水池”。当网络波动导致发送变慢时，采集到的帧可以暂时存放在这里，避免被立即丢弃；当网络恢复时，发送线程可以从缓冲区里取出积压的帧继续发送。这个缓冲区的大小需要仔细权衡：太小了，缓冲作用有限；太大了，会引入额外的延迟（因为最新的帧要等前面的旧帧发完）。

在实际项目中，我通常会为这个环形缓冲区设计一个结构体，里面不仅存放帧数据指针，还要包含帧的元信息：

typedef struct {
    void *start;      // 指向帧数据的指针（mmap获得）
    size_t length;    // 帧数据长度
    uint32_t seq;     // 帧序号，用于丢帧检测
    struct timeval timestamp; // 采集时间戳
} buffer_t;

// 环形缓冲区结构
typedef struct {
    buffer_t *buffers;
    int capacity;     // 缓冲区容量（帧数）
    int head;         // 生产者写入位置
    int tail;         // 消费者读取位置
    pthread_mutex_t mutex;
    pthread_cond_t cond_not_empty; // 缓冲区非空条件变量
    pthread_cond_t cond_not_full;  // 缓冲区非满条件变量
} ring_buffer_t;

2.2 为什么选择UDP而非TCP？

这是新手最容易困惑的问题之一。TCP不是更可靠吗？为什么视频传输反而要用“不可靠”的UDP？

这完全是由视频数据的特性决定的。视频流是连续的、实时的，对延迟的敏感性远高于对绝对可靠性的要求。想象一下视频通话，你宁愿看到对方画面偶尔有一小块马赛克（丢了一小部分数据），还是愿意看到对方一句话说完后，画面卡住2秒再突然快进（等待TCP重传）？

• TCP的弊端：为了保证可靠传输，TCP有复杂的拥塞控制、丢包重传、按序交付机制。一旦发生丢包，后续的数据包即使已经到达，也必须等待丢失的包重传成功后才能提交给应用层，这就会造成队头阻塞，导致延迟急剧增加和卡顿。
• UDP的优势：UDP简单、粗暴。它只管把数据包扔出去，不保证到达，不保证顺序。这正好符合我们的需求：
  1. 低延迟：没有重传和确认机制，数据发出后无需等待。
  2. 容忍丢包：视频编码（如H.264）本身有一定容错能力，丢失个别数据包可能只影响局部画面，甚至人眼难以察觉。我们可以通过帧序号检测丢包，但通常选择直接忽略，继续播放下一帧，保证流畅性。
  3. 无连接：开销小，适合一对多广播（比如监控视频分发给多个客户端）。

当然，UDP也不是完全放任不管。我们会在应用层添加简单的协议头，比如帧序号和长度，让接收端能识别帧边界和检测丢包，这是实现一个健壮系统的基础。

3. 实战第一步：V4L2摄像头采集详解

理论说再多，不如一行代码。我们直接进入实战环节，看看如何用V4L2把摄像头数据抓出来。

3.1 打开设备与参数配置

首先，你得找到你的摄像头。在Linux下，插上MIPI摄像头模块后，通常会在/dev/下出现video0、video1这样的设备节点。你可以用v4l2-ctl --list-devices命令来查看。

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <fcntl.h>
#include <unistd.h>
#include <sys/ioctl.h>
#include <sys/mman.h>
#include <linux/videodev2.h>

int main() {
    // 1. 打开设备
    const char *dev_name = "/dev/video0";
    int fd = open(dev_name, O_RDWR);
    if (fd < 0) {
        perror("打开视频设备失败");
        return -1;
    }

    // 2. 查询设备能力
    struct v4l2_capability cap;
    if (ioctl(fd, VIDIOC_QUERYCAP, &cap) == -1) {
        perror("查询设备能力失败");
        close(fd);
        return -1;
    }
    if (!(cap.capabilities & V4L2_CAP_VIDEO_CAPTURE)) {
        fprintf(stderr, "设备不支持视频采集\n");
        close(fd);
        return -1;
    }
    if (!(cap.capabilities & V4L2_CAP_STREAMING)) {
        fprintf(stderr, "设备不支持流式I/O (mmap)\n");
        close(fd);
        return -1;
    }

    // 3. 设置采集格式（分辨率、像素格式）
    struct v4l2_format fmt;
    memset(&fmt, 0, sizeof(fmt));
    fmt.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
    fmt.fmt.pix.width = 1920;      // 宽度
    fmt.fmt.pix.height = 1080;     // 高度
    fmt.fmt.pix.pixelformat = V4L2_PIX_FMT_YUYV; // 常用YUV格式，也可以是MJPEG、H264等
    fmt.fmt.pix.field = V4L2_FIELD_NONE;

    if (ioctl(fd, VIDIOC_S_FMT, &fmt) == -1) {
        perror("设置格式失败");
        close(fd);
        return -1;
    }
    printf("设置格式成功: %dx%d, 像素格式: 0x%08X\n",
           fmt.fmt.pix.width, fmt.fmt.pix.height, fmt.fmt.pix.pixelformat);

    // ... 后续步骤：申请缓冲区、启动流
}

这里有几个关键点：

• 像素格式：V4L2_PIX_FMT_YUYV是常见的未压缩YUV格式，数据量大但处理灵活。如果你的摄像头支持（并且你希望节省带宽），可以直接输出V4L2_PIX_FMT_MJPEG（Motion JPEG）甚至V4L2_PIX_FMT_H264（需要硬件编码器支持，如RK3588的MPP模块）。
• 流式I/O：我们检查了V4L2_CAP_STREAMING，这是使用mmap内存映射方式的前提，性能远高于传统的read/write。

3.2 内存映射与采集循环

配置好格式后，我们需要向驱动申请若干缓冲区，并将其映射到用户空间。

// 4. 申请缓冲区（Request Buffers）
struct v4l2_requestbuffers req;
memset(&req, 0, sizeof(req));
req.count = 4; // 申请4个缓冲区，根据实际情况调整
req.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
req.memory = V4L2_MEMORY_MMAP; // 使用内存映射方式

if (ioctl(fd, VIDIOC_REQBUFS, &req) == -1) {
    perror("申请缓冲区失败");
    close(fd);
    return -1;
}
if (req.count < 2) {
    fprintf(stderr, "缓冲区数量不足\n");
    close(fd);
    return -1;
}

// 5. 映射每个缓冲区到用户空间
buffer_t *usr_buffers = calloc(req.count, sizeof(buffer_t));
for (int i = 0; i < req.count; ++i) {
    struct v4l2_buffer buf;
    memset(&buf, 0, sizeof(buf));
    buf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
    buf.memory = V4L2_MEMORY_MMAP;
    buf.index = i;

    if (ioctl(fd, VIDIOC_QUERYBUF, &buf) == -1) {
        perror("查询缓冲区信息失败");
        goto cleanup;
    }

    usr_buffers[i].length = buf.length;
    usr_buffers[i].start = mmap(NULL, buf.length,
                                 PROT_READ | PROT_WRITE,
                                 MAP_SHARED, fd, buf.m.offset);
    if (usr_buffers[i].start == MAP_FAILED) {
        perror("内存映射失败");
        goto cleanup;
    }

    // 将缓冲区放入驱动队列，等待填充数据
    if (ioctl(fd, VIDIOC_QBUF, &buf) == -1) {
        perror("队列化缓冲区失败");
        goto cleanup;
    }
}

// 6. 启动视频流
enum v4l2_buf_type type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
if (ioctl(fd, VIDIOC_STREAMON, &type) == -1) {
    perror("启动流失败");
    goto cleanup;
}
printf("视频流已启动，开始采集...\n");

// 7. 采集线程主循环
static uint32_t frame_seq = 0;
while (1) {
    struct v4l2_buffer buf;
    memset(&buf, 0, sizeof(buf));
    buf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
    buf.memory = V4L2_MEMORY_MMAP;

    // 从驱动已填充数据的队列中取出一个缓冲区 (DQBUF)
    if (ioctl(fd, VIDIOC_DQBUF, &buf) == -1) {
        perror("出队缓冲区失败");
        break;
    }

    // 此时，usr_buffers[buf.index].start 里就是最新的一帧图像数据
    buffer_t current_frame;
    current_frame.start = usr_buffers[buf.index].start;
    current_frame.length = buf.bytesused; // 实际使用的数据长度
    current_frame.seq = ++frame_seq;      // 递增帧序号
    gettimeofday(&current_frame.timestamp, NULL); // 获取时间戳

    // !!! 关键步骤：将帧放入环形缓冲区，供发送线程读取
    ringbuf_push(&g_ring_buffer, &current_frame);

    // 将取空的缓冲区重新放回驱动队列，等待下一次填充 (QBUF)
    if (ioctl(fd, VIDIOC_QBUF, &buf) == -1) {
        perror("重新入队缓冲区失败");
        break;
    }
}

这就是采集线程的核心循环。它不断地执行DQBUF（取出有数据的缓冲区）-> 处理/入环形队列 -> QBUF（归还空缓冲区）这个过程。注意，buf.bytesused非常重要，它表示这一帧实际的有效数据长度，可能小于缓冲区总长度。

4. 网络传输优化：UDP、分包与抗丢包策略

采集到的数据准备好了，现在要通过WiFi发送出去。UDP Socket编程基础这里不赘述，我们重点关注针对视频流的优化策略。

4.1 创建UDP Socket与目标设置

// 发送线程初始化部分
int sock_fd = socket(AF_INET, SOCK_DGRAM, 0);
if (sock_fd < 0) {
    perror("创建socket失败");
    return NULL;
}

// 设置发送缓冲区大小，避免发送速度过快导致本地丢包
int send_buf_size = 1024 * 1024; // 1MB
if (setsockopt(sock_fd, SOL_SOCKET, SO_SNDBUF, &send_buf_size, sizeof(send_buf_size)) < 0) {
    perror("设置发送缓冲区失败");
}

struct sockaddr_in dest_addr;
memset(&dest_addr, 0, sizeof(dest_addr));
dest_addr.sin_family = AF_INET;
dest_addr.sin_port = htons(5000); // 目标端口
inet_pton(AF_INET, "192.168.1.100", &dest_addr.sin_addr); // 目标IP，替换为你的主机IP

4.2 数据分包与重组：应对MTU限制

一个常见的坑是直接发送一整帧图像。对于1080P的YUV帧，一帧可能超过2MB。而以太网的MTU（最大传输单元）通常是1500字节，WiFi可能更小。一个超过MTU的UDP包会被IP层分片，但在复杂的网络环境中（尤其是经过NAT），分片包极易丢失，导致整个UDP包报废。

解决方案是：在应用层主动分包。 我们在发送端将大帧切割成小包，在接收端再组装起来。

发送端分包逻辑：

// 假设我们定义了一个简单的协议头
typedef struct {
    uint32_t frame_seq;   // 属于哪一帧
    uint16_t total_parts; // 该帧总包数
    uint16_t part_seq;    // 当前是第几个包
    uint32_t data_len;    // 本包数据长度
} __attribute__((packed)) packet_header_t;

void send_frame_over_udp(int sock_fd, struct sockaddr_in *dest, buffer_t *frame) {
    const size_t max_payload = 1400; // 预留空间给IP/UDP头，避免分片
    size_t frame_len = frame->length;
    uint8_t *frame_data = (uint8_t*)frame->start;

    uint16_t total_parts = (frame_len + max_payload - 1) / max_payload; // 计算总包数

    for (uint16_t i = 0; i < total_parts; ++i) {
        packet_header_t header;
        header.frame_seq = frame->seq;
        header.total_parts = total_parts;
        header.part_seq = i;

        size_t offset = i * max_payload;
        size_t this_part_len = (frame_len - offset) > max_payload ? max_payload : (frame_len - offset);
        header.data_len = this_part_len;

        // 构造发送缓冲区：包头 + 数据
        char send_buf[sizeof(packet_header_t) + max_payload];
        memcpy(send_buf, &header, sizeof(header));
        memcpy(send_buf + sizeof(header), frame_data + offset, this_part_len);

        sendto(sock_fd, send_buf, sizeof(header) + this_part_len, 0,
               (struct sockaddr*)dest, sizeof(*dest));
        // 实际项目中，这里最好检查sendto的返回值，并处理EAGAIN等错误
    }
}

接收端重组逻辑（Python示例）：

import socket
import struct
from collections import defaultdict

class FrameReassembler:
    def __init__(self):
        self.buffers = defaultdict(dict) # key: frame_seq, value: dict of parts

    def process_packet(self, data):
        # 解析包头
        header_fmt = '<IHHI' # frame_seq (I), total_parts (H), part_seq (H), data_len (I)
        header_size = struct.calcsize(header_fmt)
        frame_seq, total_parts, part_seq, data_len = struct.unpack(header_fmt, data[:header_size])
        part_data = data[header_size:header_size+data_len]

        # 存储分片
        if frame_seq not in self.buffers:
            self.buffers[frame_seq] = {}
        self.buffers[frame_seq][part_seq] = part_data

        # 检查是否收齐一整帧
        if len(self.buffers[frame_seq]) == total_parts:
            # 按顺序组装
            full_frame = b''
            for i in range(total_parts):
                full_frame += self.buffers[frame_seq][i]
            # 移除已完成的帧
            del self.buffers[frame_seq]
            return frame_seq, full_frame
        return None, None

sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
sock.bind(('0.0.0.0', 5000))
reassembler = FrameReassembler()

while True:
    data, addr = sock.recvfrom(65536)
    frame_seq, full_frame = reassembler.process_packet(data)
    if full_frame is not None:
        print(f"收到完整帧 {frame_seq}, 大小 {len(full_frame)}")
        # 这里可以调用解码、显示或AI处理函数
        # process_frame(full_frame)

4.3 自适应策略：应对网络波动

网络，尤其是WiFi，是不稳定的。我们需要让系统能适应这种波动。

1. 动态帧率调整：发送线程可以监控环形缓冲区的填充程度。如果缓冲区快满了（说明发送速度跟不上采集速度），可以通知采集线程动态降低采集帧率（通过ioctl设置V4L2_CID_EXPOSURE_AUTO等，或直接跳帧）。
2. 选择性丢帧：当缓冲区溢出时，与其阻塞采集线程，不如丢弃最旧的帧（ringbuf_pop_oldest），确保最新的画面能尽快发送出去。这对于实时性要求高的场景（如遥控）至关重要。
3. 前向纠错与重传：对于要求稍高的场景，可以在UDP基础上实现简单的ARQ（自动重传请求）或添加FEC（前向纠错）码。例如，每发送4个数据包，额外发送1个校验包，丢失1个包时可以恢复。但这会增加延迟和带宽，需要权衡。

5. 性能调优与深度踩坑经验

把系统跑起来只是第一步，让它跑得“稳”和“快”才是真正的挑战。下面分享几个我实际项目中遇到的坑和优化点。

5.1 内存与缓冲区管理

• 缓冲区数量：V4L2申请的缓冲区不是越多越好。通常4-6个是比较合适的值。太少可能导致驱动生产不及，太多则会增加内存占用和潜在的内存碎片。我一般从4开始，根据DQBUF的等待时间调整。
• 环形缓冲区大小：这个大小需要根据你的网络RTT（往返时间）和预期最大抖动来设置。一个经验公式是：缓冲区大小 >= 最大抖动时间(秒) * 采集帧率(帧/秒)。例如，网络最大抖动估计为200ms，帧率30fps，那么至少需要6帧的缓冲。我通常设置为10-15帧，提供一定的安全余量。
• 内存对齐：使用posix_memalign来分配对齐的内存，有时能提升memcpy或编码器的性能。

5.2 线程优先级与调度

在资源紧张的嵌入式平台上，线程调度策略影响巨大。

• 采集线程优先级应最高：它需要及时响应硬件中断，取出数据，避免硬件缓冲区溢出。可以使用pthread_setschedparam设置其为SCHED_FIFO实时策略和高优先级。
• 发送线程优先级次之：它需要及时清空应用层缓冲区，防止阻塞采集线程。
• 绑定CPU核心：如果平台是多核的（如RK3588八核），可以考虑将采集线程和发送线程绑定到不同的CPU核心上，避免核间切换开销。使用sched_setaffinity函数。

// 设置线程为实时优先级
struct sched_param param;
param.sched_priority = sched_get_priority_max(SCHED_FIFO);
pthread_setschedparam(采集线程id, SCHED_FIFO, &param);

// 绑定线程到特定CPU核心
cpu_set_t cpuset;
CPU_ZERO(&cpuset);
CPU_SET(0, &cpuset); // 绑定到CPU0
pthread_setaffinity_np(采集线程id, sizeof(cpu_set_t), &cpuset);

5.3 编码压缩：带宽与画质的权衡

直接传输原始YUV数据对带宽要求极高。1080P@30fps的YUV422流大约需要： 1920 * 1080 * 2 bytes/pixel * 30 fps ≈ 120 MB/s 这远远超过了普通WiFi的承载能力。因此，编码压缩是必选项。

• 硬件编码：像RK3588这类高端芯片，内置了强大的视频编解码器（如MPP模块）。我们可以直接使用V4L2请求配置摄像头输出H.264码流（如果驱动支持），或者使用MPP API对原始YUV进行硬件编码。这能极大降低CPU占用。搜索资料中提到的GStreamer案例（mpph264enc）就是利用了硬件编码。
• 软件编码：如果硬件不支持，可以使用libx264等软件库进行编码。但这会消耗大量CPU资源，需要测试你的平台能否扛住。
• 编码参数调优：关键参数包括码率、GOP大小、帧率。对于实时传输，建议使用较小的GOP（甚至全I帧），这样丢包影响范围小，但压缩率低。需要在延迟、容错和带宽间找到平衡点。

5.4 诊断与调试工具

系统出问题时，如何定位？

• v4l2-ctl：命令行神器，可以列出设备、查询支持格式、设置参数、抓图测试。v4l2-ctl --list-formats-ext 可以查看设备支持的所有分辨率和格式。
• 网络调试：
  • iperf3：测试WiFi实际带宽。
  • ping / mtr：检查网络延迟和抖动。
  • tcpdump / Wireshark：抓包分析，查看UDP丢包率、延迟。可以过滤你的目标端口，观察数据流是否连续。
• 系统监控：
  • top / htop：查看CPU占用，判断瓶颈在采集、编码还是发送。
  • vmstat / free：查看内存使用情况。
  • iotop：如果用了SD卡存储，查看IO是否成为瓶颈。
• 添加详细日志：在关键位置（如ringbuf_push/pop、sendto前后）打印帧序号和时间戳。在接收端也打印接收到的帧序号和时间戳，两者对比就能清晰看出端到端延迟和丢帧发生在哪个环节。

6. 进阶扩展：从单路到多路与低延迟优化

当你掌握了单路视频传输后，可以尝试更复杂的场景。

6.1 支持多路摄像头

思路很简单：为每个摄像头创建独立的采集线程和环形缓冲区，但共享一个或多个发送线程（或线程池）。需要注意：

1. 资源管理：每个V4L2设备需要独立的文件描述符和缓冲区组。
2. 数据区分：在协议头中增加camera_id字段，让接收端能区分不同来源的视频流。
3. 发送负载均衡：如果多路视频总带宽超过WiFi物理极限，需要考虑动态调整各路视频的码率或帧率，或者使用更高规格的WiFi（如WiFi 6）。

6.2 追求极致的低延迟

对于机器人遥控、VR等场景，延迟需要压到100ms以内。

1. 减少缓冲环节：环形缓冲区大小减到最小（如2-3帧），甚至考虑无锁环形队列（如使用原子操作的RingBuffer）来减少线程同步开销。
2. 编码延迟：使用低延迟编码参数。例如，x264的--tune zerolatency选项，关闭B帧，使用很小的GOP。
3. 网络协议微调：设置Socket为TCP_NODELAY（如果用了TCP）、调整UDP发送缓冲区至合适大小，避免 Nagle算法或缓冲区堆积引入延迟。
4. 硬件与驱动：选择低延迟的摄像头模组，研究驱动是否有可能关闭某些耗时的后处理（如3A算法、降噪）。有时，直接使用libcamera这样的新框架比传统的V4L2能获得更好的延迟表现。

6.3 融合AI分析

这是当前的热点。你可以在采集线程之后、放入环形缓冲区之前，插入一个AI推理线程（或使用硬件AI加速器如RK3588的NPU）。

• 流水线设计：采集 -> AI预处理/推理 -> 编码 -> 发送。AI结果可以作为元数据随视频帧一起发送，或者在设备端直接触发动作。
• 资源竞争：AI推理通常比较耗资源，需要仔细设计线程模型，避免与编码、发送线程争抢CPU/内存带宽，必要时引入额外的缓冲队列。

7. 避坑指南：常见问题与解决方案

1. VIDIOC_DQBUF 阻塞或返回EAGAIN：
   • 阻塞：正常，说明驱动缓冲区队列为空，等待下一帧。确保流已启动(STREAMON)且缓冲区已入队(QBUF)。
   • EAGAIN：通常因为设置了非阻塞模式(O_NONBLOCK)且没有数据可读。检查缓冲区管理逻辑。
2. 画面花屏、错位：
   • 最常见原因是分辨率或像素格式不匹配。确保接收端解码时使用的格式与发送端V4L2_S_FMT设置的完全一致。用v4l2-ctl --get-fmt-video确认。
   • 分包重组逻辑错误，导致包顺序错乱。检查part_seq的处理。
3. 延迟巨大且不断增长：
   • 环形缓冲区堆积：发送速度远慢于采集速度。检查网络带宽、接收端处理速度。启用“快放丢旧”策略。
   • 编码速度跟不上：如果是软件编码，查看CPU占用。考虑降低分辨率、帧率或启用硬件编码。
4. WiFi下频繁丢包：
   • 检查WiFi信号强度(iwconfig)。
   • 尝试更换WiFi信道，避开干扰。
   • 降低视频码率。
   • 在应用层实现简单的重传或FEC。
5. 内存泄漏：
   • 确保mmap的内存最终被munmap。
   • 确保malloc/calloc的内存被free。
   • 使用valgrind工具进行检测。

最后，我想说，构建这样一个系统就像搭积木，理解每个模块（V4L2、多线程、Socket、缓冲区）的原理是关键。不要害怕修改和调试，很多最优参数（如缓冲区大小、UDP发送间隔）都需要在你的具体硬件和网络环境下实测才能确定。从最简单的YUV传输开始，逐步增加编码、多路、AI等功能，每一步都做好测试和性能评估，你就能搭建出稳定可靠的嵌入式视频传输系统。