网易云信4K 8K RTC助力远程医疗的技术实践

编者按：随着近年来国家关于缓解医疗资源分配不均的一系列政策出台，远程医疗作为平衡医疗资源分配的有力手段，目前正处于强劲发展阶段。网易云信运用超高清RTC视频技术助力医疗行业实现了远程高清视频病理分析和手术示教等能力。LiveVideoStackCon 2023 上海站邀请了来自网易云信的朱明亮，为大家分享网易云信关于4K、8K RTC助力远程医疗的技术实践。

文/朱明亮

整理/LiveVideoStack

大家好，我本次分享的主题是云信8K RTC助力远程医疗的技术实践。

首先向大家做一个自我介绍，本人来自网易云信，负责RTC SDK端视频引擎工程团队，主攻的业务方向是视频管线的需求实现和性能优化。历经点播、直播到现在的RTC，我在音视频领域已有十余年工作经验，目前在云信致力于4K、8K RTC技术的研发。

本次分享将分为以下四部分，一是介绍业务背景，二是我们的远程医疗方案，三是8K RTC实践，最后进行总结展望。

-01-

背景介绍

下面将从三个方面介绍我们的业务背景。

首先是医疗资源现状，我国的医疗资源目前高度紧缺且分布极度不均，主要体现为：近85%的资源集中在大中城市的少数二、三甲医院；全国医疗结构的近95%为基层卫生机构，而基层高水平医疗人员数量较少，取得正高/副高资格的医生占比仅为 5.1%。

为了解决资源不均的问题，国家目前正大力推行建立分级医疗和远程医疗体系。

提到远程医疗，可能大家首先想到的形式是医生通过网络远程操纵机器人完成手术，不过现状与之相比还有一定差距。当下远程医疗更多作为线下实体医院的功能延伸，如通过网络实现患者预约、就医挂号和病例查询等功能。至近期已逐步发展到“互联网+医疗”模式，患者可以利用网络进行图文、视频直播问诊并开单拿药。

我们认为远程医疗未来的发展趋势是实现高清视频问诊，包括多学科会诊（MDT）、手术高清视频示教和视频会议等。今天主要将介绍我们在这方面进行的实践。

我们再来了解8K的概念，与当前RTC常用的FHD 1080P和影院、音视频点播成熟化应用的4K分辨率相比，8K超高清分辨率达到了4K的4倍，1080P的16倍。它包括更丰富、更细腻的画面细节，传达的信息量是人眼可识别范围的4.3倍，即使对画面的个别位置进行放大也几乎不会出现细节损失，这更有利于远程医疗病理分析和远程传输等方面的应用。

-02-

远程医疗方案

接下来介绍我们现阶段在远程医疗方面应用的一些方案。上图为网易云信互联网医院的架构图，左侧为传统互联网医院就医的闭环流程。中间为本次主要介绍的基于云信RTC SDK打造的智慧协同医疗教学功能模块，它包含远程病理、远程SDT会诊、远程培训和会议等能力。

对于症状轻微的普通疾病通过左侧闭环流程即可完成就医，而对于在基层医疗机构难以决策的疑难杂症、危重疾病、手术等，则可通过智慧协同功能模块与其他医院、其他科室的专家进行会诊。

云信RTC的SDK架构如上所示，它的分层较为清晰。首先最底层为基础层，在此之上为核心的媒体引擎层，包括视频引擎、音频引擎和传输引擎模块。接着是跨平台封装层，该层会抽象一些跨平台API，包括信令传输等模块，我们在该层还会构建一些通用的音视频逻辑，如视频主辅流双通道分流、主流Simulcast机制等。再上一层为SDK接口层，针对各个平台不同的Native language进行API封装，并提供给客户进行集成。顶层为我们推出的云信易用体系，可以提供 Sample Code、行业解决方案Demo和通用组件，便于客户进行集成。

云信RTC SDK的视频引擎Pipeline如上所示。顶部为网络传输模块，左侧为视频上行流程，历经视频源采集、前处理至编码、上传，支持主辅流双路通道。VQC模块会通过QoS评估网络带宽动态调整编码器参数。

