3. 采集端瓶颈：摄像头帧率不足、分辨率过高、采集设备驱动问题

推流卡顿，很多时候不是网络不行，也不是编码器太弱。问题出在源头——采集端。

你想想看，如果摄像头本身就在“偷懒”，或者它给出来的数据格式不对，那后面再怎么优化也是白搭。我这些年排查过不少推流事故，至少有三成的问题，根子就在采集这一环。

3.1 摄像头帧率不足：源头就“饿”了

帧率不足，说白了就是摄像头每秒产生的画面数量，跟不上你设定的推流帧率。

比如你推流设置的是 30fps，但摄像头实际只能输出 15fps。那剩下的 15 帧怎么办？FFmpeg 会尝试重复上一帧来“凑数”。结果就是画面看起来一卡一卡的，动作不连贯。

核心判断标准：

推流日志中频繁出现 dup（重复帧）或 drop（丢帧）
实际输出帧率远低于设定的 -r 参数
画面有明显的“幻灯片”感，尤其是快速移动的场景

为什么会这样？我遇到过几种情况：

摄像头硬件限制：很多 USB 摄像头标称 30fps，但那是在特定分辨率下的。你一旦把分辨率拉高，帧率就自动掉下来了。
USB 带宽不足：USB 2.0 的理论带宽只有 480Mbps，实际可用也就 200-300Mbps。如果同时挂载了多个摄像头，或者接了其他高速设备，带宽抢不过，帧率自然就降了。
自动曝光/白平衡拖累：有些摄像头在光线变化时，自动调节算法会占用大量处理时间，导致帧率瞬间暴跌。

我的排查习惯：

先用 ffprobe 或者 v4l2-ctl 看看设备实际支持的帧率列表。别信包装盒上的参数。

# 查看 V4L2 设备支持的帧率
v4l2-ctl --list-formats-ext

# 或者用 ffprobe 直接看
ffprobe -f v4l2 -list_formats all -i /dev/video0

3.2 分辨率过高：采集端的“内耗”

分辨率越高，单帧数据量越大。这不仅仅是编码压力，采集端本身也会扛不住。

我见过有人用 4K 摄像头做直播，结果推流端卡成 PPT。他以为是编码器不行，换了个顶级显卡还是卡。最后发现，是摄像头在 4K 模式下，内部 ISP（图像信号处理器）处理不过来，实际输出帧率只有 10fps 左右。

分辨率	单帧数据量（YUV420P）	USB 2.0 理论最大帧率	常见瓶颈
1920x1080	约 3 MB	约 30fps	USB 带宽、编码器
3840x2160	约 12 MB	约 8fps	USB 带宽、ISP、内存带宽
640x480	约 0.5 MB	约 60fps+	几乎无瓶颈

你看这个表就明白了。4K 分辨率下，USB 2.0 连传输都费劲，更别提处理了。我个人建议，除非你有专门的采集卡或者高速接口（比如 USB 3.0 / Thunderbolt），否则直播推流别轻易上 4K。

避坑指南：

我曾经踩过一个坑：用 FFmpeg 采集 4K 摄像头，然后通过 -vf scale=1920:1080 在软件层面缩放。结果采集端还是以 4K 分辨率在跑，内存带宽和 CPU 全部被吃满。正确的做法是：

如果摄像头支持硬件缩放，直接在驱动层面设置输出分辨率
或者用 -video_size 1920x1080 参数让摄像头直接输出 1080p

# 错误示范：采集 4K 再软件缩放
ffmpeg -f v4l2 -i /dev/video0 -vf scale=1920:1080 ...

# 正确做法：直接让摄像头输出 1080p
ffmpeg -f v4l2 -video_size 1920x1080 -i /dev/video0 ...

3.3 采集设备驱动问题：看不见的“暗病”

驱动问题是最隐蔽的。它不会直接报错，但会让你的推流变得不稳定。

我遇到过几次典型的驱动问题：

帧格式不匹配：摄像头输出的是 MJPEG，但 FFmpeg 默认用 YUYV 去读。结果驱动在底层做格式转换，CPU 占用飙升，帧率下降。
缓存队列溢出：驱动内部的 buffer 太小，或者 FFmpeg 读取不及时，导致驱动丢帧。日志里会看到 buffer overrun 或者 frame dropped。
UVC 协议兼容性：有些杂牌摄像头对 UVC（USB Video Class）协议实现不完整。在 Windows 上能用，到了 Linux 上就各种怪问题。

驱动层面的排查命令：

# 查看 V4L2 设备详细信息
v4l2-ctl --all

# 查看驱动丢帧统计
cat /sys/class/video4linux/video0/device/driver/...  # 具体路径因驱动而异

# 查看 USB 传输错误
cat /sys/kernel/debug/usb/.../errors

嗯，这里要注意一点。很多人在排查卡顿时，第一反应是看编码参数、看网络带宽。但我会先看一眼采集端的日志。如果发现 fps 忽高忽低，或者 pts 时间戳跳跃很大，那八成是采集端有问题。

3.4 采集端瓶颈的完整排查流程

我总结了一套排查流程，你可以照着做：

先确认设备能力：用 v4l2-ctl --list-formats-ext 查看所有支持的分辨率和帧率组合。
裸采测试：不加编码、不加网络，直接采集到本地文件，看帧率是否稳定。
检查 USB 拓扑：用 lsusb -t 查看摄像头挂载在哪个 USB 控制器下，确认没有和其他设备共享带宽。
尝试不同像素格式：如果默认是 YUYV，试试 MJPEG 或者 H264（如果摄像头支持硬件编码）。
查看内核日志：dmesg | grep -i video 或者 dmesg | grep -i usb，看有没有驱动报错。

一个小技巧：

如果你用的是 USB 摄像头，尽量插在主板原生的 USB 3.0 接口上，别用机箱前置面板。前置面板的供电和信号质量往往不如主板直出。我遇到过好几次，插前置面板就掉帧，换到后面就正常了。

3.5 采集端瓶颈与推流卡顿的关系图

下面这张图，是我梳理的采集端瓶颈如何传导到推流卡顿的路径。你可以对照着看，你的问题出在哪一环。

从这张图可以看得很清楚：摄像头硬件的问题，会通过驱动层和接口层，一级一级传导到 FFmpeg 采集、编码，最终表现为推流卡顿。所以排查的时候，一定要从源头开始查，别一上来就调编码参数。

3.6 总结一下

采集端瓶颈，说白了就是“源头没水”。你后面管道再粗、水泵再强，也没用。

帧率不足：查硬件能力、查 USB 带宽、查自动调节算法
分辨率过高：别盲目上 4K，考虑硬件缩放而非软件缩放
驱动问题：查像素格式、查缓存队列、查 UVC 兼容性

我个人习惯，每次搭建新的推流环境，第一件事就是做裸采测试。不加任何编码和网络，直接采集 30 秒本地文件，然后看帧率曲线。如果这一步都不稳，后面就不用折腾了。