浅析低延迟Camera架构

本文系微信公众号《大话成像》,知乎专栏《all in camera》原创文章,转载请注明出处。
大话成像读者QQ 交流群 :237427716
大话成像技术论坛:www.dahuachengxiang.com
本站教学视频《成像算法基础(python版)》 《成像系统镜头光学》《图像质量测试测量与国际标准》《cmos sensor测试测量与国际标准》《新版数字成像系统40讲》已上线淘宝教育
《大话成像》淘宝官方网店上线,新内容持续更新中。
https://shop322456667.taobao.com/

1 背景简介

广播电视、机器视觉、视频监控是video camera产品的几个传统应用方向,近些年随着互联网的发展,网络直播行业异军突起,称为一个新的热点应用方向。这些貌似无关的领域其实一直以来都面临着一个共同的技术挑战,就是视频的流畅性和实时性。可能有很多人已经有过亲身体会了:在观看体育比赛直播的时候,有时隔壁邻居已经在欢呼进球了,而你的电视屏幕上射门还没有开始,这时你难免会感到有些不公平!这个例子其实就说明了视频延迟(latency)对用户体验的重要性,低延迟能够保证和谐自然的交流互动,而高延迟则会带来糟糕的用户体验。
那么,有哪些应用场景会特别关注视频的流畅性和实时性呢?
首先,像音乐会、体育比赛这种场景,每一个音符、每一帧画面都必须精确地出现在它应该出现的位置,没有抖动,没有延迟,一切动作都像行云流水般华丽自然,这将使观众获得“身临其境”的沉浸式体验,从一个遥远的观察者角色自然升级成一个现场参与者的角色。如果以“沉浸式体验“作为标准,一个视频或者是”流畅“的,或者是”不流畅“的,没有中间地带可言。
远程视频会议是另一个典型的场景。很多人都已经注意到了,当电视台主持人邀请远在前方现场的记者接管话筒时,此处画面总会出现几秒钟的延迟,这个延迟主要是卫星转发电视信号过程中引入的网络延迟,在这段时间里记者就在原地傻呆呆地站着,让观众感觉很不自然。由于延迟的影响,交互双方很容易出现抢话或冷场等意外情况,这显然会降低沟通效率,影响交互体验。
还有一种场景涉及对无人机、无人车等设备的遥控。显然,当你的无人机在远方飞行的时候,你收到的视频画面一定是零点几秒之前拍摄的。从画面上看你的无人机还在一个相对安全的位置,而实际上则不一定—你的小宝贝此时此刻可能已经撞墙挂掉了☹。有一个领域叫做竞速无人机比赛,一群参赛选手竞争谁的无人机能够最快飞到终点,途中需要躲避各种障碍物,就像小时候常玩的火箭车、马戏团等电子游戏一样。较快的无人机时速可以高达200km/h,也就是每秒能飞55米,如果画面延迟是0.1秒,则无人机的实际位置永远比飞手看到的要前出5.5米,这会给飞手操纵无人机造成额外的挑战。
其实消费级无人机存在的问题在技术上还属于小问题,某些用途更加严肃的无人飞行器,如米帝的全球鹰、战斧,某兔的彩虹,由于图像传输依赖卫星网络,控制中心收到的画面差不多是0.5秒之前的,而此时飞行器的实际位置可能已经前出了100米。当控制中心在画面上圈定目标并回传给前方飞行器时,飞行器上的计算机需要在本地回溯历史视频,在历史画面上识别出目标,然后通过跟踪算法判断出目标在最新画面上的位置(如果还在的话)。
2020年疫情的爆发给很多行业带来了新的机遇,很多原本只能在现场开会解决的问题都需要转移到线上进行,有些活动则需要线上线下同时进行。拍卖行业就是一个这样的例子,为了保证线上客户的合法权益,拍卖流程需要保证线上线下客户拥有平等的出价机会,这就要求音视频的延迟必须尽可能低,使线上的出价人完全感受不到差异。
人们预期,在未来的许多年里,市场对高分辨率、高帧率、低延迟视频服务的需求将保持高速增长的趋势,这就对video camera产品提出了越来越高的要求。本文将对camera视频延迟的形成机制进行分析,并推导出低延迟camera的设计原理。

2 什么是延迟

