基于5G网络的视频远程操控应用实践——低延迟视频技术及应用

本次分享将分为三个部分：第一部分介绍低延迟视频所涉及到的关键技术，包括低延迟视频编解码、视频传输、视频处理低延时框架、视频采集和显示；第二部分重点介绍5G环境下低延迟视频对抗弱网提出的要求，包括：弱网状态的探测、拥塞控制等；最后一部分会结合实际测试结果，介绍在港口远控、远程驾驶等场景下的应用范例。

文/沈灿
整理/LiveVideoStack
原文/https://mp.weixin.qq.com/s/oLa96-mB3zQ3wJraAZNuhg

网络技术发展带来了延时低这一问题的讨论。以前网络的延迟比较高，芯片的处理都需要时间，所以延时一直都做得不够完美。随着技术的发展，芯片的处理能力提高和网络的发展，低延迟视频开始能够运用在一些比较特殊的场景，所以今天我想讲的主要内容包括：首先把“低延时”这一问题抛出来，然后介绍一下如何解决这些问题和相关技术，最后介绍低延迟视频的应用场景。

-01-

低延迟视频面对的问题

延时是做视频都会遇到的一个关键技术指标。平时面对面实时交流，一般200ms的延时就能达到满意的状态，因为人与人之间交流的反应速度没有这么快。但是人和机器交流或机器和机器间对接，对延迟的要求就会比较高，因为机器的反应速度远快于人。例如受操控的中等速度的工程车，通常100ms的延迟速度能够满足控制要求，较典型的例子是远程控制车上的机械臂。

另外，游戏也有比较高的延迟需求，最好是在100ms以下，最好能够做到50ms、60ms左右。因为游戏虽然是人在操控，但控制的是较为激烈的游戏场景，例如开车、开枪，可能延迟差一点点游戏就输了，因此延迟对于用户体验而言是很关键的。远程开车速度通常有60公里/小时，延迟如果在60ms左右，控制时就会有1米左右的误差。再如在高速公路上操控无人机，“智慧道路”要求在控制的同时告知操控人前方是否有事故或障碍物，因此延迟需要达到30ms左右才能满足用户的要求。

那么如何定义延迟呢？

从视频的产生、采集到显示（在云游戏场景下，即从视频产生的时候算起）产生的延时，即视频经过发送、网络传输、接收，一直到显示器，这整个环节就属于端到端的延时。中间段的延时也可以单独计算，例如从发送端到接收端，不计算头和尾的延时。这中间的很多环节都会产生延时，所以每个环节的延时都需要计算、都需要考虑指标能做到多少，这样才能把完整的延时定义出来。同时，还需要考虑内容的产生来源，例如内容是从某个云端产生，这其中的延时也需要计算。因此，技术指标是需要考虑到各个方面的。以上就是它的定义。

可以通过列表来估算每个环节会产生多大的延迟，哪些环节是容易产生延迟的。第一个环节是采样，如果是30帧/秒，其中会有33ms左右的间隔。这个（过程）本身也是有延迟的，因为采集有固定间隔，其固定间隔就是采样的延时。接下来是媒体的前处理，主要是ISP芯片带来的延迟，例如降噪、畸变校正等，其中的运算、数据传输都会产生延时，这部分就和它的处理能力有关，我们也可以对其进行估算。

然后是发送缓冲、网络传输、接收缓冲，这些也都需要时间，因为网络的带宽是有限的，如果带宽非常宽，则传输时间可以忽略不计。后面会详细介绍这其中会带来什么问题。这部分是延时产生的主要来源。

再之后是后处理，后处理和前处理相同，都属于媒体的处理，这部分的延迟比较固定，其数值不会波动太大。而中间的网络部分（的延迟）波动是比较大的，是随着网络条件、环境变化而变化的，也和丢不丢包有关。最终的显示，解码之后进入显示缓存和显示器，显示也是存在等待延迟的。综合上面的计算，根据目前系统的能力来看，如果不计算采样延时，（延时）大概在20到几百之间。

下面再逐个分析延时产生的原因到底是什么。一个是计算的开销，比如说在处理的时候计算很复杂，涉及到一些数值计算，比如做白平衡、降噪、去掉噪声、编码、解码，这些都是大计算量的，都需要时间，时间大概在几毫秒到几十毫秒不等。这部分属于计算的开销。

