编者按： 随着自动驾驶技术和 5G 行业应用的发展，5G 远程实时操控类应用逐渐兴起，用于满足高危行业 / 恶劣场景远程作业、自动驾驶异常情况下远程介入等需求。相比直播、会议等传统实时音视频场景，由于操控的复杂性和车辆的移动性，远程实时操控对音视频传输的时延和可靠性提出了更高的要求。

本次分享将介绍 5G 远程实时操控行业应用场景对音视频传输的要求，以及腾讯云音视频针对 5G 远程实时操控场景的音视频传输优化和应用落地实践。

文 / 毛峻岭

整理 / LiveVideoStack

我是来自腾讯的毛峻岭，今天很高兴能够给大家分享低延时实时音视频在 5G 远程操控场景的应用实践。说到 5G 远程操控，可能大家有些陌生，它是近两年刚刚兴起的一个实时音视频应用。

1、远程实时操控应用介绍

首先，给大家介绍一下远程实时操控的应用。

什么是远程实时操控应用呢？我们给了一个简单的定义：突破空间限制，借助网络和音视频能力实现人对物的远距离操控，以接近现场操作的体验。从这个定义我们可以看到远程实时操控中交互的媒介主要是网络，交互的目标效果主要是接近现场操作的体验，而交互的主要价值就是突破空间限制，来解放人与物交互的空间距离。相比原有的传统远程控制来讲，远程实时操控主要在下面三个方面进行了增强。第一个主要是信息更具象，在远程实时操控中除了传统的传感器信息之外往往会有多路视频，这些多个视角的视频会全方位在远端具象呈现以让操控者达到一个身临其境的体验。第二个是操控更逼真，为了提高操控效率，在远程实时操控中往往会采用跟原有设备相似的操控设备，比如汽车会用模拟方向盘，挖机会用对应操纵的机械杆以提高操纵者的效率。最后也是比较重要的一点是远程实时操控中为了保持操作流畅性，它的交互需要更实时，远端操作与现场反馈的画面要达到无缝衔接，使操纵流畅。

下面我想跟大家介绍一下近两年为什么远程实时操控会兴起，主要离不开两个技术方向的驱动。第一个是 5G：5G 技术本身可以改善网络的上行带宽以及网络时延，为远程实时操控的场景提供了重要的网络基础。另外这两年来国家 5G 政策也在推进数字化产业的快速升级，像在 2020 年，工信部、网信办、发改委等十部门推出了《5G 应用 “扬帆” 行动计划（2021-2023 年）》，其中提到了涉及港口、矿山、工厂等多个 5G 行业远程应用场景，以实现现场的无人化、少人化作业，从本地作业向远程作业方式进行改善。第二个是自动驾驶技术的成熟。其实自动驾驶经过几年发展后，目前在一些场景中逐步开始尝试进入无人化的阶段，通过去除车上的本地安全员来实现无人驾驶的商业价值。但是无人驾驶中仍然存在一些意外情况需要解决。去年国际（SAE）和国内（GB）自动驾驶分级标准中，均引入远程介入方式，定义远程驾驶员来解决远程驾驶意外情况下的接管，应对 L3/L4 阶段自动驾驶意外情况下的介入问题，完成了从原有本地安全员到远端安全员的转变。

下面，主要介绍下远程实时操控有哪些应用场景，我们大概分为了三大类场景。第一类场景是自动驾驶的应急接管，在这类场景中主要是通过远端的远程监管员去接管意外的自动驾驶情况，以实现一个远端安全员同时看管多辆无人设备，提高效率。目前比较成熟的场景主要是矿山的无人矿卡和港口的无人集卡，现已进入实际落地运营阶段。另外，园区物流和乘用车场景也在做无人化的远控探索。第二类场景是高危和恶劣环境作业，也是国家比较支持的方向，可以将原有作业人员从艰苦的作业环境中解放出来，在空调房里作业已不再是梦想。目前主要有这几类应用场景：一个是矿山的钻机和井下的掘进机需要远程化作业；另外在港口也存在一些高空作业的环境，像场桥和轮胎吊；还有在钢铁车间中温度较高，这时也尽量做到少人化，除此之外在应急的自然灾害中可以通过远程挖掘机和无人机去做相应的处理，减少人员的危险。第三类场景是线上到线下的服务和体验，传统的实时音视频更多是人与人之间的线上交互，但远程操控为线上到线下的交互带来了全新的可能，这也是比较适合万众创新的一个方向。线上到线下的互动主要分为两个方面，一个是线上的人力向线下服务，比如出行场景的云代驾泊车、地产建图场景的扫图机器人、医疗场景的远程 B 超都可以让线上的医生和工作人员在远端对现场进行服务。第二个方面是线上的客户以便捷化的方式体验线下的资源，比如无人机云旅游场景，在家就可以获得实际的旅游体验，观赏相应的景观。还有云赛车的场景，可以在远端线上体验专门赛场内的赛车服务。