延迟即latency,又称等待期,潜伏期,可以一般地描述为“因(cause)与果(result)之间的时间距离”。在数字设计领域,latency指对一个数据进行一组处理所需的时间,一般以时钟周期(cycle)数为单位,若已知时钟频率,则可以转换成以秒、毫秒、微秒衡量的绝对时间。显然,以cycle数衡量的latency主要取决于数据处理过程(即处理算法)的复杂度,而以绝对时间衡量的latency则与时钟频率有关,频率越高latency越小。
在向别人解释latency概念时,程序员们最喜欢举两个例子,因为这两个例子项目经理最容易理解:
A、一个女人生孩子需要10个月,如果有人想下个月就抱小孩,是不是今天找到10个女人一起生就可以?
B、已知坐船去美国需要10天,如果有人想明天就到美国去看自由女神,是不是今天找到10艘船一起去就可以?
显然,这两个问题的答案都是“不可以”,它说明的道理是,latency是做一项工作的最少必要时间,采用并行化的手段可以增加系统的吞吐率(throughput),但却无助于改善latency。
好了,想必到这里所有人都已经充分理解什么是latency了。在视频直播和视频监控领域,用户们比较关注的latency是从物理世界发生的事件(因)到电视屏幕上看到该事件(果)之间的时间延迟。在安防展会上,有经验的用户会在camera前快速挥手或眨眼,然后观察这个动作需要多久才能呈现在电视画面上,如果动作的延迟在0.1秒左右,用户就会流露出满意的笑容。如果延迟超过了0.5秒,用户可能就会摇摇头不辞而别。
随着时间的推移,已经有越来越多的用户学会了如何准确地测试视频延迟,下图显示的就是一种简便易行的方法,如今已被工程师和用户们熟练掌握。图中的DELL笔记本是笔者2007年在米帝开始第一份工作时公司配发的移动工作站,在当时配置是傲视群雄的,如今已经动过多次大手术但还能顽强地开机,估计有望坚持到女儿上大学做她的开学礼物。

浅析低延迟Camera架构_第1张图片
话说回来,这种测试方法虽然简单,但总的来说效果不是特别理想。手机上的秒表软件定时精度比较低,很少有精确到1毫秒的,而常见的体育比赛秒表虽然定时精度还可以,但是由于液晶面板上的数字本身是不发光的,所以camera也很难拍清楚。
一种效果更好的方法是在电脑上运行一个精心挑选的计时软件,用camera拍摄软件显示的时间,类似下图这种数字又大又清晰的软件还是比较容易找的,效果一般都不错。
浅析低延迟Camera架构_第2张图片
在专业的影像实验室里一般会使用壁挂式的多通道精确计时设备,采用主动发光的LED数码管显示时间,这样camera就可以在较远的距离上拍摄,无需贴近电脑屏幕。
浅析低延迟Camera架构_第3张图片

1 什么是低延迟

低延迟即low latency,这其实是一个相对模糊的概念,并没有一个绝对的定义,不同的应用领域对低延迟的定义往往相差迥异。在典型的人机交互场合,如视频会议,或电子游戏,100ms以下就可以认为是低延迟了。但是汽车、工控、医疗等场合则对延迟的要求会更加严格,从30ms到1ms都有可能,取决于具体用途。因此,低延迟本质上是一种市场宣传用语,它是相对于某种特定的用途或者相对于某些竞品性能而言的。

2 延迟的构成

目前主流的camera大多都遵循以下工作原理:
使用集成的MIPI CSI/LVDS等视频输入接口捕获CMOS sensor输出的RAW数据,这个过程产生的延迟称为video capture latency;
使用集成的ISP硬件对RAW数据进行流水线处理,生成YUV图像,这个过程产生的延迟称ISP pipeline latency;
使用集成的H.264/265硬件编码器对YUV图像进行编码,生成编码码流,这个过程产生的延迟称为video encoding latency;
步骤1,2,3的延迟主要取决于芯片硬件性能,而三者之间还存在软件调度的延迟,硬件延迟和软件延迟的总和统称为camera latency;
使用RTSP/RTMP/HLS/SIP等流传输协议将编码码流传送到网络客户端,这个过程受网络拥堵和丢包情况影响较大,产生的延迟称为network latency;
客户端使用FFMPEG等解码软件对收到的码流进行解码,得到YUV图像,这个过程产生的延迟称为video decoding latency。当客户端需要处理多路码流时,每个码流都需要在内存中排队等待CPU处理,所以decoding latency里还包含了软件调度的延迟。目前较新版本的FFMPEG已经默认支持使用GPU进行解码,可以显著降低CPU占用率、降低decoding latency;
客户端使用OpenGL,DirectX等3D加速引擎对YUV图像进行2D和3D处理,包括像素格式转换、图像增强、图形层叠加、PIP贴图、3D投影变换、添加场景光源、计算阴影等处理任务,这个过程称为渲染(rendering),产生的延迟称为rendering latency;
渲染之后的图像被保存在显卡上的帧缓存(FrameBuffer)中,显卡的视频控制器(Video Controller)会读取帧缓存中的信息,经过数模转换后送给显示器进行显示,这个过程称为video display,产生的延迟称为screen latency。

