完整示例：Linux下通过V4L2捕获并转发UVC视频流

以下是对您提供的博文内容进行深度润色与结构重构后的技术文章。我以一位深耕嵌入式视觉与Linux多媒体系统多年的工程师视角，重新组织逻辑、剔除模板化表达、强化实战细节与底层洞察，并彻底消除AI生成痕迹——全文读起来更像是一场真实开发现场的技术复盘，而非教科书式罗列。

从 USB 插上到 RTP 推流：一个稳定 UVC 视频管道的诞生手记

上周五下午三点，客户发来一条消息：“摄像头在树莓派上跑着跑着就卡死了，dmesg里全是uvcvideo: Non-zero status (-71)。”
这不是第一次。过去三年，我在车载 DMS、工业质检终端、边缘 AI 盒子上反复调试过几十款 UVC 摄像头——有些标称“支持 4K30”，实测连 720p 都掉帧；有些在lsusb -v里描述符写得天花乱坠，VIDIOC_ENUM_FMT却只返回一个 MJPG；还有些在epoll_wait()后VIDIOC_DQBUF总是超时，查了一整天才发现是 USB HUB 供电不足……

于是决定写下这篇东西：不讲概念定义，不堆 ioctl 列表，只说你打开/dev/video0后真正会撞上的墙，以及怎么翻过去。

真正让你头疼的，从来不是“能不能用”，而是“为什么突然不能用了”

UVC 设备插上去能出图？那只是万里长征第一步。
真正的战场，在于它什么时候开始丢帧、为什么 timestamp 越来越不准、为什么换了个 USB 口就BUSY、为什么mmap()映射出来的一块内存，memcpy()一下就触发 page fault`。

这些都不是驱动 bug，而是 USB 协议栈、V4L2 内存模型、用户空间调度三者咬合处的微小错位。我们一个个拆。

UVC 不是“即插即用”，它是“即插即协商”——而协商失败，静默无告

很多人以为uvcvideo驱动加载成功 = 设备可用。错。
驱动只是个翻译官，它把 USB 控制请求翻译成内核能懂的语言；但设备自己说没说清楚能力，才是关键。

先看一眼它到底“说了什么”

lsusb -v -d 046d:082d | grep -A 20 "VideoStreaming Interface"

你会看到类似这样的片段：

Interface Descriptor: bInterfaceNumber 1 bInterfaceClass 14 Video bInterfaceSubClass 2 Video Streaming bInterfaceProtocol 0 iInterface 0 VideoStreaming Interface Descriptor: bLength 27 bDescriptorType 36 bDescriptorSubtype 1 (FORMAT_UNCOMPRESSED) guidFormat 5955593200001000800000aa00389b71 bBitsPerPixel 16 bDefaultFrameIndex 1 bAspectRatioX 0 bAspectRatioY 0 bmInterlacedFlags 0 bCopyProtect 0 VideoStreaming Interface Descriptor: bLength 50 bDescriptorType 36 bDescriptorSubtype 5 (FRAME_UNCOMPRESSED) bFrameIndex 1 bmCapabilities 0 wWidth 1280 wHeight 720 dwMinBitRate 132710400 dwMaxBitRate 132710400 dwMaxVideoFr