UVC 摄像头等时传输调试：带宽、Alternate Setting 与丢帧排查
系统讲解 USB UVC 摄像头无法出图、丢帧、降分辨率等问题的抓包分析方法，从描述符、Alternate Setting 切换、等时传输行为三个层面定位根因。
UVC（USB Video Class）设备几乎无处不在——网络摄像头、工业相机、显微镜摄像头、嵌入式视觉模组、自动化测试夹具。UVC 摄像头出问题的时候，用户看到的现象往往很直接：黑屏、帧率上不去、丢帧，或者某个分辨率能开、另一个分辨率就罢工。
但 USB 层面的真相远没有这么简单。UVC 摄像头的工作链路涉及描述符、类特定协商、Alternate Interface Setting（备用接口设置）、端点带宽分配、等时传输行为等多个环节。光看一个"摄像头没图像"的工单，根本得不到足够的信息。
UVC 的难点不止枚举
UVC 设备能正常枚举，不代表它能正常出图。枚举成功只说明主机读到了描述符、选好了配置。要真正开始视频流，还需要一连串额外的协商和端点交互。
抓包时重点看这些项：
- Video Control 接口
- Video Streaming 接口
- Format 描述符
- Frame 描述符
- 帧间隔选项
- Probe / Commit 控制请求
- 实际选中的 Alternate Setting
- 等时端点描述符
- 包大小与传输状态
同样一颗摄像头，640x480 正常、1080p 异常——把描述符和带宽证据摆出来，往往就能看出原因。
Alternate Setting 是关键
很多 UVC 设备会通过不同的 Alternate Interface Setting 暴露不同的带宽等级。主机在开始流传输之前会先选定一个 Alternate Setting。如果选中的设置和协商好的格式、带宽对不上，流就可能起不来，或者开着开着丢帧。
抓包时需要回答这些：
- 实际选中的是哪个 Alternate Setting？
- 端点声明的最大包大小是多少？
- Commit 之后用的格式和帧间隔是什么？
- 等时传输到底有没有开始？
- 错误是立刻出现，还是跑了一会儿才出现？
- 主机有没有回退到更低的 Alternate Setting？
在动手改 Frame 描述符或端点配置之前，这些证据必须先拿到。
等时传输以"准点"为先
等时传输是为时敏数据设计的。它会预留带宽，但不会像 Bulk 传输那样自动重传。这对视频来说是对的，但代价是：丢包不会重发，而是直接体现为画面异常、花屏或局部图像缺失。
常见原因有：
- 总线带宽不够
- Hub 拓扑有问题
- 其他 USB 设备挤占带宽
- Alternate Setting 选错
- 固件缓冲区欠载
- 主控制器能力上限
- 线材或信号质量差
好的抓包应该能告诉你：包到底有没有被调度出去？数据有没有按时到达？状态阶段有没有出错？
别只看应用层就下结论
摄像头应用程序往往会"帮"用户把 USB 协商的过程藏起来。它可能悄悄切到更低的分辨率、回退到 MJPEG、重试帧间隔、把传输错误吞掉。对固件工程师和设备厂商来说，这种程度的反馈远远不够。
一份合格的 UVC 抓包应该记录：
- 请求的格式
- 请求的帧大小
- 请求的帧间隔
- Probe / Commit 的结果
- 实际选中的 Alternate Setting
- 传输状态
- 实际观测到的 payload 流量
有了这些，才能解释清楚：为什么同一个摄像头，在 A 主机上没问题，在 B 主机上就翻车；为什么 720p 没事，1080p 就异常。
Bus Scope 在这个场景里做什么
Bus Scope 是一款为 USB 取证而生的工具。面对 UVC 案例，它的价值在于把"描述符 — 控制请求 — 端点选择 — 传输时序"这几件事串成一条线。它不需要把图像渲染出来才有意义——我们要回答的不是"图长什么样"，而是"总线在干嘛"。
如果你搜的是 "UVC 摄像头没图像"、"USB 摄像头等时传输失败"、"网络摄像头 USB 抓包丢帧" 这一类问题，正确的切入点应该是：描述符、Alternate Setting、带宽、传输状态。