下面可能是一个大家比较关心的话题，远程实时操控的视频指标到底是什么？其实远程实时操控对实时音视频的挑战是比较大的，我们从目前在制定的一个 5G 远程驾驶行标中摘录了三个比较重要的指标。第一个是画面延迟，指的是相机的捕捉画面到远端显示画面的延迟，它包含了相机的采集延迟、视频传输以及显示器的显示三部分。远程实时操控的画面延迟指标，标准中定义的是 150 毫秒到 200 毫秒，但实际中更期望的指标是在 100 毫秒到 150 毫秒范围中。在远程操控中往往需要使用车规或者更高规格的相机设备，而这类设备的时延远高于手机或者 USB 相机的时延。像车规的相机延迟典型值是在 70 毫秒到 100 毫秒之内，这意味着留给视频编码解码传输还有显示的延迟时间不到 100 毫秒。第二个是卡顿率，这也是一个要求非常高的指标，因为在远控的场景中很多物体是移动的，在移动的画面中更易感受到卡顿，标准定义的卡顿帧间隔是 100 毫秒到 150 毫秒，而传统的音视频定义卡顿的界限是 200 毫秒。卡顿率的要求也提高了 10 倍，传统音视频卡顿率指标可能是 1%，而远控标准将值改为了 0.1%，当然这是正常情况下的数值，如果出现了极端弱网，这还是很难达到的。第三个是抗弱网指标，远程实时操控对抗弱网要求没那么高，这主要考虑到了现实网络场景，一般远控的网络相对来说比较好，标准定义是 20% 丢包和 50 毫秒网络抖动，这样的指标下能达到 1% 的卡顿率。

2、腾讯远控 RTC 产品介绍

下面主要是介绍下腾讯在远控 RTC 产品方面的一些经验。

首先是产品架构。从这个架构来说，它与传统的实时音视频架构类似，也是分为推流的网关端、观看拉流的操控端以及服务侧，服务侧也是传统的三大件（信令服务器、媒体服务器、存储服务器）。稍微有点区别的是因为 5G 远控安全性的要求，在信令服务器上需要增加对设备的认证更健全的安全性保护。另外，从部署的场景上来看，在媒体服务器和存储服务器上需要做一些轻量化的提高场景的伸缩性以及跨区域的部署能力。在端侧，大概分为了几部分与传统音视频的不同。第一个是 5G 远控场景比较多，有点对点直连的，也有服务器中转的场景，所以它可能需要支持多模式的视频推流。第二个是在远控中对状态和控制信令的传输的要求非常高，不仅需要低时延而且需要持续的传输，所以在控制信道上也需要做相应的增强。第三点是一些操作平台上的变化，因为远控不同于传统实际音视频的场景，它主要是一些 Linux 的物联设备还有 windows 的操控端，在这样的情形下它支持的平台也会发生变化。

下面，介绍一下腾讯远控产品的特性和指标。第一个是低时延，非常重要的指标之一。我们做到了端到端的画面时延，本地 100 毫秒左右，省内 150 毫秒左右，全国 200 毫秒，并可提供逐帧视频时延测量，帮助客户在高延时的情况下做一些回退的策略。第二个是安全可控，因为远程操控对安全性的要求是非常高的，在传统音视频流内容加密传输的基础上，我们增加了设备接入认证和视频权限管理帮助客户更好地提供安全加护。第三个是抗弱网，在做到极致的低延时同时也保留了与现在实时音视频相当的抗弱网的能力，可以抵抗 30% 丢包和 50 毫秒以上网络波动，并且对于一些港口或者矿山的网络覆盖存在一些盲区，在这种情况下我们也提供了小于 1 秒的网络中断的快速恢复能力。第四个是全网络场景支持，在远程操控中存在公网的场景，乘用车、无人出租车这样的公网场景，也有专网的场景，像矿山和港口，还有一些混合网络的场景，因此我们提供了一个自动快速选择路径的功能，可以自动找到最近的接入路由做相应的接入来降低端到端的时延。

