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

到目前位置，我们理想中的梦幻 encoder 已经能够以 16 行为单位输出编码码流了，所以接下来的任务 就是用最快的速度把这些比特流送到网络上去。我看到有些热心观众已经开始跃跃欲试地举手了，它们一 定是想说，先把这些数据送到内存里，然后 encoder 给 CPU 一个中断，CPU 立刻使用 socket 把数据传出 去，这样延迟就很低了。

对于持有这些想法的热心观众，我只能说，其实想象力很重要，不要被思维定势画地为牢了。在一个真 正的低延迟 camera 里，我们其实不需要 socket 这类技术，因为该技术会涉及多次内存拷贝，效率还不够 高。我们的终极做法是在 encoder 后面设计一个硬件 DMA，当 encoder 的输出攒够一定数量时（比如 1460 个字节），DMA 直接把比特流写入网卡芯片内置缓冲区的 data payload 位置，然后 CPU 介入，给 payload 补齐 54 个字节的 header，这就构成了一个完整的网络数据包，这笔数据就 ready to go 了。 根据以太网协议，CPU 需要填补的 packet header 包含 14 个字节的 Datalink header、20 个字节的 IP Header、20 个字节的 TCP Header。

需要补充的是，上述方案是以 TCP 协议为码流载体的，由于没有使用标准的 socket 服务，方案的设计 者需要自行解决 TCP 协议栈的问题，这多多少少还是有些技术难度的，对于已经聪明绝顶的工程师来说， 可能还要再牺牲几根头发。实际上在低延迟应用中，更多场合会倾向于使用简单快捷的 UDP 协议，工程师 能够保住头发，客户也非常满意。

总结 通过本文的分析我们知道了，camera latency 的主要来源不是硬件处理，而是因为各种原因导致的等待： 软件或或硬件出于算法和调度的需要，必须先将像素数据凑齐成一个基本单位才能启动处理。如果这个单 位是帧，则会引入非常显著的延迟，所以理想的低延迟方案需要摒弃以帧为单位对像素数据进行处理，而 是尽可能以行为单位，只要积累的像素行数满足了硬件的最低要求，就立刻开始硬件处理。如果每个处理 环节都遵循这样的原则，就一定能够得到性能接近硬件极限的低延迟 camera 方案。