第二个（延迟产生的）来源是传输延迟。网络本身是有延迟的，不管是什么网络，光的传输都是需要时间的，路由器处理也需要时间，不管用什么方式（传输）都是需要时间的。视频的数据量比较大，大的视频帧有几百kbps到几M不等。传输是在有限的带宽上进行，假设是50M、100M左右的网络，传一个2M的视频，这是需要几毫秒时间的。通过后面的视频传输数据的波形图，可以看出视频的码流是不稳定的，即每帧的大小差异比较大，每帧在传输中需要的时间是不确定的，每帧到达目的地的时间不同，是不是固定的，这样不可预计到达时间。压缩前的视频数据达到1G左右的级别，即数据在编码前和解码后都有这么大的数据量，这在终端设备上显示和处理都是需要时间的。所以传输的延迟算是需要考虑的一个方面。

还有就是抗丢包。当网络质量比较差的时候，要应对网络抖动或网络丢包，就要用一个“代价”。通常情况下，要保证用户体验，要用的“代价”就是用延时来换。所以要增加延迟来抵抗（丢包），比如重传。这部分的延迟是可变动的，随着网络状态的变化而不断变化。再有就是任务调度之间的延迟。要把以上的步骤串起来，不同的模块之间、不同的任务之间需要安排好，像流水线一样。如果流水安排得不好，就会出现“等待”：数据还没来，我无法处理，需要等数据过来才能开始。这其中就有等待延迟。

再看到延迟、带宽和算力之间的关系。它们之间是三角形的、互相矛盾关系。如果要限制算力、节省算力，延迟可能就会上升。算力如果给得多，延迟或带宽就会占得比较少，它们之间是互相矛盾的关系。假如带宽给得非常高，给得十分充足，延迟肯定就会下降，因为花在传输路上的时间少了，而且如果带宽给得高，抗丢包也好做，需要的抗弱网的延迟比较少。所以它们之间是三角形的关系。延迟最终可以表达为与带宽、算力、视频质量相关的函数，视频质量高，要求的延迟、算力的消耗都会更多，会影响视频质量。算力高意味着成本高，带宽占得高也意味着成本高，所以需要寻找平衡。在什么样的质量下、在什么样的延迟要求下，用多少成本约束是合理的。也不是一定要选择最好的芯片，处理能力、配置强一些、带宽配置高一些，就一定是好的，它是一个均衡的关系，相互之间要达到平衡和优化。当然，视频质量和延迟也是互为矛盾的关系，如果视频质量要求高，码率就会高。

再看下视频码流的图。不同的线表示不同的条件，有的是游戏，有的是演讲、聊天。在不同的条件下的曲线是变化的，码流是不太有规则的，虽然长时间看，有一根平均线，但短时间看是忽上忽下的，这是因为视频的复杂度不一样，内容的复杂度和码流是有关系的。内容越复杂，或者摄像头剧烈晃动、距离变动，码流自然就会冲高，因为带宽（例如4M的带宽）是压不住的，是会上升的。因为编码要保证质量在一定范围内、保证它不太差，那么（码流）必然会冲高，因为信息量非常大。如果把码率压低，编码器最终输出的质量会很差，就会看到很多不清楚的、模糊的画面。内容的复杂度还包括帧内的内容。如果帧内的内容非常丰富，也会影响码流的输出。所以视频的码流波动是比较剧烈的。

还有一个影响码率的因素是视频的I帧、P帧的问题。关键帧的大小一般是P帧的5倍、10倍都有可能，这取决于内容的复杂度、帧内的复杂度。如果帧内复杂度很高，100k、200k都是很正常的，而P帧可能只有它的十分之一。因为它的波动比较剧烈，所以每帧在路上传输消耗的时间是不一样的，即使是网络很好的时候，到达、接收的时间也是不一样的，到达延迟是变化的。有的帧可能特别大，要把它拆成几百个报文，要等所有的报文都收到才算传输完毕，这路上花费的时间变化就会比较大。同时，码流变化会对网络产生一定的冲击，假设几个摄像头在同一个信道里传输，几个波峰都在一起，相互之间会挤，等待时间就会大幅度增加，就会出现更多不可预料的延时。这些问题都是需要考虑的。

显示也是有延迟的。视频解码后，到GPU渲染，再到操作系统显示。如图，是安卓上的显示过程，在其他系统上也是一样的，有显示服务，服务每隔一段时间会刷新一次的，如果要求数据”1”低延迟显示，就要在第一个间隔点前把它处理、渲染好，比如你需要叠加一个文字，就需要在这之前处理好，再到下一个时间段会把它刷新。除了图中的延迟外，还有显示器刷新的时间，显示器刷新的时间比较短，有的显示器仅有1毫秒。操作系统是软件控制的，这里的延迟和刷新率有关，例如刷新频率是100赫兹，就会有10毫秒的间隔。这是一个固定的延迟，它是操作系统和刷新间隔造成的。再看图中的“3”的图像，“3”跨越两个时间段，它的显示就会等待更长时间，它不会在前面还没有处理完就刷新显示器。所以显示的环节也是延迟比较大。

以上就是低延迟视频的问题，下面再看下如何解决这些问题。