接下来，分享两个腾讯远控产品的应用案例。一个是港口，一个是矿山，在这两个案例中我们都做到了在本地 5G 专网下画面时延降低至 120 毫秒左右，这是基于车规相机来做的，也就是说真正的视频传输可能是在 50 毫秒左右。左边港口的案例中亮点是支撑了无人化行驶监控和远程驾驶，帮助客户实现了一个实际的无人化运营。右边矿山的案例主要亮点是我们在广州和武汉展会上展示了远程操控位于鄂尔多斯的矿车，从武汉到鄂尔多斯的操控距离是 1000 多公里，而广州到鄂尔多斯是 2000 多公里，在这样的距离尺度下，实现了持续驾驶，画面时延小于 200 毫秒。

3、腾讯远控 RTC 技术分享

那么，大家可能会关心腾讯远控产品背后有哪些新的技术点。

这里，我们简单分享几个技术点。第一个是拥塞控制技术，在低时延预算下，视频传输需要更好的拥塞控制算法，一旦网络发生拥塞，可以尽量降低码率，避免拥塞发生，减少丢包的重传以及因拥塞导致的时延的上升。我们在传统的拥塞算法上加上了 5G 空口拥塞感知环节，包括基于空口 Buffer 的测量， IECN 拥塞反馈字段扫描以及信号质量和 MCS 做了一个发送码率的预估，以减少网络拥塞的发生。

远控视频有个特点是多路视频传输，像我们做的案例中大部分最少会有 4 路视频的传输，在一些特殊的机械中会有 6-8 路的视频传输，而更多的视频传输在发生拥塞时可以有适当取舍，一般我们需要保证主画面的清晰度，而对于非主要视角的清晰度可以做一些额外的下降。基于这样的情况，我们做了一个联合拥塞控制，整个网络的发送速率是共享的，在拥塞控制算法中得到相应输出的发送速率基于权重去分配到对应视频流上。通过这种方式就可以灵活取舍多路视频传输的质量。

第二个是抗弱网技术，在低时延传输中也是非常重要的。首先讲的是重传技术方面。重传是目前最有效抵抗丢包的技术之一，但是重传在高 RTT 下会增加解码 ready 时间的波动，带来接收端累计时延变长，从而引起整个端到端画面时延的增加。为了减少重传带来的时延波动，我们做了跨帧编码流的算法，编码流类似于 SVC，做了两层的分片，后一个 P 帧会参考前面再前面一个 P 帧，形成跨帧参考。这时发生丢包有几个好处，第一个是前一帧丢包时，当前帧无需等待重传进行解码，这有效解决了重传带来的时延波动问题。另外，就是在发生严重丢包时，可以整体舍弃其中一个分片的重传和传输，使用一半帧率传输视频，减少了传输带宽，缓解了拥塞发生。

抗弱网除了刚提到的重传，还有一个比较重要的技术就是 FEC。多路视频给 FEC 的交织提供了更多的维度，在多路视频情况下，我们为了减少突发丢包的影响，对发送的多路视频流做了发送的交织，这样对于突发连续丢包会分散在每一路单独的视频上，通过每一路自己的 FEC 编码完成修复。另外，为了平衡冗余度和纠错能力的关系，还可以在发送上叠加外 FEC，这里增加的冗余包是多路视频可以共享的。

降低视频时延其实最直接有效方式就是改善网络，选择时延更低的网络进行传输。在 5G 网络中的远控场景，大部分 case 中设备端和操作端是在同城或是同一个园区。而这样的同城和本地场景下，视频的链路可以有多种选择，比如通过直连的 P2P 方式去做链接，第二个是通过边缘的媒体服务器方式去做边缘的转发，第三个是传统方式那样通过云端转发，而云端转发方式的网络链路时延往往会比较大。为了支持灵活的转发链路，我们在端侧做了多模支持，P2P + 边缘分流 + 远端转发三种形式，提供智能调度选择。

下面是我们时延实际测试数据，这里的测试相机是 1080P 30fps GMSLⅡ 车载相机，它的时延大概在 70 毫秒左右，我们在 WIFI 局域网场景下，网络 RTT 大约在 1-3 毫秒左右，整个画面时延约 90 + 毫秒。第二个是在 5G 同城网络下做的测试，网络 RTT 大约在 30 毫秒左右，画面延时上升到约 120 毫秒。

下面是另一款相机，型号是 USB3.0 720P 工业相机，这款相机的整体时延是远小于前面的车载网络相机的，它的相机时延大概在 20 毫秒左右。我们在 WIFI 局域网场景下做到了画面时延约 40 + 毫秒，这是一个非常低的时延。像大疆的一些无人机在这样清晰度情况下也是很难做到 50 毫秒以内的延迟。右边是在 5G 同城网络下做的测试，网络 RTT 大约在 30 毫秒左右，画面延时做到了 70 毫秒这样的水平。

我的分享就到这里，感谢大家。