【USB 传视音频的那些事02】USB 摄像头里跑的，到底是什么画面？

一个反直觉的问题

接着上一篇的话题——【USB 传视音频的那些事01】为什么你的 USB 摄像头不用装驱动？

你打开会议软件，画面出现了。但如果我们停下来问一个问题：这一帧 1920×1080 的画面，从摄像头送到电脑里的时候，到底是什么样的数据？

你的第一直觉可能是：”不就是一张图片嘛。”

但事情没这么简单。一张 1080p、30帧的视频画面，如果用最朴素的方式表达（每个像素 24 位 RGB 颜色），它的数据量是:

1920 × 1080 × 24 bit × 30 帧 ≈ 1.49 Gbps

而一根普通的 USB 2.0 线，理论带宽是 480 Mbps——也就是 0.48 Gbps。

数学上看，1080p 30 帧的原始画面，根本就塞不进 USB 2.0。

可现实里，2010 年代的 USB 2.0 摄像头明明可以跑 1080p——这怎么做到的？

这就是这一篇要讲的内容：USB 摄像头里跑的画面，到底是什么格式；它和 USB 带宽之间在玩什么样的”博弈”；以及当一台 UVC 摄像头插上电脑时，它们之间到底”商量”了什么。

USB 带宽：一切的源头约束

要理解 USB 视频，得先建立一个底层认知——USB 不是无限管道。每一代 USB 标准都有自己的带宽上限，而这个上限直接决定了一台摄像头能传什么样的画面。

USB 标准演进至今的几个关键版本：

关于”实际可用带宽”的解释——USB 是一个分时复用的总线，协议本身要占用一部分带宽来做握手、纠错、设备识别等管理工作。所以实际可用带宽通常是理论值的 65%~75%。这是一个很重要的细节——很多人按理论带宽算视频码率，最后发现”为什么传不动”，就是漏算了这部分协议开销。

现在我们回到刚才那个 1080p 原始数据 1.49 Gbps 的算式——

• USB 2.0 的实际可用带宽约 320 Mbps，塞不下。差了将近 5 倍。
• USB 3.0 的实际可用带宽约 3.2 Gbps，塞得下，但已经吃掉一大半。
• 4K 60fps 的原始数据约 12 Gbps——连 USB 3.0 都塞不下，需要 USB 3.2 Gen 2 以上。

这就是为什么 USB 摄像头几乎不传原始画面。要在有限的 USB 带宽里塞下”看起来够清楚”的画面，必须做一件事：压缩。

而 UVC 标准在设计的时候，已经预见到了这件事——它支持多种视频格式，从完全不压缩的原始数据，到深度压缩的视频流，覆盖了不同的带宽-质量取舍。

UVC 支持的视频格式：从原始到压缩的光谱

UVC 标准定义了若干种视频格式（在 UVC 术语里叫做”Payload Format”）。我们挑最常见的几种来讲：

RGB / YUV：未经压缩，纯净但巨大

RGB（红绿蓝三色直接编码）和 YUV（亮度 + 色度分量编码，YUV422 / YUV420 等子格式）是未经压缩的原始像素格式。

它们的优点很直接——画面没有任何信息损失，PC 拿到数据可以直接显示，CPU 几乎不用做解码。

但缺点更直接——数据量巨大。前面算过，1080p 30 帧的 RGB 数据就是 1.49 Gbps；YUV422（每像素 16 位）会少一点，但仍然在 1 Gbps 量级。

这就导致 RGB / YUV 在 USB 摄像头里只能用于低分辨率或低帧率场景：

• USB 2.0 摄像头跑 YUV，通常上限是 640×480 30 帧或 1280×720 15 帧
• USB 3.0 摄像头跑 YUV，可以做到 1080p 30 帧，但已经接近天花板
• 4K YUV？需要 USB 3.2 Gen 2 以上，并且基本是工业相机的专属配置

绝大多数面向消费市场的 USB 摄像头，不会用 RGB / YUV 来跑高分辨率。

MJPEG：当下 USB 高分辨率视频的实际主力

MJPEG（Motion JPEG）的工作方式可以一句话讲清楚——把每一帧画面都单独压缩成一张 JPEG 图片，然后一帧接一帧地传。

它的特点是：

