延迟来源分析：从Sensor到显示，每一毫秒都算数
做ISP Pipeline最头疼的是什么？我个人觉得，不是算法调优，而是延迟。你想想看，Sensor已经曝光完了，数据在MIPI链路上跑着，ISP还在处理上一帧，DDR带宽又被其他模块占着——整个系统就像一条流水线，任何一个环节卡住，帧率就往下掉。
这一章，我们来拆解延迟的五个主要来源。我在好几个项目里都吃过延迟的亏，有一次甚至因为Sensor曝光和ISP处理没对齐，导致画面出现“撕裂”，被客户当场退货。嗯，从那以后，我对延迟分析就格外上心。
1. Sensor曝光延迟：一切延迟的起点
Sensor曝光延迟，说白了就是从发出曝光指令到像素电荷完全读出之间的时间。这个延迟由两部分组成：
- 曝光时间本身：由shutter speed决定，比如1/30s就是33.3ms，1/60s就是16.7ms。
- 读出时间：像素电荷从感光区转移到读出寄存器，再逐行输出。这个时间取决于Sensor的行频和分辨率。
举个例子，一个1080p的Sensor，行频假设是100kHz，那么读出1920行需要19.2ms。如果曝光时间设为16.7ms（1/60s），那么总延迟就是16.7 + 19.2 = 35.9ms。
关键点：曝光延迟是“阻塞式”的。在曝光和读出期间，Sensor无法开始下一帧的曝光。这就是为什么高帧率需要短曝光时间和高速读出。
我在项目中遇到过一个问题：Sensor的曝光时间设置得比帧周期还长，结果帧率直接腰斩。后来查了datasheet才发现，Sensor的帧周期必须大于“曝光时间 + 读出时间 + 消隐时间”。这个坑，大家一定要避开。
2. MIPI传输延迟：数据在路上的时间
Sensor读出数据后，通过MIPI CSI-2接口传输到ISP。MIPI传输延迟主要取决于：
- 数据速率：比如4-lane MIPI，每lane 1.5Gbps，总带宽6Gbps。
- 数据量：一帧图像的总bit数。比如1080p @ 10bit RAW，一帧数据量是1920×1080×10 = 20.7Mbit。
- 传输时间 = 数据量 / 总带宽。20.7Mbit / 6Gbps ≈ 3.45ms。
但实际延迟会比这个理论值大一些，因为MIPI协议有包开销、消隐期、以及LP（低功耗）模式切换的额外时间。
| 分辨率 | 位深 | MIPI配置 | 理论传输时间 | 实际典型延迟 |
|---|---|---|---|---|
| 1920×1080 | 10bit | 4-lane @ 1.5Gbps | 3.45ms | 4~5ms |
| 3840×2160 | 12bit | 4-lane @ 2.5Gbps | 9.95ms | 11~13ms |
| 640×480 | 8bit | 2-lane @ 800Mbps | 1.92ms | 2.5~3ms |
经验之谈：MIPI传输延迟虽然不大，但它决定了ISP的“数据到达时间”。如果你的ISP处理速度比MIPI传输快，那ISP就得等数据；反过来，如果ISP处理慢，数据就会在FIFO里堆积。理想情况是两者匹配。
3. ISP处理延迟：核心计算的时间成本
ISP处理延迟，就是图像数据从进入ISP到处理完成的时间。这个延迟取决于：
- Pipeline长度：多少个处理模块串联。比如BLC → LSC → AWB → CFA → CCM → Gamma → YUV转换，每个模块都有延迟。
- 处理模式：逐行处理 vs. 逐帧处理。逐行延迟小，但帧间依赖少；逐帧延迟大，但可以做全局统计。
- 硬件加速：专用硬件模块（如3A统计、去噪、锐化）通常比软件快10~100倍。
我见过一个典型的ISP Pipeline，逐行处理模式下，每行延迟约0.5μs，1080p总共约1ms。但如果加上3A统计和帧缓存，延迟会飙升到5~10ms。
注意：ISP处理延迟不是固定的。它受输入数据速率、内部时钟频率、以及DDR带宽的影响。我曾经在一个项目中，因为DDR带宽被其他模块抢占，ISP处理时间从3ms变成了8ms，直接导致帧率下降。所以，ISP处理延迟一定要在“最坏情况”下评估。
4. DDR读写延迟：被忽视的隐形杀手
DDR读写延迟，是ISP Pipeline里最容易被低估的延迟来源。为什么？因为ISP需要频繁读写DDR：
- 写入原始RAW数据
- 读取中间结果（比如LSC校正表、AWB增益）
- 写入处理后的YUV/RGB数据
- 读取显示帧缓存
DDR延迟包括：
- 访问延迟：从发出请求到数据返回，典型值50~100ns（DDR4）或30~60ns（DDR5）。
- 带宽竞争：多个master（ISP、CPU、GPU、显示控制器）同时访问DDR，导致排队。
- 刷新周期：DDR需要定期刷新，刷新期间无法访问。
举个例子，一个1080p @ 30fps的ISP Pipeline，每帧需要读写约50MB数据（RAW输入 + 中间结果 + YUV输出）。如果DDR带宽是12.8GB/s（DDR4-3200单通道），理论传输时间只有3.9ms。但实际因为带宽竞争，可能变成10ms以上。
核心观点：DDR延迟不是固定的，它取决于系统负载。我建议在设计阶段就做DDR带宽预算，把ISP、显示、CPU、GPU的带宽需求加起来，确保不超过DDR总带宽的70%。留30%余量，避免峰值竞争。
5. 显示刷新延迟：最后一公里的等待
显示刷新延迟，是从ISP输出数据到屏幕上显示出来的时间。这个延迟由显示控制器和面板特性决定：
- 显示控制器：从DDR读取帧数据，按行扫描输出。延迟取决于行扫描时间和帧周期。
- 面板响应时间：液晶分子翻转的时间，典型值5~20ms（LCD）或1~3ms（OLED）。
- VSync同步：显示控制器通常以VSync为基准，ISP输出必须与VSync对齐，否则会出现tearing。
显示刷新延迟的典型值：
- 60Hz显示：帧周期16.7ms，加上面板响应，总延迟约20~30ms。
- 120Hz显示：帧周期8.3ms，总延迟约10~15ms。
小技巧：如果你做的是实时取景或视频通话，显示延迟直接影响用户体验。我建议使用“低延迟模式”，让ISP输出直接送到显示控制器，跳过DDR缓存。这样能减少1~2帧的延迟。
延迟全景图：一张图看懂所有环节
下面这张图，把五个延迟来源串在一起。你可以看到，从Sensor曝光到屏幕显示，数据经历了曝光、传输、处理、存储、显示五个阶段。每个阶段都有延迟，而且它们是串联的——总延迟就是所有阶段延迟之和。
延迟分析实战：一个1080p @ 30fps的案例
我们来看一个实际案例。假设系统参数如下：
- Sensor：1080p，曝光时间16.7ms，读出时间19.2ms
- MIPI：4-lane @ 1.5Gbps，传输时间约4ms
- ISP：逐行处理，Pipeline延迟约3ms
- DDR：单通道DDR4-3200，带宽竞争导致实际传输时间8ms
- 显示：60Hz LCD，面板响应10ms
总延迟 = 16.7 + 19.2 + 4 + 3 + 8 + 10 = 61ms。嗯，这个值对于实时取景来说，勉强可以接受。但如果要做视频通话，延迟最好控制在50ms以内。怎么办？
我当时的做法是：
- 把曝光时间从16.7ms降到8.3ms（1/120s），同时提高Sensor增益来补偿亮度。
- 把MIPI速率提高到2.0Gbps，传输时间降到3ms。
- 优化ISP Pipeline，把3A统计从帧级改成行级，延迟降到1.5ms。
- 给ISP分配独立的DDR通道，避免带宽竞争。
- 换成120Hz OLED面板，显示延迟降到8ms。
优化后总延迟 = 8.3 + 19.2 + 3 + 1.5 + 5 + 8 = 45ms。效果很明显。
避坑指南：我曾经在优化时只盯着ISP处理延迟，把Pipeline从10ms优化到2ms，结果总延迟只降了8ms。后来才发现，Sensor曝光和DDR读写才是大头。所以，做延迟分析一定要看全局，不要只优化自己熟悉的环节。
小结
这一章我们拆解了ISP Pipeline的五个延迟来源。每个来源都有其特点：Sensor曝光是阻塞式的，MIPI传输是线性的，ISP处理是可优化的，DDR读写是竞争性的，显示刷新是周期性的。理解这些特性，你才能有针对性地做延迟控制。