跟着卷卷龙一起学 Camera-- 低延迟 02

camera latency 是一个系统指 标，包含了硬件和软件的贡献：硬件架构决定了系统能够做到的最小延迟，而软件架构也会对延迟产生重 大的影响，合理高效的软件设计可以使系统总延迟接近硬件极限，而低效的软件设计则会引入不必要的延 迟，降低产品性能。

1 延迟的根因 俗话说，不怕慢，就怕站。Camera 延迟的根本原因就是像素没有时刻跟随硬件时钟的节拍在流转，而 是花了很多时间静静地呆在某个地方等待硬件处理。那么事情为什么会是这个样子呢？个中原因就一言难 尽了，客官需要听我细细道来。 先从 ISP 讲起。ISP pipeline 一般是由一个个独立的处理模块组成，很多模块都需要使用滤波器对图像进 行滤波，典型的滤波窗口尺寸有 3x3，5x5，7x7，9x9，更大的还有 17x17 等等。以 5x5 滤波器为例，它会 要求至少 5 行图像数据全部到齐以后才能开始滤波处理，在此之前，先到的数据就只能在某个缓存里边静 静地等待，不许说话也不许乱动。以典型的 1080p 分辨率为例，sensor 输出一行图像需要大约 2000 个 PCLK cycle，此处 PCLK 为 sensor 主频，则 ISP 需要等待 5 行 sensor 数据的时间，引入的延迟约为 10,000 个 PCLK cycle，当 PCLK 频率为 76MHz 时，绝对延迟时间为 132us。这是 ISP 等待数据到齐的延迟，之后就开始了 ISP 内部处理，此时需要使用 ISP 主频计算处理延迟，不妨命名为 ICLK。根据 ISP pipeline 的复杂度，一般 需要几千个 ICLK cycle 之后数据开始流出 ISP，这个延迟称为 pipeline 延迟。 接下来是 video encoder。以 JPEG 编码器为例，JPEG 的核心算法是 8x8 大小的离散余弦变换，即 DCT 运算，该运算要求至少 8 行图像数据全部到齐以后才能开始处理。类似地，H.264 要求 16 行，而 H.265 则 要求 64 行。套用前面的公式，H.265 缓存 64 行数据需要 128,000 个 PCLK cycle，绝对延迟时间约为 1684us。 在这个延迟之后，encoder 就可以开始处理数据了，此时需要使用 encoder 主频计算处理延迟，不妨命名 为 ECLK。根据 encoder 的复杂度，一般需要几千个 ECLK cycle 之后编码数据开始流出 encoder。笔者曾经 参与过一个简化版 H.264 encoder 设计，该设计中，一个像素从开始处理到离开 encoder 只需要 530 个 ECLK cycle，每个 ECLK 时值 18ns，所以硬件 pipeline 延迟为 9.5us。