持续创作，加速成长！这是我参与「掘金日新计划 · 10 月更文挑战」的第12天，点击查看活动详情
这里需要注意的是，由于在线模式 ISP 只能为一个 sensor 服务，所以它并不需要满负荷工作。如果 ISP 系统的硬件设计支持动态调整时钟频率，则应该把 ISP 的主频调低到 100MHz 以下，与 sensor 主频适配， 此时既能满足业务处理的要求，也能降低硬件功耗。对于电池供电的产品来说，这个特性是至关重要的
1 低延迟 Encoder 常规的 video encoder IP 都是以帧为单位进行编码的，典型的流畅是，从 ISP 出来的一帧 YUV 图像先进 入内存队列排队，encoder 空闲时会从队列中取出一帧进行编码。H.264 标准支持对图像进行分片（slice）， 每个 slice 包含一定数量的宏块（macroblock），多个 slice 构成一帧。尽管有些 encoder IP 支持以 slice 为 单位输出编码码流，但实践中多数产品还是以帧为单位输出编码码流，这时一帧就是一个 slice。 在对 encoder 进行低延时设计时，使用 slice 并不是一个终极解决方案，因为 slice 机制的主要设计意图 并不是支持低延迟，而是控制码流错误的传播范围，在一个 slice 中发生的误码不可能传播到其它 slice 中 去。在实践中，很多 encoder IP 只支持 1 个 slice，也有些 IP 支持最多 4 个 slice，对于 1080p 图像，平均 每个 slice 包含 270 行像素。在前文中我们已经分析过，H.264 只需要缓冲 16 行数据就可以开始编码了， 如果每隔 270 行输出一次，虽然离硬件极限接近了一些，但总是感觉还不够好。
显然，最理想的 encoder 设计是以 16 行为单位进行编码，每完成 16 行就输出一次，这样的输出效率 就最大限度地逼近了硬件极限，可以实现很低的延迟了。
可能有热心观众会问，这个方案虽然挺好了，但还能再继续压缩码？其实也不是完全不可能，因为 H.264 标准还支持 8x8、4x4 等宏块，如果我们决定牺牲一点编码效率，固定使用 8x8 这一种编码形式，则延迟还 有可能进一步压缩。如果让市场部门负责给这个技术起个名字，保不齐会就会出现“零延迟编码”这类存在 夸大嫌疑的广告语。
