[转] 浅析低延迟Camera架构 _延迟

大话成像读者交流群：
大话成像技术论坛：
本站教学视频《成像算法基础（版）》《成像系统镜头光学》《图像质量测试测量与国际标准》《cmos 测试测量与国际标准》《新版数字成像系统40讲》已上线淘宝教育
《大话成像》淘宝官方网店上线，新内容持续更新中。
1 背景简介
广播电视、机器视觉、视频监控是video 产品的几个传统应用方向，近些年随着互联网的发展，网络直播行业异军突起，称为一个新的热点应用方向。这些貌似无关的领域其实一直以来都面临着一个共同的技术挑战，就是视频的流畅性和实时性。可能有很多人已经有过亲身体会了：在观看体育比赛直播的时候，有时隔壁邻居已经在欢呼进球了，而你的电视屏幕上射门还没有开始，这时你难免会感到有些不公平！这个例子其实就说明了视频延迟（）对用户体验的重要性，低延迟能够保证和谐自然的交流互动，而高延迟则会带来糟糕的用户体验。
【[转] 浅析低延迟Camera架构】那么，有哪些应用场景会特别关注视频的流畅性和实时性呢？
首先，像音乐会、体育比赛这种场景，每一个音符、每一帧画面都必须精确地出现在它应该出现的位置，没有抖动，没有延迟，一切动作都像行云流水般华丽自然，这将使观众获得“身临其境”的沉浸式体验，从一个遥远的观察者角色自然升级成一个现场参与者的角色。如果以“沉浸式体验“作为标准，一个视频或者是”流畅“的，或者是”不流畅“的，没有中间地带可言。
远程视频会议是另一个典型的场景。很多人都已经注意到了，当电视台主持人邀请远在前方现场的采访人员接管话筒时，此处画面总会出现几秒钟的延迟，这个延迟主要是卫星转发电视信号过程中引入的网络延迟，在这段时间里采访人员就在原地傻呆呆地站着，让观众感觉很不自然。由于延迟的影响，交互双方很容易出现抢话或冷场等意外情况，这显然会降低沟通效率，影响交互体验。
还有一种场景涉及对无人机、无人车等设备的遥控。显然，当你的无人机在远方飞行的时候，你收到的视频画面一定是零点几秒之前拍摄的。从画面上看你的无人机还在一个相对安全的位置，而实际上则不一定—你的小宝贝此时此刻可能已经撞墙挂掉了? 。有一个领域叫做竞速无人机比赛，一群参赛选手竞争谁的无人机能够最快飞到终点，途中需要躲避各种障碍物，就像小时候常玩的火箭车、马戏团等电子游戏一样。较快的无人机时速可以高达200km/h，也就是每秒能飞55米，如果画面延迟是0.1秒，则无人机的实际位置永远比飞手看到的要前出5.5米，这会给飞手操纵无人机造成额外的挑战。
其实消费级无人机存在的问题在技术上还属于小问题，某些用途更加严肃的无人飞行器，如米帝的全球鹰、战斧，某兔的彩虹，由于图像传输依赖卫星网络，控制中心收到的画面差不多是0.5秒之前的，而此时飞行器的实际位置可能已经前出了100米。当控制中心在画面上圈定目标并回传给前方飞行器时，飞行器上的计算机需要在本地回溯历史视频，在历史画面上识别出目标，然后通过跟踪算法判断出目标在最新画面上的位置（如果还在的话）。
2020年疫情的爆发给很多行业带来了新的机遇，很多原本只能在现场开会解决的问题都需要转移到线上进行，有些活动则需要线上线下同时进行。拍卖行业就是一个这样的例子，为了保证线上客户的合法权益，拍卖流程需要保证线上线下客户拥有平等的出价机会，这就要求音视频的延迟必须尽可能低，使线上的出价人完全感受不到差异。
人们预期，在未来的许多年里，市场对高分辨率、高帧率、低延迟视频服务的需求将保持高速增长的趋势，这就对video 产品提出了越来越高的要求。本文将对视频延迟的形成机制进行分析，并推导出低延迟的设计原理。
2 什么是延迟
延迟即，又称等待期，潜伏期，可以一般地描述为“因(cause)与果()之间的时间距离” 。在数字设计领域，指对一个数据进行一组处理所需的时间，一般以时钟周期（cycle）数为单位，若已知时钟频率，则可以转换成以秒、毫秒、微秒衡量的绝对时间。显然，以cycle数衡量的主要取决于数据处理过程（即处理算法）的复杂度，而以绝对时间衡量的则与时钟频率有关，频率越高越小。
在向别人解释概念时，程序员们最喜欢举两个例子，因为这两个例子项目经理最容易理解：
A、一个女人生孩子需要10个月，如果有人想下个月就抱小孩，是不是今天找到10个女人一起生就可以？
B、已知坐船去美国需要10天，如果有人想明天就到美国去看自由女神，是不是今天找到10艘船一起去就可以？
显然，这两个问题的答案都是“不可以”，它说明的道理是，是做一项工作的最少必要时间，采用并行化的手段可以增加系统的吞吐率（），但却无助于改善。
好了，想必到这里所有人都已经充分理解什么是了。在视频直播和视频监控领域，用户们比较关注的是从物理世界发生的事件（因）到电视屏幕上看到该事件（果）之间的时间延迟。在安防展会上，有经验的用户会在前快速挥手或眨眼，然后观察这个动作需要多久才能呈现在电视画面上，如果动作的延迟在0.1秒左右，用户就会流露出满意的笑容。如果延迟超过了0.5秒，用户可能就会摇摇头不辞而别。
随着时间的推移，已经有越来越多的用户学会了如何准确地测试视频延迟，下图显示的就是一种简便易行的方法，如今已被工程师和用户们熟练掌握。图中的DELL笔记本是笔者2007年在米帝开始第一份工作时公司配发的移动工作站，在当时配置是傲视群雄的，如今已经动过多次大手术但还能顽强地开机，估计有望坚持到女儿上大学做她的开学礼物。
话说回来，这种测试方法虽然简单，但总的来说效果不是特别理想。手机上的秒表软件定时精度比较低，很少有精确到1毫秒的，而常见的体育比赛秒表虽然定时精度还可以，但是由于液晶面板上的数字本身是不发光的，所以也很难拍清楚。
一种效果更好的方法是在电脑上运行一个精心挑选的计时软件，用拍摄软件显示的时间，类似下图这种数字又大又清晰的软件还是比较容易找的，效果一般都不错。
在专业的影像实验室里一般会使用壁挂式的多通道精确计时设备，采用主动发光的LED数码管显示时间，这样就可以在较远的距离上拍摄，无需贴近电脑屏幕。
1 什么是低延迟
低延迟即low ，这其实是一个相对模糊的概念，并没有一个绝对的定义，不同的应用领域对低延迟的定义往往相差迥异。在典型的人机交互场合，如视频会议，或电子游戏，100ms以下就可以认为是低延迟了。但是汽车、工控、医疗等场合则对延迟的要求会更加严格，从30ms到1ms都有可能，取决于具体用途。因此，低延迟本质上是一种市场宣传用语，它是相对于某种特定的用途或者相对于某些竞品性能而言的。
2 延迟的构成
目前主流的大多都遵循以下工作原理：
使用集成的MIPI CSI/LVDS等视频输入接口捕获CMOS 输出的RAW数据，这个过程产生的延迟称为video；
使用集成的ISP硬件对RAW数据进行流水线处理，生成YUV图像，这个过程产生的延迟称ISP；
使用集成的H.264/265硬件编码器对YUV图像进行编码，生成编码码流，这个过程产生的延迟称为video；
步骤1，2，3的延迟主要取决于芯片硬件性能，而三者之间还存在软件调度的延迟，硬件延迟和软件延迟的总和统称为；
使用RTSP/RTMP/HLS/SIP等流传输协议将编码码流传送到网络客户端，这个过程受网络拥堵和丢包情况影响较大，产生的延迟称为；
客户端使用等解码软件对收到的码流进行解码，得到YUV图像，这个过程产生的延迟称为video。当客户端需要处理多路码流时，每个码流都需要在内存中排队等待CPU处理，所以里还包含了软件调度的延迟。目前较新版本的已经默认支持使用GPU进行解码，可以显著降低CPU占用率、降低；
客户端使用，等3D加速引擎对YUV图像进行2D和3D处理，包括像素格式转换、图像增强、图形层叠加、PIP贴图、3D投影变换、添加场景光源、计算阴影等处理任务，这个过程称为渲染（），产生的延迟称为；
渲染之后的图像被保存在显卡上的帧缓存（）中，显卡的视频控制器（Video ）会读取帧缓存中的信息，经过数模转换后送给显示器进行显示，这个过程称为video ，产生的延迟称为。
上述各种视频延迟的总和一般称为端到端（end-to-end）延迟，意思是从视频捕获端到视频显示端的延迟，用公式表示就是，
以上公式中的是本文所研究的主要问题，这里先说结论，是一个系统指标，包含了硬件和软件的贡献：硬件架构决定了系统能够做到的最小延迟，而软件架构也会对延迟产生重大的影响，合理高效的软件设计可以使系统总延迟接近硬件极限，而低效的软件设计则会引入不必要的延迟，降低产品性能。
1 延迟的根因
俗话说，不怕慢，就怕站。延迟的根本原因就是像素没有时刻跟随硬件时钟的节拍在流转，而是花了很多时间静静地呆在某个地方等待硬件处理。那么事情为什么会是这个样子呢？个中原因就一言难尽了，客官需要听我细细道来。
先从ISP讲起。ISP 一般是由一个个独立的处理模块组成，很多模块都需要使用滤波器对图像进行滤波，典型的滤波窗口尺寸有3x3，5x5，7x7，9x9，更大的还有17x17等等。以5x5滤波器为例，它会要求至少5行图像数据全部到齐以后才能开始滤波处理，在此之前，先到的数据就只能在某个缓存里边静静地等待，不许说话也不许乱动。以典型的1080p分辨率为例，输出一行图像需要大约2000个PCLK cycle，此处PCLK为主频，则ISP需要等待5行数据的时间，引入的延迟约为10,000个PCLK cycle，当PCLK频率为76MHz时，绝对延迟时间为132us 。这是ISP等待数据到齐的延迟，之后就开始了ISP内部处理，此时需要使用ISP主频计算处理延迟，不妨命名为ICLK 。根据ISP 的复杂度，一般需要几千个ICLK cycle之后数据开始流出ISP，这个延迟称为延迟。
接下来是video。以JPEG编码器为例，JPEG的核心算法是8x8大小的离散余弦变换，即DCT运算，该运算要求至少8行图像数据全部到齐以后才能开始处理。类似地，H.264要求16行，而H.265则要求64行。套用前面的公式，H.265缓存64行数据需要128,000个PCLK cycle，绝对延迟时间约为。在这个延迟之后，就可以开始处理数据了，此时需要使用主频计算处理延迟，不妨命名为ECLK 。根据的复杂度，一般需要几千个ECLK cycle之后编码数据开始流出。笔者曾经参与过一个简化版H.264 设计，该设计中，一个像素从开始处理到离开只需要530个ECLK cycle，每个ECLK时值18ns，所以硬件延迟为9.5us 。
从以上分析可以知道，典型的硬件延迟其实是非常小的，ISP和的延迟之和可以做到2ms以内，如果只考虑算法本身的延迟则更小，与动辄100ms以上的端到端延迟相比，几乎可以忽略不计。接下来的问题就很显然了，剩下的这么多延迟都是怎么来的呢？其实问题的根因很简单，就四个字：“离线模式” 。