上述各种视频延迟的总和一般称为端到端(end-to-end)延迟,意思是从视频捕获端到视频显示端的延迟,用公式表示就是,
在这里插入图片描述
以上公式中的camera latency是本文所研究的主要问题,这里先说结论,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。
浅析低延迟Camera架构_第4张图片
从以上分析可以知道,典型的硬件延迟其实是非常小的,ISP和encoder的延迟之和可以做到2ms以内,如果只考虑算法pipeline本身的延迟则更小,与动辄100ms以上的端到端延迟相比,几乎可以忽略不计。接下来的问题就很显然了,剩下的这么多延迟都是怎么来的呢?其实问题的根因很简单,就四个字:“离线模式”。

1 离线与在线模式

所谓离线模式就是说,从CMOS sensor捕获到的数据不是立即马上right away送给ISP去处理,而是先输出到内存中的帧缓存(frame buffer)中,等到一帧完整的数据捕获完毕后ISP才择机开始处理。以30fps帧率为例,等到一帧图像捕获完成后,图像的第一个像素数据已经在内存中白白等待接近30ms的时间了。在此基础上,“择机”二字的具体含义是,ISP其实不一定什么时候才能开始处理,有的时候可能要再等上一两帧之后ISP才有空,等ISP终于有空的时候,它读取的图像可能已经是两三帧之前的历史图像了,仍以30fps帧率为例,这就意味着刚才那个像素已经等了60ms以上。在camera系统中,这种由buffer缓冲引起的延迟是最主要的延迟来源。
浅析低延迟Camera架构_第5张图片
ISP离线模式原理示意图
那么ISP为什么会这么忙,以至于要等一两帧之后才有机会处理sensor图像呢?显然,这样设计是故意的,并且有着非常合理的原因。按照当前的主流IP的技术水平,ISP和video encoder的主频很容易做到800MHz,有些芯片甚至可以做到1GHz以上。前面提到过CMOS sensor在输出1080p@30fps时典型主频在76MHz左右,所以IP的实际处理能力是sensor输出能力的10倍以上。这么强大的处理能力如果只为一个sensor服务显然是太奢侈了,所以现实情况是一个ISP最少需要同时支持两个sensor,有些产品则需要支持4个甚至8个sensor。比如笔者手里价格高达1000余元的红米Note8手机就装有5个摄像头,同时ISP还有惊人的图像处理能力。显然,ISP需要以分时复用的方式一个个处理来自各个sensor的图像,这就需要软件逻辑介入对多个sensor的处理任务进行合理的调度。如果软件设计的不尽合理,或者CPU处理能力不够,当所有sensor一起跑实时流时,就很容易出现某些sensor处理不及时的情况。
看到这里很多观众可以长出一口气了,原来camera latency的主要原因在于离线模式。如果我的产品没有支持多sensor的需求,那是不是就可以让ISP专心处理一个sensor的图像,就可以做到更好的实时性了。Bingo! 当一个ISP只需要支持一个sensor时,sensor出来的数据不需要经过DDR排队的过程,而是通过一个专用的硬件通路(VIP Path)直接送给ISP进行处理,这种工作方式叫做在线模式。
浅析低延迟Camera架构_第6张图片
ISP在线模式原理示意图
前面已经计算过,ISP等待5行数据到达引入的延迟约为10,000个PCLK cycle,而内部处理的延迟一般不超过5000个ICLK,为计算方便不妨假设ICLK频率是PCLK的5倍,则ISP处理的总延迟约为11000个PCLK,折合绝对时间约为145us。
这里需要注意的是,由于在线模式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这一种编码形式,则延迟还有可能进一步压缩。如果让市场部门负责给这个技术起个名字,保不齐会就会出现“零延迟编码”这类存在夸大嫌疑的广告语。

2 低延迟流传输

到目前位置,我们理想中的梦幻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。方案的基本原理如下图所示。
浅析低延迟Camera架构_第7张图片
低延迟流传输原理示意图
需要补充的是,上述方案是以TCP协议为码流载体的,由于没有使用标准的socket服务,方案的设计者需要自行解决TCP协议栈的问题,这多多少少还是有些技术难度的,对于已经聪明绝顶的工程师来说,可能还要再牺牲几根头发。实际上在低延迟应用中,更多场合会倾向于使用简单快捷的UDP协议,工程师能够保住头发,客户也非常满意。

1 总结

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

你可能感兴趣的:(浅析低延迟Camera架构)