京东智联云在RTC方面所做的工作

本文由京东智联云的魏伟在LiveVideoStackCon2020线上峰会的演讲内容整理而成，他会从逻辑结构、系统业务流程和弱网增强等方面介绍京东智联云在RTC方面所做的工作。

1. 简介    1.1 视频形态 

  视频形态可归为非实时视频（点播视频）和准实时视频（直播视频）。从本质上来看，任何一个视频系统的完成都是由采集、编码、连接和播放这一完整的端到端流程组成，不管是点播、直播还是RTC的视频，它们底层的视频算法都是基于H.264/H.265等编码协议，并基于一些网络封装协议，包括一些基础的传输网络来实现视频的连接，而且视频的采集和播放都使用相同的技术框架。虽然视频的形态非常多，应用场景有直播带货、娱乐视频、监控视频、会议视频等各种各样的视频形态，其本质都是建立在视频的采集、编码、连接、传输这些基础的逻辑之上。   但发展到RTC阶段之后，我个人理解是时间和空间的转化，设定在一个几乎没有延迟的条件下，完成一个视频的采集、编码、传输和播放，并且不限制视频形态和视频应用场景的变化，其底层的视频编解码技术，包括承载视频的传输网络都是一样的。   京东智联云在过去两年内推出了很多的视频底层技术方面的一些成果，也推出了视频点播和直播的一些产品，包括在视频压缩方面的一些黑科技和在CDN上的建设和储备。  1.2 JRTC系统画像 

  到达RTC阶段，我们理解的RTC系统画像并不是一个独立的RTC系统，我们希望建立的RTC系统不仅仅服务于视频会议、娱乐视频的视频连麦，除了最基本的实时音视频通信之外，还能支持多种协议的接入、异构系统之间的互通以及实现不同业务之间的接入和资源共享。在点播、直播以及监控系统之上构建一个融合的RTC平台，实现业务、资源和技术的融合。我们希望能用一套系统，把包括点播、直播、监控等系统在内的资源、内容和设备进行统一管理，并且在这一整套技术架构之上能实现资源的共用、系统的统一调度，还能提供更好的服务形态以及更低的使用成本。同时利用CDN节点提升边缘的接入能力，使用户能够就近接入，降低延时，并且充分利用闲置资源来降低系统服务成本。   所以京东智联云RTC是建立在现有视频点播、直播和媒体处理系统之上的一个综合的融合性平台。该平台可以实现视频点播、直播、通信和媒体处理等多种业务形态的融合，也能共用一些现已投入使用的基础视频处理资源。视频编解码技术、网络传输技术、资源调度使用技术都可以在该平台上进行综合管理和使用，最终达到易用、好用、低价的产品进行交互。  1.3 内容融合与统一交换 

  在我们构建的RTC平台之上可以支持基础RTC的接入，但其中有一些私有化的信令或基于Websocket连接，数据分发传输可以支持基于TCP或UDP协议，也支持直播、点播系统，常见的有RTMP协议、HLS协议或者基于HTTP、 TCP传输的视频协议。其次，还有一些视频会议的系统，其中间有支持SIP或者323的协议接入。监控终端支持的主流协议是GB-28181。   我们会搭建一个统一的媒体协议的网关系统，在统一的网关系统下将视频从多种多样的封装协议或者网络协议中抽离出来。抽取底层视频格式的网络和信令层，得到底层储存的H.264或者AAC的音视频流，其中可以调用媒体处理的能力对这些媒体进行处理，再通过媒体传输网关在不同的系统之间进行对应系统的网络封装或者信令的控制，最终达到在不同的异构系统之间实现媒体内容的融合或者媒体内容的统一交换。