• 压缩率显著——通常能把数据量压到原始的 1/10 到 1/20。1080p 30 帧 MJPEG 的码率，典型在 30~50 Mbps，USB 2.0 都跑得动。
• 每一帧独立——没有帧间预测、没有 B 帧 P 帧的概念，每帧都是完整的。
• 解码极其简单——JPEG 是一项三十年的成熟技术，所有操作系统、所有平台都有硬件级或汇编级优化的解码器。CPU 占用几乎可以忽略。
• 延迟极低——每帧独立编码、独立传输、独立解码。从相机捕获到屏幕显示之间的延迟，理论上只有一帧的时间（30fps 下约 33ms）。

但 MJPEG 的代价是：压缩效率不如更现代的视频编码。同样的码率下，MJPEG 的画质比 H.264 差一档；要达到同样的画质，MJPEG 需要的码率高得多。

不过对于 USB 摄像头的场景，这恰恰是优势——

USB 给的带宽是充足的（USB 3.0 有 3.2 Gbps 可用）。CPU 时间反而是稀缺的（会议软件本身已经在吃 CPU）。

所以”用更多带宽换取更少 CPU 占用”是一个完全正确的取舍。这就是为什么今天市面上几乎所有支持 1080p 以上的 USB 摄像头，主流格式都是 MJPEG——它在 USB 这个场景下，是带宽、画质、CPU、延迟之间的最优平衡点。

特别要提一下 4K——几乎所有声称支持 4K 的 USB 摄像头，传输的都是 MJPEG。原因前面也讲了：4K YUV 太大、4K H.264 对 CPU 太狠（下面会说），只有 MJPEG 能在合理的 CPU 开销下，把 4K 画面送进电脑。

H.264 / H.265：理论上很美，现实里很尴尬

H.264 是过去二十年最成功的视频编码格式——你今天看的视频、刷的短视频、做的视频会议，背后绝大多数都跑在 H.264 上。

UVC 1.5（2012 年发布）正式把 H.264 纳入了支持范围。从理论上看，H.264 应该是 USB 摄像头的”最优解”——它的压缩效率比 MJPEG 高 5~10 倍。同样画质下，H.264 只需要 MJPEG 五分之一到十分之一的带宽。

但在实践中，H.264 在 USB 摄像头里反而不是主流。原因有几个：

• 第一，CPU 解码开销大。H.264 的解码比 JPEG 复杂得多——它有帧间预测、运动补偿、熵编码、去块滤波等等。会议软件本身已经在大量占用 CPU（图像缩放、降噪、回声消除、网络编码再发出去），如果输入的视频还得花 CPU 解 H.264，整体性能会很紧张。虽然现代电脑有硬件 H.264 解码器，但会议软件是否会调用硬件解码、调用得是否高效，是不可控的——尤其是在 Windows 平台上，不同会议软件对硬件解码的支持千差万别。
• 第二，延迟问题。H.264 为了提高压缩率，会使用 B 帧（双向预测帧）——它需要等待后一帧才能解码当前帧。这对视频会议这种实时场景非常致命。虽然可以配置 H.264 跑”低延迟模式”（只用 I 帧 + P 帧，关闭 B 帧），但这又会牺牲一部分压缩率。
• 第三，画质 vs 码率的甜区不同。H.264 真正”碾压” MJPEG 是在低码率场景（比如 1080p 跑 2 Mbps）。但在 USB 摄像头场景下，带宽根本不是瓶颈——既然带宽充裕，”用 30 Mbps 跑 MJPEG”和”用 5 Mbps 跑 H.264″对最终画质几乎没区别，前者反而更省 CPU、延迟更低。
• 第四，操作系统侧的支持深度。Windows 的 DirectShow / Media Foundation 对 UVC H.264 的支持，远不如对 MJPEG 那么”开箱即用”。一些会议软件在拿到 H.264 UVC 设备时，会出现兼容性问题。

所以现实是——UVC 1.5 虽然支持 H.264，但市面上真正用 H.264 输出的 USB 摄像头很少。MJPEG 仍然是事实主流。

未来呢？ UVC 1.5 之后没有新的主版本发布。但行业内有几个方向在演进：AV1（更高效的开源视频编码）、HEVC / H.265（H.264 的下一代），它们在未来某个时候可能进入 UVC 规范。但目前来看，MJPEG 仍然会是 USB 摄像头未来若干年里的实际主力——因为它的”简单”在 USB 这个场景里就是优势。

设备和电脑之间的”对话”：UVC 协商机制

最后讲一件很多人没注意过、但其实非常关键的事——当一个 UVC 摄像头插上电脑的瞬间，它们之间到底在”商量”什么？

这个过程在 UVC 标准里叫做 Probe and Commit（探测和确认）。它的工作流程大致是：