文章插图
1 离线与在线模式
所谓离线模式就是说，从CMOS 捕获到的数据不是立即马上right away送给ISP去处理，而是先输出到内存中的帧缓存（frame ）中，等到一帧完整的数据捕获完毕后ISP才择机开始处理。以30fps帧率为例，等到一帧图像捕获完成后，图像的第一个像素数据已经在内存中白白等待接近30ms的时间了。在此基础上，“择机”二字的具体含义是，ISP其实不一定什么时候才能开始处理，有的时候可能要再等上一两帧之后ISP才有空，等ISP终于有空的时候，它读取的图像可能已经是两三帧之前的历史图像了，仍以30fps帧率为例，这就意味着刚才那个像素已经等了60ms以上。在系统中，这种由缓冲引起的延迟是最主要的延迟来源。
ISP离线模式原理示意图
那么ISP为什么会这么忙，以至于要等一两帧之后才有机会处理图像呢？显然，这样设计是故意的，并且有着非常合理的原因。按照当前的主流IP的技术水平，ISP和video 的主频很容易做到，有些芯片甚至可以做到1GHz以上。前面提到过CMOS 在输出1080p@30fps时典型主频在76MHz左右，所以IP的实际处理能力是输出能力的10倍以上。这么强大的处理能力如果只为一个服务显然是太奢侈了，所以现实情况是一个ISP最少需要同时支持两个，有些产品则需要支持4个甚至8个。比如笔者手里价格高达1000余元的红米Note8手机就装有5个摄像头，同时ISP还有惊人的图像处理能力。显然，ISP需要以分时复用的方式一个个处理来自各个的图像，这就需要软件逻辑介入对多个的处理任务进行合理的调度。如果软件设计的不尽合理，或者CPU处理能力不够，当所有一起跑实时流时，就很容易出现某些处理不及时的情况。
看到这里很多观众可以长出一口气了，原来的主要原因在于离线模式。如果我的产品没有支持多的需求，那是不是就可以让ISP专心处理一个的图像，就可以做到更好的实时性了。Bingo! 当一个ISP只需要支持一个时，出来的数据不需要经过DDR排队的过程，而是通过一个专用的硬件通路（VIP Path）直接送给ISP进行处理，这种工作方式叫做在线模式。
ISP在线模式原理示意图
前面已经计算过，ISP等待5行数据到达引入的延迟约为10,000个PCLK cycle，而内部处理的延迟一般不超过5000个ICLK，为计算方便不妨假设ICLK频率是PCLK的5倍，则ISP处理的总延迟约为11000个PCLK，折合绝对时间约为145us 。
这里需要注意的是，由于在线模式ISP只能为一个服务，所以它并不需要满负荷工作。如果ISP系统的硬件设计支持动态调整时钟频率，则应该把ISP的主频调低到以下，与主频适配，此时既能满足业务处理的要求，也能降低硬件功耗。对于电池供电的产品来说，这个特性是至关重要的。
1 低延迟
常规的videoIP都是以帧为单位进行编码的，典型的流畅是，从ISP出来的一帧YUV图像先进入内存队列排队，空闲时会从队列中取出一帧进行编码。H.264标准支持对图像进行分片（slice），每个slice包含一定数量的宏块（），多个slice构成一帧。尽管有些 IP支持以slice为单位输出编码码流，但实践中多数产品还是以帧为单位输出编码码流，这时一帧就是一个slice 。
在对进行低延时设计时，使用slice并不是一个终极解决方案，因为slice机制的主要设计意图并不是支持低延迟，而是控制码流错误的传播范围，在一个slice 中发生的误码不可能传播到其它slice中去。在实践中，很多 IP只支持1个slice，也有些IP支持最多4个slice，对于1080p图像，平均每个slice包含270行像素。在前文中我们已经分析过，H.264只需要缓冲16行数据就可以开始编码了，如果每隔270行输出一次，虽然离硬件极限接近了一些，但总是感觉还不够好。
显然，最理想的设计是以16行为单位进行编码，每完成16行就输出一次，这样的输出效率就最大限度地逼近了硬件极限，可以实现很低的延迟了。
可能有热心观众会问，这个方案虽然挺好了，但还能再继续压缩码？其实也不是完全不可能，因为H.264标准还支持8x8、4x4等宏块，如果我们决定牺牲一点编码效率，固定使用8x8这一种编码形式，则延迟还有可能进一步压缩。如果让市场部门负责给这个技术起个名字，保不齐会就会出现“零延迟编码”这类存在夸大嫌疑的广告语。
2 低延迟流传输
到目前位置，我们理想中的梦幻已经能够以16行为单位输出编码码流了，所以接下来的任务就是用最快的速度把这些比特流送到网络上去。我看到有些热心观众已经开始跃跃欲试地举手了，它们一定是想说，先把这些数据送到内存里，然后给CPU一个中断，CPU立刻使用把数据传出去，这样延迟就很低了。
对于持有这些想法的热心观众，我只能说，其实想象力很重要，不要被思维定势画地为牢了。在一个真正的低延迟里，我们其实不需要这类技术，因为该技术会涉及多次内存拷贝，效率还不够高。我们的终极做法是在后面设计一个硬件DMA，当的输出攒够一定数量时（比如1460个字节），DMA直接把比特流写入网卡芯片内置缓冲区的data 位置，然后CPU介入，给补齐54个字节的，这就构成了一个完整的网络数据包，这笔数据就ready to go了。
根据以太网协议，CPU需要填补的包含14个字节的、20个字节的IP 、20个字节的TCP。方案的基本原理如下图所示。
低延迟流传输原理示意图
需要补充的是，上述方案是以TCP协议为码流载体的，由于没有使用标准的服务，方案的设计者需要自行解决TCP协议栈的问题，这多多少少还是有些技术难度的，对于已经聪明绝顶的工程师来说，可能还要再牺牲几根头发。实际上在低延迟应用中，更多场合会倾向于使用简单快捷的UDP协议，工程师能够保住头发，客户也非常满意。
1 总结
通过本文的分析我们知道了，的主要来源不是硬件处理，而是因为各种原因导致的等待：软件或或硬件出于算法和调度的需要，必须先将像素数据凑齐成一个基本单位才能启动处理。如果这个单位是帧，则会引入非常显著的延迟，所以理想的低延迟方案需要摒弃以帧为单位对像素数据进行处理，而是尽可能以行为单位，只要积累的像素行数满足了硬件的最低要求，就立刻开始硬件处理。如果每个处理环节都遵循这样的原则，就一定能够得到性能接近硬件极限的低延迟方案。
---------------------