2. JRTC介绍    2.1 JRTC逻辑结构 

  上图展示了JRTC系统的逻辑结构，包括最底层的云资源，当然现在谈到云资源一定会提到边缘计算资源。在云资源上部有多种SDK，包括移动端和H5端等，而且SDK不仅有通信的能力，同时也有一些业务属性。接入层接入JRTC客户端、直播流、SIP、监控等终端，提供信令、媒体、混流服务。包括网络链路选择、传输效率提升以及纠错容错能力都是在分发层实现。控制和平台对接层更多是实现不同业务之间的连接。顶部是SaaS应用，包括视频会议、直播连麦等不同应用的使用场景。  2.2 JRTC组网图 

  融合JRTC系统采用分布式、分层架构，利用数十万个边缘可控节点提供服务。图中左边是能力增强部分，它融合基础网络能力、CDN分发能力、媒体处理能力、MCU、多码率的对齐和处理、压缩和转码、SVC等能力都在媒体处理集训里完成。AI能力平台提供采集端的美颜和滤镜、播放端的超分、平台端的内容审核、AI结构化处理等能力。   图右边是内容交换部分，包括视频监控平台、直播系统、视频会议系统。不管是技术能力还是异构系统都会在RTC平台通过接入网关融合在一起，再由统一的媒体处理和AI能力进行处理，最后再对外暴露出是面向娱乐视频、教育视频、会议视频场景等各种低延迟场景下的具体应用。  2.3 JRTC开放SDK集 

  JRTC开放SDK集可以提供基础通信能力、业务应用能力两个层面的SDK。   JRTC Client  Core SDK，即核心SDK，它提供音视频通信、消息通信、媒体处理控制等基础能力。此外，我们面向不同的业务应用场景提供不同的SDK，包括视频会议、直播连麦、视频客服、低延时直播等SDK。   用户基于实际情况，可选择业务应用SDK或视音频基础通信能力SDK，满足快速集成和深度定制的不同需求。提供满足PC、移动、专业设备系统运行的SDK版本，主要包括Android、iOS、WIN、 H5、MAC、Electron平台。  2.4 RTC系统业务流程 

  上图介绍了RTC系统的系统业务流程。首先，用户、监控摄像头、SIP终端首先定位到接入服务器，并建立连接，登记到控制层。当用户发布流到接入服务器，接入服务器同步流信息到控制层。其次，订阅流用户向控制层查询流信息，通过中转Relay服务，将流从源服务器调度到接入服务器并订阅。用户由接入服务器向媒体处理发起混流请求，混流服务通过Relay拉取多条源流经过混合后，推送到直播系统。最后，用户向直播系统发起拉直播流操作，经过拉流网关协议转换后，将流返送到RTC系统。监控等其他系统，通过控制层交换内容列表，通过Relay交换媒体。   整个运作模式就是发布和订阅模式，在和其他系统应用时也能以比较低的延时实现在直播系统和其他异构系统之间的交互。  2.5 基于优选路径中转调度 

  这部分是关于路径选择的简单描述。左图中，静态路由有运营商匹配、区域临近匹配、跨网搭桥处理。其次是基于探测的动态监测，每一个节点会探测与其临近的或者需要连接的一些点的网络联通性。整个路径选择会基于实时探测的故障点检查、包括拥堵检查，以最优路径的方式建立一个端到端的连接。   右图中可以看到有海量的节点需要通信，同时也有海量的节点作为网络隧道的承载点来帮助建立更可靠的连接。基于静态路由和动态检测的方式可以从海量的节点中（包括边缘点）来选择一些比较优秀的节点以构建一个优选的路径发布。该优选的路径分发网络，在新加入的节点需要建立通信的时候可以承载网络隧道和穿透的能力。   上部是路径决策，历史通信记录、路由分析、IP的判决结果都会在最上层的路径决策系统里，结合历史实时通信结果、静态路由配置情况和实时探测的情况，形成优选的实时传输网络。  2.6 多路径并行传输 

  在传统设备中用得比较多是是多路径并行传输，但在真正的RTC系统中反而用的就较少。因为现在在很多的移动终端会有同时连接WiFi和4/5G信号的情况，包括手机支持双4G信号的连接。这种情况下我们就可利用双链路的双路径并行传输来提升传输效率和传输的可靠性。比如手机上有电信和联通两张卡，如果同时使用电信和联通两个卡去发送和接收数据，就会有更好的带宽和网络保证。   如何将数据在两个网络之间进行调配以及如何在两个链路之间进行动态的冗余都有比较大的挑战。我们有一个比较简单的方式是先把所有的网卡列举出来并激活，再进行处理数据和执行并行的数据传输。单链路会有主链路来传输音视频数据，并调用辅助链路处理音频数据，以此来提升音频的可靠性。在RTC环境里，如果视频产生一些丢包但能保证音频的话，这对通信质量也会有比较好的保障。  2.7 弱网增强 

  弱网增强采用视音频编解码、传输控制、纠错算法不同手段综合实现。在视音频编辑码方面有SVC|Simulcast、码率自适应和AI超分。在RTC或数据通信的场景下，经常会发生网络带宽的波动情况，这时候就需要动态地调整音视频编解码的实时码率，如果这时的音视频编解码实时码率能够和实时传输带宽达到最佳匹配的话，一方面可以最充分的利用网络带宽，另一方面也可以保证最佳的视频效果（即不会产生卡顿也不会降低视频质量）。但这是比较有挑战性的，因为网络传输和视频编码是两个非常独立的模块，如何将这两个模块结合在一起联动工作，首先要让音视频的Codec能够支持动态地调整码率、分辨率、帧率等一些基础逻辑，这样才有可能通过实时网络探测的方式将实时网络情况传送给音视频的Codec，再实现音视频码率和带宽的自适应，不浪费网络带宽并且提升视频质量。   AI超分是在播放端实现的，这项技术在RTC场景下显得尤为重要，因为RTC场景很多时候是在跨网或者跨地域的连接下使用的，不像现在的点播、直播系统可以通过CDN加速，通过网络连接提升和保障视频的下载速度。大部分RTC都是基于点对点的连接，而且两点之间有可能跨越了非常复杂的网络情况，这直接导致在大部分的RTC情况下，音视频的带宽都比较低，此时想要做到1080p的传输是比较艰难的，并且很容易因为丢包造成卡顿的情况。AI超分在其中一个很重要的作用是可以在整个RTC链路上以一个较低的分辨率、码率进行通信，在终端播放时通过超分的方式增强视频的主观观看效果。如果提供1.2M的RTC网络通信能力（ RTC的场景以静态居多），做1080p的数据传输是有一定风险的。1.2M做1080p传输的图像质量不会太高，但在这种情况下结合AI超分，就可以在RTC链路上只跑一个540P 1M的视频流，再在终端通过超分把它提升到1080p，这样就可以以一个比较稳定且比较低的带宽占用，实现比较好的最终使用效果。   传输控制方面有多源汇聚、多链路并传、缓存自适应、带宽估算、平滑发送。纠错算法方面有FEC前向纠错、主/被动重传、错峰多副本、自适应纠错策略。  2.8 编解码 

  在编解码部分我将介绍一些基础的视频能力，它们都会在MCU中使用。其中端上也会有去噪、锐化、AI增强、动态编码、ROI编码。ROI编码会增强画面中的人脸部分，并弱化画面中的非人脸部分，在比较小的网络带宽环境下提供更好的主观效果。   在极速转码方面有解码复用、随源快转、源流水印、倍速转码。 终端超分方面有实时超分、2×超分、渲染处理、细节增强。 多码率切换方面有帧对齐、无缝切换、直播切换。 舒适音频方面有降噪、齐量、均衡、舒适。 质量检测方面有文件合规性、黑屏、静帧、花屏、静音。   以上是我们在视频方面对RTC进行的一些工作。  2.9 移动端增强超分 

  上图的右半部分是移动端增强超分的流程图，在视频解码之后会得到YUV图像，并将它在低分辨率的情况下进行亮度的增强、超分增强、色度增强、色度上采样增强等处理，以及高分辨率的一些重建工作。整个过程在实际的测试效果中，虽然大家都怀疑从540P到1080P超分的效果是不是不太好，但实际上1M 540P的主观感受基本上可以接近2.5M 1080P的效果。   我们也针对移动端上功耗的问题进行了很多优化，主要是用GPU加速的方式来实现超分的卷积框架。相比于屏幕显示的功耗，超分算法的功耗是比较低的。  2.10 边缘节点管理 

  因为RTC需要就近的连接才能提供更低的延时和更多的路由选择，但不管是公有云机房还是CDN等地方，我们都有一些RTC能力的部署。上图左部分列举的一个简单对比，CDN节点的量级一般在千级别，可用性也比较高，全国各省都会分布几个机房点。但实际上最终要接入网络的设备数可能是亿级别的量级，设备接入并通过网络进行数据通信。我们将边缘计算层定义成Edge层，这一层是百万级别的设备，但这些设备没有CDN节点那么高的可靠性，处理能力也不如CDN节点里部署的服务器那么强，但它就是利用边缘闲置的一些计算资源来提供一些分布式的计算和连接能力。因为部署在边缘的这些计算资源也具备计算、存储和网络通信的能力，虽然每一个点的绝对计算能力都不是非常的强，但它可以在低延时通信领域里作为一个数据流转发或者提供比较小的数据存储和连接能力。从整体上来说，未来的网络一定是从“云-管-端”的架构发展到“云-管-边-端”，在云的边缘会有一层百万量级的边缘设备作为边缘计算节点来对外提供服务。   这些节点一方面跟核心控制平台有连接，它有自我升级和管理的能力，通过平台的控制逻辑下发指令，这些节点就可以进行自我管理和自我净化。   自我管理包括自身计算能力的分配、自有存储空间的管理等。因为这些节点有网络能力之后，可以探测自身的一些网络连接状况，管理热点文件，并根据自身的存储空间进行整个全生命周期的管理。而且，每个节点都是一个自制的节点，来完成自己存储空间、临近节点路由和网络连通性的管理，并将自身情况数据上报给平台管理层，平台管理层可以结合每一个节点的自制能力进行全局的管理。每个节点也可以实现按照平台逻辑做数据防护和加密，整个“云-管-边-端”架构也是京东云RTC基础运行的物理存在环境。