我把它归纳为传输和信源（两部分）。传输主要是指低延迟传输，即如何实现（传输的）快速、稳定，能抵抗丢包。信源层包括摄像头前面的处理部分，到最终的显示，如果把这一系列问题都能解决好，解决延迟问题的目标就达成了。

并行视频的处理和编码。视频本身是采样过来的，是可以划分成条块的，前面这个示意图可以横过来划分，也可以四分划分。发送条块可以通过并行来计算，图像的并行化是解决延迟的主要手段。当然，并行化也会带来一些问题，并行是通过划分（进行的），计算的时候就可以把每块分别计算，进行处理，包括后面的编码也可以用同样的方法，这样就可以通过并行化把延迟降到原来的几分之一。当然，（为了实现并行化），每帧都单独处理而不做关联会造成一些问题，比如白平衡，有的处理算法要整帧先计算，或者后面做补偿计算。因为每帧的内部及每帧之间是有关联度的，包括编码，在计算时一旦分割进行全屏处理，从而实现并行化。

并行化有什么问题呢？一个是做了分块之后，Slice的压缩比也是受影响的，不仅有帧头开销，Slice之间的相互参考也会减少，就会带来压缩率的下降。还有就是视频解码时，要跨越条块边界就需要做滤波，所以解码的并行化不如编码的并行化好。所以一般是编码时做并行化，解码的并行化比较弱。然后是做图像处理时，不同条块之间有一致性的问题，比如光照强度，有区域的较暗，需要做统一的计算，才能知道别的块要怎么处理。

因此，如果把并行化做好，编码的时间、前处理的时间都可以减少很多。充分发挥计算的能力，通过并行化的手段使延迟下降。

还有就是动态调整关键帧的间隔，来减少码流波动。看上面这张图，关键帧如果同时出现，这两帧的延迟都受到影响。这时候瞬间出现一个比较大的波动，到达接收端时，就会出现这一帧在路上的时间特别长的情况，其他帧比较小。但是显示时为了保证流畅性，减少快慢播问题，就必须缓冲和等待。为了能够平滑地显示播放，不至于不断出现快放、慢放的情况，就会导致所有的帧都带来额外的延迟，慢慢才能通过动态缓冲把它补偿回来。这种情况是需避免的，以避免关键帧同时出现。

在延迟要求比较敏感的地方，关键帧尽量越少越好。因为关键帧越少，码流的平滑度越容易做，每帧在路上的时间不容易出现波动。当然，有的场景会要求固定间隔，比如几秒就要有一个关键帧。假如没有终端临时加入观看，是可以让间隔长一些的，这是有收益的，而且压缩比也更高。但是如果有的场景间隔要求短，就尽量避免它们同时出现。在同一个信道中间传输多路视频的时候，尽量把关键帧交错开，避免关键帧同时出现，减少I帧的碰撞。

在传输过程中间，已经编码完的数据立刻进行传输，尽量减少等待。有多少数据立刻传输，不用等这一帧全部编完，因为按照并行化编码，数据是可以先后出来的，这样就可以减少等待。这是传输的问题。

有的场景延迟是固定为主的，有的则是变化的，因为是和网络有关的，网络路上很多是不确定的，哪儿堵车了、哪儿出问题了，会带来很大的不确定性。一般抗丢包用的都是前向纠错或者重传，或者两者互相结合。如果是延迟很敏感的场景，可以先用FEC使丢包率下降，但它不能把丢包率完全消除，这取决于你的丢包模型。如果模型是很均匀的，用FEC是可以把它消除到几乎没有的；但通常前向纠错本身是无法把它完全消除的，但它能够使得你的丢包率下降，下降之后发生重传的概率就会相对低一些。重传的次数越多，在路上RTT的时间就会更长，就会出现卡顿，就会影响后面视频的接收和显示，缓冲区就会有很多数据在等。

而且前向纠错本身冗余率是非常高的，它会带来额外的带宽的浪费和消耗。但它是一种平衡，假如你舍得用带宽，延迟是可以下降的；如果你觉得带宽很值钱，不希望消耗太多，延迟可能就会增加一些，前向纠错可能就加得少或者不加，因为有时不一定会有收益。在丢包比较多、或丢包模型不符合一定条件时，不用FEC会划算，这是一种平衡。如果能够通过网络状态探测到，并且能够根据当前的丢包率、RTT的时间，能够动态调整，达到一个平衡就能知道什么场景下用什么方式是最划算的。

通讯引擎本身是能够满足各种条件的。例如延迟敏感条件，或者带宽和延迟要求平衡的条件，告诉引擎有这些偏好要求，就可以通过做一些策略调整来达到最终延迟和带宽消耗的平衡。