第一步：枚举（Enumeration）

电脑通过 USB 标准的”设备描述符”问设备：”你是谁？”设备回应：”我是 UVC 类设备（Class Code 0x0E），版本 1.5。”电脑接着读设备的”视频流接口描述符”，得到这台摄像头支持的所有视频格式、分辨率、帧率组合的完整列表。比如：

• MJPEG · 3840×2160 · 30fps
• MJPEG · 1920×1080 · 60fps
• YUV422 · 1280×720 · 30fps
• ……

这个列表就是这台摄像头的”能力清单”。

第二步：Probe（探测）

会议软件（比如 Zoom）告诉操作系统：”给我 1920×1080 30 帧的 MJPEG 数据流。”操作系统把这个请求转换成 UVC 的 Probe 命令发给摄像头。摄像头回应：”这个组合我能做，确认。” 或者：”这个组合我做不了，我能给的最接近选项是 XXXX。”

这是一个协商过程——双方可以来回几次，直到敲定一个都接受的参数。

第三步：Commit（确认）

参数敲定后，电脑发出 Commit 命令——”我们就按这个配置来。”摄像头开始按这个配置准备数据流。

第四步：开始传输

电脑发出 SET_INTERFACE 命令激活视频流。摄像头开始把视频帧通过 USB Isochronous 传输模式送到电脑。

这里再插一句技术细节——USB 有四种传输模式：Control（控制）、Bulk（批量）、Interrupt（中断）、Isochronous（同步）。

视频流使用的是 Isochronous 模式——它保留固定的带宽时隙、不保证数据 100% 到达（丢包就丢了）、但保证时间上的连续性。这非常适合视频和音频这种”丢一两帧无所谓，但绝对不能卡顿”的实时数据。

整个 Probe-Commit 过程通常在几十毫秒内完成。所以你”插上摄像头，点开 Zoom，画面就出来”的这几秒钟，其实背后发生了非常复杂的一系列握手。而这一切都不需要你装任何驱动、不需要你做任何配置——这就是 UVC 标准的力量。

UAC：音频走着相似但更简单的路

音频的传输逻辑和视频几乎完全对称，但简单很多——因为音频的数据量小得多。

未压缩的 CD 音质音频（44.1kHz / 16bit / 立体声）只需要约 1.4 Mbps。即便是专业级的 24bit / 192kHz 立体声，也只需要约 9 Mbps。这点带宽在任何一代 USB 上都是九牛一毛——所以 UAC 几乎都跑未压缩的 PCM 原始音频，根本不需要复杂的压缩格式。

UAC 设备的协商过程和 UVC 几乎一样——枚举、读取支持的采样率/位深/声道数列表、确认配置、开始用 Isochronous 模式传输。

这也是为什么 USB 麦克风、USB 音频接口的兼容性比 USB 摄像头还要好——格式简单、带宽充裕、协议成熟，几乎不存在”协商不上”的情况。

我们站在多少层”看不见的工程”之上

回头看这一篇讲的所有内容——

带宽、压缩格式、编码取舍、协商机制——每一个细节背后，都是一群工程师在某个会议室里讨论了几年、几十年的产物。

当你今天点开 Zoom，画面”咔哒”一声出来，背后发生的是：

• 摄像头里的 ISP 把传感器原始信号转成 YUV
• 摄像头里的编码芯片把 YUV 压成 MJPEG
• USB 控制器把 MJPEG 数据按 UVC 标准打包成 Isochronous 数据包
• USB 物理层把数据包通过那根 USB-C 线传到电脑
• 电脑的 USB 控制器接收数据，操作系统按 UVC 标准解析
• 操作系统把每一帧 JPEG 解码成 YUV
• 会议软件拿到 YUV，再做色彩处理、缩放、编码成 H.264 发到网络

这一切，在你按下”加入会议”按钮后的 200 毫秒内完成。

USB 视音频这件事，从插上线到画面出现，背后是带宽工程、编码理论、协议标准、操作系统集成多个层面的工程文明合力。我们享受的每一次”插上即用”，都是站在这些看不见的工程之上的。

下一篇，我们要从”采集”换到”输出”——

电脑要把画面送出去给一块外接显示器或投影仪，USB 又是怎么干的？为什么今天的 USB-C 显示器、USB-C 拓展坞能直接出画面？DP Alt Mode 是什么？还有那个叫 DisplayLink 的”非主流方案”，它又是怎么回事？

USB 传视音频的故事，”采”已经讲完，下一篇讲”放”。