一、场景：带宽预算为什么总要重算一遍
产线上常见这样一类现象：触发正常、曝光正常，图像却偶发丢帧或出现绿色横带，把帧率砍掉一半就一切正常。这类问题的根子往往不在相机也不在软件，而在采集链路一开始就没有做带宽预算——分辨率、像素格式、帧率三个量各自变一点，每秒需要搬运的字节数就会差出两三倍。
预算本身只有三步：单帧多少字节 → 每秒需要多少兆字节 → 接口实际能提供多少兆字节。下面按这三步给出可对照的速查表，再给两个完整算例，最后列出四条最容易算错的地方。文中所有速查值都是工程估算，用于快速判断「够不够」和「差多少」，最终结论仍以现场抓包与丢帧统计为准。
二、第一步：单帧数据量 = 宽 × 高 × 每像素字节数
最容易出错的一步是「每像素字节数」。相机参数表里写的是位深（8 bit、10 bit、12 bit），而链路上占用的是字节数，两者并不总是 1:1 对应：12 bit 若放在 16 bit 容器里传输，一个像素就要占 2 字节；只有厂商明确标为 packed（打包）时，才按 1.5 字节计。下表按 GenICam 像素格式命名约定（PFNC）的常见格式整理。
| 像素格式 | 每像素字节数 | 说明 |
|---|---|---|
| Mono8、BayerRG8/BG8/GB8/GR8 | 1 | 8 位单通道或 8 位 Bayer，一个像素一个字节 |
| Mono10、Mono12（未打包，16 位容器） | 2 | 有效位放在 16 位字里，传输仍占满 2 字节 |
| Mono10 Packed、Mono12 Packed | 1.5 | 按 2 像素/3 字节打包（10 位值同样装入 24 位组），平均 1.5 B/px |
| YUV422_8、YCbCr422_8 | 2 | 两个像素合计 4 字节（Y0/U/Y1/V），平均 2 B/px |
| RGB8、BGR8 | 3 | 三通道各 1 字节 |
| RGB10、RGB12（未打包） | 6 | 三通道各占 16 位 |
| Bayer 双通道（BiColor 等厂商自定义格式） | 2 | 两路 Bayer 交织，等效每像素 2 字节；命名与打包方式随厂商不同，需按具体格式核对 |
把常见分辨率代入，得到下表的单帧数据量（十进制 MB，1 MB = 106 字节）。表中的数值是「像素数 × 每像素字节数」的裸值，实际传输还会因行对齐、报文头而略大。
| 分辨率 | 像素数 | 1 B/px | 1.5 B/px | 2 B/px | 3 B/px |
|---|---|---|---|---|---|
| 640×480（0.3 MP） | 0.31 M | 0.31 MB | 0.46 MB | 0.61 MB | 0.92 MB |
| 1280×1024（1.3 MP） | 1.31 M | 1.31 MB | 1.97 MB | 2.62 MB | 3.93 MB |
| 1920×1080（2.1 MP） | 2.07 M | 2.07 MB | 3.11 MB | 4.15 MB | 6.22 MB |
| 2048×2048（4.2 MP） | 4.19 M | 4.19 MB | 6.29 MB | 8.39 MB | 12.58 MB |
| 2448×2048（5.0 MP） | 5.01 M | 5.01 MB | 7.52 MB | 10.03 MB | 15.04 MB |
| 2592×1944（5.0 MP） | 5.04 M | 5.04 MB | 7.56 MB | 10.08 MB | 15.12 MB |
| 4096×3000（12.3 MP） | 12.29 M | 12.29 MB | 18.43 MB | 24.58 MB | 36.86 MB |
| 5120×5120（26.2 MP） | 26.21 M | 26.21 MB | 39.32 MB | 52.43 MB | 78.64 MB |
使用 ROI 时只按实际开窗的行列数计算，不要按传感器满幅算；做 binning 时行列各减半，在输出像素格式与位深不变的前提下，单帧字节数按四分之一计（若 binning 后位深或像素格式变了，要按新的每像素字节数重算）。这两条能把大分辨率相机的带宽需求压下来一大截，比换接口便宜得多。
三、第二步：每秒速率 = 单帧 × 帧率，余量怎么算
把单帧字节数乘以帧率，就得到连续采集的平均数据率。这个平均数据率要和接口的「工程可用值」比较，而不是和线速比较。余量系数（一般 1.05–1.15）只在两种场合用：一是自己从线速推算可用带宽、没有现成经验值时，用它扣掉控制通道与突发开销；二是做接线容量核算、需要给未来留空间时。第四节表里的「工程可用值」已经是从标称速率扣掉开销、又留了运行余量之后的保守值，用它与原始数据率直接比较即可，不要再乘一次余量，否则会把同一份余量算两遍、把可行方案判成不可行。
需要区分的是：触发方式和曝光时间不改变单帧字节数，它们只改变帧与帧之间的间隔；真正影响带宽的是分辨率、像素格式和帧率三个量。反过来，缩短曝光可以把帧率做上去，但带宽需求随之线性上升。多相机共用一个上行端口时，持续带宽按各相机平均数据率之和核算，同时用最坏时刻（多台同时触发）的瞬时叠加去校核缓冲是否够，两者缺一不可。
四、第三步：接口实际能提供多少
接口的「名义速率」和「可用载荷」之间隔着编码开销与协议开销，这两层必须分开算。以太网还要再扣掉报文头与帧间间隔：以 1500 字节 MTU 传输时，一个以太网帧在线路上占 1538 字节（含前导码、帧头、FCS 与 96 bit 时间即 12 字节的帧间间隔），其中的 IPv4/UDP 数据部分占线路上字节的 95.7%；改用 9000 字节的巨型帧后可提到约 99.3%。若只按「帧内 1500 字节」这一口径算，同一组数字分别是 97.5% 与 99.6%——两个口径都常见，关键是先说明扣到哪一层。这就是同样一条千兆链路，为什么有人算出 125 MB/s、有人只敢按 100 MB/s 用的原因。
| 接口 | 线速 | 编码 / 开销 | 理论载荷 | 工程可用值 |
|---|---|---|---|---|
| GigE Vision（1000BASE-T） | 1 Gbit/s | 以太网帧开销 | 119.6 MB/s（1500 B MTU） 124.1 MB/s（9000 B MTU） | 100–115 MB/s |
| 2.5GBASE-T（IEEE 802.3bz） | 2.5 Gbit/s（MAC 标称） | PHY 层开销已含在标称速率内 | 299–310 MB/s | 250–280 MB/s |
| 5GBASE-T（IEEE 802.3bz） | 5 Gbit/s（MAC 标称） | 同上 | 598–620 MB/s | 520–560 MB/s |
| USB 3.0（USB3 Vision 常用档） | 5 Gbit/s | 8b/10b | 500 MB/s（未含 USB 协议包开销） | 约 400 MB/s |
| USB 3.1 Gen 2 / USB 3.2 Gen 2 | 10 Gbit/s | 128b/132b | 1212 MB/s（未含 USB 协议包开销） | 约 900 MB/s |
| Camera Link Base | 24 bit × 85 MHz | 裸 LVDS，随数据发时钟 | 2.04 Gbit/s＝255 MB/s 像素载荷 | 255 MB/s |
| Camera Link Medium / Full / Deca | 48 / 64 / 80 bit × 85 MHz | 同上 | 510 / 680 / 850 MB/s | 510 / 680 / 850 MB/s |
| CoaXPress CXP-3 / CXP-6 / CXP-12 | 3.125 / 6.25 / 12.5 Gbit/s（每通道） | 8b/10b | 312 / 625 / 1250 MB/s（每通道） | 按通道数相加 |
| PCIe Gen 2 ×1 | 5 GT/s ×1 | 8b/10b | 500 MB/s | 约 400 MB/s |
| PCIe Gen 3 ×4 | 8 GT/s ×4 | 128b/130b | 3938 MB/s | 约 3.5 GB/s |
表中「工程可用值」是长期稳定运行的保守取值，已经把 GVCP、重传、其他业务流量与突发缓冲留进去；「理论载荷」列是按标称速率与编码效率推算的上限，只扣了以太网/IP/UDP 与编码开销，没有扣 GVSP、CXP 等应用层包头，两者不要混用。Camera Link 与 CoaXPress 属于点对点专线，不受以太网报文开销影响：Camera Link 的 24 bit × 85 MHz 本身就是像素载荷速率，四条 LVDS 串行链路还要另带时钟与同步位，原始串行速率略高于这个数；CoaXPress 采用 8b/10b，每通道载荷要先打八折再除以 8，四通道 CXP-6 合计约 2.5 GB/s，八通道则可到约 5 GB/s。
五、速查：Mono8 下各接口能跑多快
把上两张表拼起来，直接查「某分辨率在某接口上最高多少帧」。下表按单色 8 位计算，单位 fps；彩色（RGB8）把结果除以 3，YUV422_8 或 12 位未打包格式除以 2。口径说明：GigE、2.5G、5G、USB 三列用的是工程可用值，Camera Link 与 CoaXPress 两列用的是专线的像素载荷速率；表中数值是「裸上限」，未再乘余量，结果四舍五入，低于 10 的保留一位小数。
| 分辨率（Mono8） | GigE 110 MB/s | 2.5G 275 | 5G 550 | USB 3.0 400 | USB 3.2 Gen 2 900 | CL Base 255 | CXP-6 单通道 625 |
|---|---|---|---|---|---|---|---|
| 1920×1080（2.1 MP） | 53 | 133 | 265 | 193 | 434 | 123 | 301 |
| 2048×2048（4.2 MP） | 26 | 66 | 131 | 95 | 215 | 61 | 149 |
| 2448×2048（5.0 MP） | 22 | 55 | 110 | 80 | 180 | 51 | 125 |
| 4096×3000（12.3 MP） | 9 | 22 | 45 | 33 | 73 | 21 | 51 |
| 5120×5120（26.2 MP） | 4.2 | 10 | 21 | 15 | 34 | 9.7 | 24 |
这张表有两处值得记住的结论：5 MP 单色在千兆网口上顶到 22 fps 左右，这是多相机千兆方案最常撞上的天花板；12 MP 以上想跑 30 fps，无论哪个接口都得先看主机侧能不能吃下——单色 12.3 MP、30 fps 已经是 369 MB/s 的持续写入压力。
六、算例
算例 1：5 MP 单色，要 60 fps
单帧 5.01 MB，60 fps 即 301 MB/s。工程可用值已含运行余量，直接对准它比：千兆网口（100–115 MB/s）只到 22 fps 左右，不够；2.5GBASE-T（250–280 MB/s）也只到 50–55 fps，同样不够。能满足 60 fps 的是 5GBASE-T（520–560）、USB 3.0（约 400，余量约 25%，是否真够还要看相机包长与主机实现）、CXP-6 单通道（625）、Camera Link Full（680）。若必须走双绞线而手上只有 2.5GBASE-T，就把帧率压到 50 fps 以内。
算例 2：一条千兆链路接两台 2 MP 彩色相机，各 30 fps
1920×1080 的 RGB8 每帧 6.22 MB，30 fps 需要 187 MB/s，单台就超过千兆网口的可用值；换成 YUV422_8 后降到 124 MB/s，仍然超。把帧率降到 20 fps 并改用 YUV422_8，单台 83 MB/s，两台合计 166 MB/s，还是超过一条千兆链路。结论是不换接口就必须把两台相机分到不同端口，或者上 2.5GBASE-T（250–280 MB/s）留出余量。
算例 3：多路高速接口进同一台工控机
四路 CXP-6 相机合计约 2.5 GB/s，这笔流量最终都要落到采集卡所在的 PCIe 链路上。按上表，PCIe Gen 3 ×4（约 3.5 GB/s）尚有余量，Gen 2 ×4 的 2 GB/s 一级就顶不住了，何况还要与网卡、存储争用根复合体带宽。这一层经常被忽略：接口选对了、采集卡插槽不够宽，现象同样是丢帧。
七、四条常见误算与结论边界
- 把位深当字节数。12 bit 未打包占 2 字节，只有标了 packed 才是 1.5 字节；按 1.5 字节去套未打包格式，算出来的带宽会低 25%，现场表现为「按计算够用却偶尔丢帧」。
- 把名义速率当可用带宽。千兆网口不是 125 MB/s 随便用，USB 3.0 的 5 Gbit/s 也不是 500 MB/s 可用；编码开销、报文头、帧间间隔与协议控制流量都在吃这份预算。
- 漏掉主机侧。采集卡插在 PCIe Gen 2 ×1 上、内存拷贝路径没走大页、CPU 中断集中在一个核、落盘用机械盘，任何一环低于链路速率，瓶颈就不在接口上。
- 多相机只按平均值算。多台相机共用一个上行端口时，持续带宽要按各相机平均数据率之和核算，还要用同时触发时的瞬时叠加去校核缓冲；只算平均、不留瞬时余量，现场表现就是偶发丢包。
结论边界同样要说清楚：表中的「工程可用值」是按标准线速与编码效率推算的保守值，实际相机的单包载荷上限、网卡与交换机的巨帧配置、驱动与操作系统的收发缓冲都会改变结果；不同厂商对同一接口的标称方式也不完全一致。做方案时先用这套速查把量级定下来，再用目标相机与采集卡做一次实测，用丢帧计数和带宽占用曲线确认余量是否真的留住了。压缩、ROI 与 binning 都能降低带宽需求，但它们改变的是数据本身，不能替代对链路能力的核算。