还有就是智能调速技术。接收方把每个报文的接收时间反馈回去，发送端就可以根据接收的时间和发送时间的差来估算网络状态，最终可以获得网络带宽、当前的丢包率、延迟等信息。网络如果感知到这些信息，码率就可以做动态调整。在移动网络中，码率和带宽是波动的，当被干扰、被遮挡或有天气变化等情况时，它的无线信号在一段时间内也会出现比较大比例的丢包或带宽的下降。无线信号的噪声上升了，整个网络的带宽就会下降，丢包率上升等情况都会出现。这时就需要对它进行动态监测，要估算网络现在到底怎么样、处于什么状态，要获得丢包率等参数，同时感知视频内容。

所谓的内容，是指内容的复杂度，复杂度可以表征为时间复杂度和空间复杂度。时间复杂度就是每帧之间的变化，比如运动是否剧烈。空间复杂度是帧内的画面复杂度。根据这些来动态估计码率的决策，可以使得码率更加合理，达到最优值，减少卡顿和延迟。

智能调速能够根据各种条件实时动态调整码率。调整码率不能太频繁，不能一秒钟内立刻就变了，那也是有问题的，它也得有一定的调整时间的限制。这个图可以看出，如果调整的时间合理，随着网络带宽的恢复，码率也能恢复。当然恢复是慢速恢复，下降则是快速下降。为了尽量消除卡顿，带宽必须快速下降，而上升则是慢慢上升。

还有一个问题是最短传输路径。如果端到端，在两个端上解决这个问题，其实还不是彻底地解决，因为在路上传输所消耗的时间和网络节点是从哪儿走有关。如果网络节点之间，能够把路况都探测到、获取到不同路径的延迟和带宽情况，就可以寻找到最小延迟路径来解决延迟这个问题，使得网络传输之间自主选路。再加上上面端到端之间的媒体抗弱网，在端到端之间、2个媒体节点之间做抗丢包，综合起来之后可以达到完整的方案。每个节点都做了优化，就可以解决好这个问题。

-03-

低延迟视频应用案例

最后说一下应用场景。

5G应用给产业带来了一些变革。之前许多控制都是靠有线的，例如网线、光纤。但是有了移动网络之后，一些需要运动的、不太容易布线的（东西、场景），移动网络就可以适用于这些新的应用场景，例如生产线、工业应用、自动驾驶、远程操控，或是一些较为危险的场景，例如地下矿车等。工业园区、港口、煤矿、医院、智慧社区这些都是未来潜在的应用可能。这也是移动网络带来的一个好处，即通信设备可以通过移动网络来解决问题。

这是我们中兴做的一个网关，上面带5G天线，里面可以接几个摄像头，也可以接工业、车载控制的口，接口丰富。可以接SDI的摄像头，这种摄像头延迟是比较低的。还有就是接入IP摄像头，它已经把视频编码和打包好了。最后工业设备的控制，通过远程控制台可以控制前面的设备。IP摄像头的延迟取决于摄像头编码和采集的延迟。因为上面有5G天线，所以可以实现远程控制。

还有一种是可以有一个网关，前面摄像头已采集的视频经过它做一次转码，转码之后再通过天线从基站过来，再把视频进行回传。这是我们的另外一个设备，它可以进行网关的转码或合成，画面也可以在里面合成，合成网关设备可以和前面的设备形成互补。

案例1是煤矿。左边是煤矿的机械，在井道里面，如果将网关放在车上，可以在机械上放几个摄像头，远程控制中心可以看到矿井内视频，就不用人在下面开车了，可以在地面的集控中心控制它。因为这个机械的延迟要求估计在100毫秒就够，它运动速度不快，就可以解决井下工人工作环境危险的问题。这是通过远程控制减少人工成本的比较有价值的应用。

无人集卡。这和前面的车差不多，但它可以带几个SDI或IP摄像头，然后通过车载完成控制。中间要建5G的基站，及核心网设备。里面有2个5G模组实现备份，提供抗弱网体验，支持onvif摄像头，及支持IP摄像头接入。到了本地之后它是可以走有线的。

这个场景是在港口上。港口上有龙门吊（之类的设备），每个吊车上可以放20、30个摄像头，人都是在操控室里控制的。这种场景要求人可以切换摄像头，传过来之后还需要做一些放大，这样才能使操作时司机控制得比较好。这种以前都是用有线来做的，用光纤或网线来做，因为环境比较恶劣，有一定的维护成本。如果换成无线的这种，相对而言维护成本会降低。可以提供50-80毫秒的延迟，无线网络上的这一段大概在10毫秒，可以解决在岸桥这一场景的远程控制。它的优势在于司机控制龙门吊时可以自由切换摄像头，智能化之后生产效率还是会有一定提高的。