右侧为视频下行流程，支持N路下行，可满足多人视频会议等场景的需求。

接下来具体介绍视频引擎的上行Pipeline，其中左侧的视频采集模块支持桌面采集、摄像头采集和第三方输入等方式，输入的视频经过前处理将分为两路，一路经过叠加水印、打码等额外处理后进行本地渲染以供预览。另一路将经过额外处理传输至编码器。VQC模块会根据网络条件动态调整视频分辨率、码率、帧率等编码参数，提高观看体验。

-03-

8K RTC实践

下面将从以上几方面介绍我们关于8K RTC的技术实践。

我们的8K RTC系统在选定的一般硬件平台落地。CPU是Intel 11 代i5，显卡是集成显卡 iRIS Xe Graphics，系统是 Windows11，显示设备为8K显示屏，使用8K 摄像头进行采集。

8K RTC 对视频引擎Pipeline的优化点主要集中在屏幕共享、摄像头采集、前处理、编码和VQC五大方面。

首先介绍8K摄像头采集方案。由于USB3.0摄像头存在450 MB/s的传输速率上限，而8K原始YUV 420P码流每帧的数据量达到了47 M字节，照此估算视频帧率只能达到7～8fps，流畅度显然不能满足要求。目前我们采用的方案为从8K摄像头采集8K H.265或MJPEG压缩码流，视频规格为20Mbps@20fps。

从摄像头采集的数据在解码后将按照正常的上行Pipeline处理,下行端解码器会接收8K H.265码流进行解码。1V1 会议场景下，主播端会同时存在两路 8K 解码、一路 8K 编码，这对系统造成的压力较大。

我们对上述问题进行了优化，改为向网络端直接发送摄像头采集的码流，此时摄像头既是视频源又是编码器，避免了反复编解码。但这对摄像头的硬件要求较高，需摄像头具备稳高质量的编码能力，并要保证摄像头编码器能够接收VQC模块的指令，调整编码参数。

因此我们使用Dshow在采集模块中加入了摄像头指令控制模块，基于Windows UVC Driver增加了可查询Control接口的Extension Unit，使采集模块能通过Extension Unit动态调整编码参数。同时我们还增加了IDR请求能力，使中途加入会议的用户能够快速接收I帧，显示画面。

针对8K桌面采集我们目前采用高效率的DXGI方案，在指定硬件平台可实现8K 30fps视频采集，其他流程与基本的视频引擎Pipeline一致。

接下来介绍我们针对8K桌面采集的优化。DXGI是微软推出的基于硬件驱动层的图形操作接口，可以支持不同图形库间的互操作。右侧为大致的采集流程，在创建D3DDevice后，利用IDXGIOutputDuplication接口的AcquireNextFrame函数获取屏幕画面，将Texture转为RGBA数据，再使用Libyuv 把 RGBA 转为 I420，并将其发送至编码器。

我们对红框圈出的两个环节进行了优化，第一是在调用AcquireNextFrame函数时注意延时参数控制，避免因时延过低导致出现大量重复帧，或是时延过高导致画面帧数不足。

第二是在RGBA数据转换时，由于8K RGBA数据量很大，直接将RGBA数据复制到前处理线程耗费的时间过长，因此我们进行了多线程优化，后续又发现使用Libyuv 直接将 RGBA 转到 I420 所需的时间更短，便改为采用这种方式。

接下来介绍视频编解码方面的优化，首先对于落地的硬件平台而言，8K软编软解是不可能的，需要考虑硬编硬解。其次在质量方面，H.264已经不能胜任4K/8K视频的编码，因此编码器改为使用H.265。最后是延时，由于8K编码对系统性能和延时的压力很大，因此要尽可能优化前处理流程，去掉不必要的环节，从而降低延时。

接下来介绍关于Windows端硬编硬解的优化，我们的SDK支持Nvidia、Intel和AMD三大厂商的硬件平台，最下层为基于不同平台抽象的硬编解码器，在此之上为BitrateAdjuster和BitstreamAdapter，用于动态平滑码率发送和过滤码率中额外的NALU。在引擎层会抽象不同的硬编解码器供SDK使用。