告别音视频卡顿、延迟、画面模糊，中关村科金推出音视频鸿蒙SDK
中国银联数据显示，当银行视频面签因卡顿、延迟导致业务中断、保险双录流程因画质模糊触发合规风险时，金融机构正在付出每年超12%的客户流失代价。
众所周知，鸿蒙生态在2024年迎来了历史性突破，其跨终端协同能力，为重构金融服务体验提供了新基建，银行、保险、证券和信托等机构正加快其业务系统的鸿蒙化适配进程，但传统音视频方案在弱网环境下，通话卡顿、延迟、画面模糊成为影响通信质量关键阻碍。
面对企业需求，中关村科金音视频中台依托全栈自研的ZRTC音视频能力底座，推出音视频鸿蒙SDK，针对鸿蒙系统进行全面适配和优化，在完美兼容鸿蒙系统的同时，基于鸿蒙系统深度优化的抗弱网传输引擎，将通话卡顿、延迟、画面模糊等情况出现的几率大幅度降低，保障流畅交互，破解弱网导致通信服务中断的困局。
中关村科金自研的ZRTC音视频能力底座主要通过NACK和FEC两种方式解决弱网丢包的问题。
NACK
NACK（Negative Acknowledgment）机制用于丢包重传，通过接收端定期统计并反馈丢失的RTP包给发送端进行重发。然而，这一过程引入了额外延迟，包括等待NACK发送、网络传输及重传时间（大约1.2倍往返时延加上10到20毫秒），这可能导致总延迟显著增加。例如，若往返时延(RTT)为200毫秒，则总延迟可达300毫秒以上，接近实时传输建议的最大值500毫秒。因此，NACK重传更适合于网络传输延迟较小的环境；在RTT较大时，依赖NACK重传来保证质量会使得整体延迟超出可接受范围。
FEC
FEC（Forward Error Correction）的作用通过添加冗余数据来防止丢包，其实现基于异或操作。如图所示，在传输Data1和Data2时，同时生成一个冗余数据R，它是通过对Data1和Data2进行逐位异或运算得到的。即使在传输过程中丢失了其中一个数据包，比如Data1，接收端也能利用剩余的数据包（Data2）和冗余数据R通过同样的异或操作找回丢失的Data1，而无需重新请求数据。这样，FEC确保了实时音视频通信的流畅性和稳定性，减少了因数据重传带来的延迟。
网络情况不良极易造成数据包抖动、乱序。抖动指的是数据包由于网络状况导致接收时的不均匀性，而乱序则是指数据包未按发送顺序到达。ZRTC利用JitterBuffer和NetEQ分别处理视频和音频包的抖动与乱序问题。
JitterBuffer和NetEQ
这两种机制通过缓存队列暂存接收到的数据包，并依据RTP包中的序列号确保数据包按发送顺序排列，比如图中104、107包已经到达，并且在对应的位置上，而103、105和106没来，位置就空着，等它们来了再插入对应的位置,这样就可以防止乱序,从而平滑输出数据流，有效解决了数据传输过程中遇到的抖动和乱序问题。所以，即使在网络状况不佳的情况下，也能保证音视频播放的连续性和同步性。
随着HarmonyOS NEXT正式开启，中关村科金将与广大客户及生态伙伴一同携手，积极参与鸿蒙生态建设，以创新、高效、安全、稳定的服务，助力客户各类业务系统在鸿蒙化应用和系统改造上迅速实现目标。
