在安防领域，超高清视频监控有着非常值得期待的应用前景，但只有解决了阻碍应用的传输、算力、算法、存储、安全等几个问题之后，应用的前景才会变得清晰起来。另一方面，传统网络正在发生天翻地覆的改变，计算和存储能力空前提高，算法进一步硬件化智能化，安全问题也从未像今天一样成为国家意志，凡此种种为超高清视频监控的技术突破带来了光明的前景和奋进的动力。
超高清视频监控面临的第一个问题是传输问题。由于4K视频超大的分辨率，对于25fps的帧率来说，在相同编码规格下，其码率约为高清视频（1080P）的4倍以上，对于传输的要求也相应提升了数倍。即使采用H.265等较为先进的编码方式，由于超高清视频在色深、帧率、分辨率等方面的改进，其传输量也是不可小觑的。到了8K超高清视频的时代，其传输量又会有成倍的增加。因此，增加带宽，即增加端侧的吞吐能力和增加中间链路的传输能力是超高清视频监控面临的首要问题。
（1）增加端侧的吞吐能力
端即超高清视频的接收端和发送端，增加两端的网卡上下行能力极为关键。上下行能力受以下因素制约：网卡性能、缓冲区大小与调度机制、网络协议栈工作效率、超高清视频监控应用进程本身的吞吐能力、视频接收与发送的策略等。
为了保证监控视频传输质量，我们以单千兆卡60%的有效上下行传输率计算。在单千兆卡的情况下，对于H.264MainProfile编码的4K超高清视频，即使其码率只有1080P的4倍也会接近30Mbps，因此单千兆网卡只能承载20路左右的4K超高清视频。这对于浏览客户端可能问题不大，但对于流媒体服务器是远远不够的。因此，从千兆卡升级到万兆卡，或者多张千兆卡绑定以扩展上下行能力就显得尤为重要。
另一方面，对于诸多由软件完成的传输功能，例如网络包软校验、加解密、DPI等功能完全可以“卸载”到硬件中执行，这就是我们耳熟能详的硬件卸载加速技术。通过SOC的方式将这些功能以硬件语言设计和描述，在SOC内实现ASIC电路是一种明智之举。
视频监控的网络传输应用中流媒体服务器占了流量的大头。因此流媒体服务有针对性地改进机制和提升性能就显得越发必要。缓冲区作为网卡与操作系统、应用软件交互的中间媒介理应做出相应的改进。
a.HugePage机制：操作系统中内存页面的分配粒度是4KB，对于超高清视频这显然是不够的，因此有选择性地启用大内存页机制甚至巨页机制，使其分配的粒度达到若干MB甚至1GB，以减少内存页倒换带来的系统开销，这无论对于发送端还是接收端都具有很重要的意义。
b.DMA机制：DMA即直接内存存取机制。通过DMA可以摒弃传统的“网卡缓存->主存->CPU缓存”的传输路径，转而通过DMA控制器建立网卡缓存到CPU三级缓存之间的映射实现数据的快速交换。由于绕过了主存读写这个速度较慢的步骤并省略了2次PCI-E总线的IO，因此读写速度会大大加快。
传统网络协议栈是以内核态驱动的方式存在于操作系统中的，其关键工作机制是中断响应、延迟过程处理、通用包处理。
中断响应：传统网络协议栈驱动以网卡的中断机制为基础，网络包的到达和发送完成均以中断机制通知上层网络协议栈，以便协议栈驱动继续处理接收和发送。
延迟过程处理：协议栈驱动响应中断后，并不是将包的收取或发送处理包含在中断处理例程中占用中断时间，因为中断的优先级较高，如果中断占用的时间太长会影响其他优先级线程的执行，因此中断处理例程将具体的收取/发送等事务性工作放在DPC（延迟过程调用）队列中，待中断优先级下降时才处理，这样就减少了中断打扰占用的时间。
通用包机制：网络协议栈是瞄准通用型网络包处理的，因此对于OSI模型的每层协议都会进行相应的处理和校验，这比较适合流量不大包类型各异的情况。而在高清视频流媒体服务器上流量较大，且传输的一般为信令报文和视频包，其协议格式和封装方式固定。
上述机制在一定程度上降低了协议栈的处理效率。针对超高清视频流媒体服务器，可以采用改进的网络协议栈对传统协议栈进行旁路化改进，比如定制专门针对流媒体传输的专用协议栈驱动，或者嫁接高速传输设备的协议栈驱动。DPDK（数据平面开发套件）框架就是一个较好的选择。DPDK是一种基于IntelX86/X64平台的网络数据包处理框架，也是一套数据包旁路化处理的方案，具有很高的IO处理速度，多用于SDN高速交换机和路由器的转发驱动框架，具有以下特点和机制：
a.UIO机制：UIO（UserspaceI/O）机制将小部分驱动运行在内核态空间（硬中断只能在内核态空间处理），大部分运行在用户态空间以实现旁路化机制。
b.SIMD机制：DPDK框架采用批量方式同时处理多个网络数据包，基于向量式编程，一个周期内对所有网络数据包进行处理，加大了处理吞吐量。
c.缓存优化机制：采用Cacheline对齐、Cache数据预取等策略加快缓存中数据的读取和处理速度。
d.PDM机制：PDM（PoolModeDriver）机制抛弃中断模式，改为基于中断+轮询的方式收包，避免了中断开销。
e.无锁循环队列机制：支持单生产者入列、单消费者出列和多生产者入列、多消费者出列的操作，因此可以提高传输效率并保证数据同步。
f.处理器亲和性机制：利用处理器亲和性（CPUAffinity）机制将IO线程绑定到若干个CPU核上，以此减少线程调度和切换从而降低切换开销，同时由于线程被绑定在固定的CPU核上，CPU缓存的命中率大大提高。
g.多队列机制：通过多队列网卡驱动的支持，将各个队列绑定到不同的CPU核上，以满足网卡高吞吐的需求。
h.DDIO机制：DDIO（DataDirectIO）是Intel提出的技术，允许网卡与CPU通过LLC（lastlevelcache）直接交换网络数据，从而绕过主存，既缩短了交互流程，也提升了交互的速度。该技术类似DMA机制，但比DMA具有更高的效率。
i.硬件加速机制：将基础性重复性的软事务（例如计算分析类任务、TCP组包类任务和TCP分段任务等）“卸载”给硬件完成以加快处理速度。
图3采用DPDK框架旁路化网络协议栈
除了网络传输外，在视频存储领域亦可以采用SPDK（StoragePerformanceDevelopmentKit）框架以代替传统存储协议栈驱动框架，SPDK不失为一种效率成倍提升的有效手段，且该框架更是当今非常流行的软件定义存储的加速器。
除了上述几种机制外，还可针对超高清视频的特点对传输节点进行改进。例如基于视频包封装协议较为固定的特点，会话协商报文可通过传统协议栈流转，而流媒体包则通过DPDK驱动进行传输，并对DPDK进行相应的裁剪，只需适应TCP、UDP、SCTP这些四层协议不同的封装要求即可。
同时也可以其他采用软件调优的思路，例如：
软件架构采用去中心化的设计思想，尽量避免全局共享，以减少全局竞争和失去横向扩展的能力；
在NUMA架构下不跨Node使用内存，以避免内存远程访问；
视频应用进程不在IO线程中承担过多任务，若无特殊要求更应避免任何形式的阻塞。
（2）增加中间链路的传输能力
随着5G的发展和成熟，以SDN/NFV、IPV6为特征的新一代网络已悄然落地，这为接入网、城域网和核心网传输能力的增加提供了契机，更为超高清视频的传输提供了扩容手段。
首先，IPV6的普及可以有效地减少NAT等传统IP扩容设备的部署，极大减少了在互联网环境下的传输瓶颈和限制。
再者，SDN（软件定义网络）隔离了传输的数据面和控制面，一方面解耦了软件与专用硬件的绑定，更重要的是交换设备本身不再承担找端口找路由等逻辑判断功能，极大地释放了交换设备的IO能力。SDN应用层可以对超高清视频的Qos业务进行定制化处理，采用交换机流表项的方式代替了原先通过MPLS实现的Qos业务，省略了包封装和解封装的开销，提高了传输效率。
最后，NFV（网络功能虚拟化）支持在通用平台上实现以虚拟化为载体的网络业务功能，进一步释放了通用计算平台的计算力。
对于超高清视频监控而言，算力问题就是编解码的效率问题。由于巨大的分辨率，即使采用H.265的压缩标准，其存储和网络开销亦是不可忽视的。但提高压缩标准必然带来编码端与解码端“编”和“解”的算力开销。在此我们重点讨论一下解码能力。
针对普通的解码端（包括解码器、PC端、移动端与机顶盒端等），在当前的配置下解码4K甚至8K超高清视频是非常吃力的，这主要由以下原因造成：
（1）超高清视频源本身压缩标准、码率、分辨率、帧率都非常高，由此带来了解码与时间同步等问题的压力也很大。
（2）大部分解码端性能都不是特别高，配置专门的高性能显卡非常昂贵。特别是移动端算力尚显单薄的情况下，高负荷的解码压力勉为其难。
（3）操作系统对于超高清视频解码后的渲染事务尚未担负起相应的责任，除了硬件上的优化，驱动软件特别是显卡驱动与显示框架的优化也非常重要。
鉴于以上原因，在处理超高清视频时，可以有针对性地对解码端进行性能加固。
配置高性能显卡是最直接最有效的手段。例如Nvidia的显卡对于解码与编码均具备最广泛的加速支持，GPU性能和并行计算能力也非常强悍。尤其是显卡本身的驱动较好地处理了显存与主存之间的IO交互，使得解码与渲染可以处于同一个渲染管线环境，更加速了超高清视频的处理速度。
基于专有厂家芯片的编解码加速支持也是一个非常好的选择，这种方案也是片上系统解码+渲染的方案。例如Intel针对其核芯显卡的QSV（高速图像同步转码技术）加速技术就是基于普通的被封装到CPU芯片中的HDGraphics系列核芯显卡的。这种方式可以在一定程度上提高超高清视频的解码处理能力。
对于操作系统显示驱动体系的软件改进是超高清视频渲染加速的有效手段。例如针对Windows最新的图形驱动模型WDDM（WindowsDisplayDriverModel）的渲染改进与加速，特别是针对DirectDraw基础库（主要用于播放视频）的硬件加速支持，也是一个不容忽视的方面。
现阶段支持软解码的主流开源库是FFMPEG，而FF对于编解码的硬件加速也有很好的支持。例如对于IntelQSV技术的支持已经融入到FF中（集成了Intel的MediaSDK）并体现出了良好的性能（解码时显存占用会稍大）。而FFmpegCUVID（基于CUDA的视频解码库）/NVECN/CUDA部分也分别集成了支持硬件加速的解码、编码以及部分CUDA加速的诸如Scaling这样的过滤器机制。
除此之外，还有若干种独立于平台的优化方案，包括：
OpenMax：这是由KhronosGroup制定的开放多媒体加速器，包括音频、视频和图像处理的全套API。使用时无需关注底层逻辑，减少了流媒体软件的设计流程，易于扩展，且完全免费。
Vulkan：这是由KhronosGroup制定的下一代开放的图形显示API，与OpenGL相比具有更简单的显示驱动层，同时支持跨平台特性、多线程特性和预编译的Shaders。
OpenCL：作为异构高性能计算的标准框架，OpenCL提供了基于任务和基于数据两种并行计算机制，不仅仅限于图形计算。不过FFMPEG仅仅优化了AVFilter（过滤框架）部分，主要用于硬件加速转码的场景下。
除了解码和渲染，还要考虑播放问题。例如4K超高清视频播放需要HDMI1.4a及以上的接口，HDMI1.4支持10.2Gbps的带宽，只够支持24fps、25fps、30fps的UHD4K的播放。因此未来要加快发展最大带宽达到18Gbps、可播放4K分辨率和3D视频的HDMI2.0标准。
安全问题并不是超高清视频监控领域独有的问题，所有信息技术领域均须重视各种安全问题。安全问题可分为以下几个领域：系统安全、数据安全、网络安全和应用安全。对于超高清视频监控我们需要关注以下内容。
面临服务器硬件、操作系统和监控终端的三重安全威胁。对于服务器系统，幽灵（Spectre）与熔断（Meltdown）作为处理器的巨大漏洞虽然已被修复，但是包括修复补丁在内还有多少处理器的0-Day漏洞尚未可知。操作系统的漏洞就更多了，2017年爆发的“永恒之蓝”系列漏洞直接被黑客利用开发出了Wannacry勒索病毒，可怕场景至今历历在目。而对于监控终端，其操作系统日益开源化、处理器平台日益通用化，这也为各种物联网设备、工控设备的Rootkit入侵提供了便利。
针对上述情况，除了要对操作系统进行安全加固外，还要针对监控终端的操作系统进行全流程控制。可以采用可信计算的思想对操作系统的启动进行安全度量。例如CPU芯片中植入可信计算基TCB，在系统启动的不同阶段进行层层嵌套式的安全度量。
1）BIOS以芯片中的TCB为标准进行度量；
2）BIOS可信后以上述度量结果为新的TCB度量主引导区MBR；
3）MBR可信后以上述度量结果为新的TCB度量活动分区OBR。
如此层层度量，虽然启动会略慢，但从一定程度上加固了服务器和终端的操作系统安全，是值得也是必要的。
GB35114作为视频监控领域数据安全的先行者和探路人，已经开始在行业内实践落地，并已开始构筑生态体系。对于超高清视频监控，符合GB35114规范的B级和C级标准必然意味着更大的加解密算力需求。特别是对于C级标准视频内容本身的加解密，其开销十分巨大。
基于此，要研究针对超高清视频本身的数据安全机制。对于加解密的算力需求，应将其“卸载”到专有芯片（例如ASIC）中实现。针对非对称型加密机制，亦可通过硬件+软件的方式共同实现。同时也可以采用约定的方式抽取若干视频帧进行加解密以降低算力开销。
在超高清视频监控系统中，要加强抵御DDOS攻击的能力和手段，增加数据摆渡和校验机制。特别是在超高清视频流量巨大的情况下，这对于数据摆渡设备是一个重大考验。除此之外，通过回声技术的摄像机的安全准入系统也应视情况部署和使用。
在视频监控领域也应重视应用软件本身的漏洞和防护。针对缓冲区溢出漏洞、数字溢出漏洞、恶意模块注入、SQL注入漏洞、Bypass漏洞等要有检测和防护的措施，以保证整个应用系统的稳定，不能让这些漏洞成为信息系统中病毒与APT（高级可持续威胁）传播的跳板。
作者：蒋立伟 谭喆 深圳力维智联技术有限公司
————————————————————————————————————————————
2019年第二十届中国国际建筑智能化峰会将于2019年10月30日至12月11日期间，分别在北京、上海、广州、深圳、杭州、武汉、成都、西安八大城市举行。本届峰会将聚焦“AIoT赋能建筑、人与空间”，届时将携手全球顶级智能化品牌，共同分享人工智能技术在城市、建筑与家庭中的最新应用，全面解读人工智能、物联网与智能化产业链的最新发展趋势。
报名参会或更多2019年峰会信息，详见峰会官网：
