网易云信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使用。

接下里介绍针对网络模块的优化。由于8K编解码的画质和码率都较高,很多传统针对1080P RTC码流的优化策略不再适用。

因此在拥塞控制方面我们采用自适应灵敏度来提升优质传输率;对于抗丢包优先使用ARQ,尽量减少使用FEC,防止恶性拥塞;在端到端时延的优化上采用高精度JitterBuffer控制,综合平衡抗性和时延。右图为优化效果的前后对比图,可以看到时延和卡顿率进一步降低,抗性和带宽利用率得到了提升。

接下来介绍针对VQC模块的优化策略。VQC是视频引擎的质量控制模块,用于平衡RTC系统视频的清晰度、流畅度和延时三个质量指标,提升视频QoE。三个指标由上图中视频编码、QoS和VQS的互相作用决定。

QoS会依据网络状况动态评估适合的码率,将其分配至VQC。VQC 会依据QoS 的反馈动态调整视频模块的编码码率,同时也可依据编码器的QP反馈和系统负载率动态调整编码分辨率/帧率。其中分辨率最低可降至640x360,8K以上分辨率的帧率最低可降至20fps。

接下来介绍关于Simulcast(大小流)的优化。考虑到网络状况和接收端的性能限制,服务端会同时发送一个大流和小流,接收端可以依据自身性能选择接收合适的视频流,服务端也可依据网络条件选择发送合适的流。我们针对小流的质量进行了优化,将小流分辨率从180p提升到360p,码率从120k提升到300k。

接下来展示云信RTC方案在客户侧的落地效果。我们与浙江一家三甲医院达成了合作,上图为院方进行MDT会诊的实景照片。可以看到,院方借助超高清RTC系统可以实现细致的远程病理切片分析。

上图展示了医院远程示教的实景效果,各地不同的医疗机构可以远程共同观看病理分析。除此之外还包括RTC方案还包括视频会议等应用场景。

上图展示了 8K 摄像头的实测采集传输数据,其中编码器采用Intel集成显卡H.265硬编码器,上行分辨率为8K。可以看到,视频实际的上行帧率为20fps左右,这基本满足医院病理分析等相对静态场景的需求。视频实际上行码率为10Mbps左右。

8K屏幕共享的实测结果与摄像头采集类似。

-04-

总结展望

接下来进行总结和展望。本次分享主要介绍了网易云信针对远程医疗提出的解决方案。8K RTC不仅是对分辨率的提升,也是对RTC视频管线的全面升级。我们在各方面进行了一些技术改进,介绍了落地过程中的技术挑战、解决方案以及最终实际的落地效果。

未来在技术优化方面,我们会进一步探索将摄像头/桌面采集的画面直接以Texture方式传输至硬编码器的方案。同时4K、8K RTC技术在云游戏、远程协作领域也有应用前景。

当前云信4K/8K RTC技术已成熟并在部分场景落地,我们将携手合作伙伴开拓更多极致高清的商业场景。我今天的分享就到这里,谢谢大家!


扫描图中 二维码 或点击" 阅读原文 "

直通LiveVideoStackCon 2023深圳站 9折购票通道

相关推荐
野蛮的大西瓜2 天前
BigBlueButton视频会议 vs 华为云会议的详细对比
人工智能·自动化·音视频·实时音视频·信息与通信·视频编解码
野蛮的大西瓜2 天前
文心一言对接FreeSWITCH实现大模型呼叫中心
人工智能·机器人·自动化·音视频·实时音视频·文心一言·信息与通信
野蛮的大西瓜2 天前
BigBlueButton视频会议 vs 钉钉视频会议系统的详细对比
人工智能·自然语言处理·自动化·音视频·实时音视频·信息与通信·视频编解码
Whappy0012 天前
《第十二部分》1.STM32之RTC实时时钟介绍---BKP实验
stm32·嵌入式硬件·实时音视频
嵌入式小强工作室5 天前
如何在STM32中使用RTC定时器
stm32·单片机·实时音视频
野蛮的大西瓜5 天前
BigBlueButton视频会议 vs 华为视频会议系统的详细对比
人工智能·机器人·自动化·音视频·实时音视频·信息与通信·视频编解码
m0_370565227 天前
stm32 rtc 详解
stm32·单片机·实时音视频
菊风 Juphoon8 天前
物联网养宠,实时音视频为宠物行业“加码”
物联网·实时音视频·宠物
陌夏微秋8 天前
STM32单片机芯片与内部24 RTC——内部实时时钟 简介 特性 框图 原理 UNIX
stm32·单片机·嵌入式硬件·硬件工程·实时音视频·信息与通信·智能硬件
陌夏微秋8 天前
STM32单片机芯片与内部25 RTC BKP——数据手册 寄存器介绍
stm32·单片机·嵌入式硬件·实时音视频·信息与通信·智能硬件