一、引言：数字人技术的崛起与音嘴同步的挑战

在数字人技术的快速发展中，音嘴同步（Lip Sync）技术已经能够生成高度逼真的虚拟角色视频，使得数字人的表现力达到了前所未有的水平。然而，生成高质量的音嘴同步视频只是第一步，如何将这些视频实时推送到用户端，并确保流畅、低延迟的播放，成为了另一个关键挑战。

过去，WebSocket + mainSource 方案是实时视频推送的主流选择。它通过持久化的连接将生成的音嘴同步视频从服务器推送到客户端，并在前端播放器中展示。然而，随着用户对实时性和流畅性要求的提升，这一方案的局限性逐渐暴露——延迟高、带宽效率低、同步难度大等问题，严重影响了用户体验。于是，WebRTC（Web Real-Time Communication）技术成为了更高效、更稳定的替代方案。WebRTC 专为音视频通信设计，能够实现低延迟、高带宽利用率的实时视频传输，尤其适合推送生成好的音嘴同步视频。它通过内建的音视频同步机制和自动带宽管理，显著提升了视频推送的质量和稳定性。

本文将深入探讨从 WebSocket + mainSource 到 WebRTC 的技术转变，揭示这一升级如何为数字人系统的实时视频推送带来质的飞跃，并分析其在实际应用中的优势与价值。

二、WebSocket + mainSource 方案的辉煌与局限

2.1 WebSocket + mainSource 的工作原理

在早期的实时音视频传输中，WebSocket + mainSource 方案是当之无愧的“主力军”。它的工作原理简单而直接：

  • WebSocket：作为一种全双工通信协议，WebSocket 在客户端和服务器之间建立了一条持久化的连接，使得数据可以实时双向传输。这种持久化连接避免了传统 HTTP 请求的频繁建立和关闭，显著提高了数据传输的效率。

  • mainSource：这是前端接收的音视频数据流，通过 WebSocket 从服务器传输到客户端，并在播放器中实时展示。mainSource 的核心作用是将音视频数据流整合并传递给前端，确保用户能够实时看到和听到数字人的表现。

2.2 局限性：当技术遇到瓶颈

尽管 WebSocket + mainSource 方案在早期表现出色，但随着数字人技术的快速发展，它的局限性逐渐显现：

  1. 延迟问题：WebSocket 并非为音视频流设计，缺乏专门的编解码和带宽控制机制。在高频率的音视频数据传输中，延迟和丢包问题频发，导致音视频不同步。例如，在虚拟主播的场景中，用户可能会明显感觉到声音和嘴型的不一致，从而影响观看体验。

  2. 带宽效率低：音视频流对带宽要求极高，而 WebSocket 并未针对带宽优化，容易造成网络拥堵，导致视频卡顿或数据丢失。尤其是在高分辨率视频传输时，带宽的消耗会显著增加，进一步加剧了这一问题。

  3. 同步难度大：音频和视频帧通常是分开传输的，开发者需要手动实现同步逻辑，这不仅复杂，还容易出错。例如，开发者需要精确控制音频和视频帧的时间戳，以确保它们在播放时能够对齐。这种额外的开发工作不仅增加了项目的复杂性，还可能导致潜在的同步问题。

  4. 网络适应性差：在复杂网络环境（如 NAT、防火墙）下，WebSocket 缺乏有效的穿透机制，导致连接不稳定。例如，在企业内网或公共 Wi-Fi 环境下，WebSocket 可能无法建立稳定的连接，从而影响音视频流的传输。

在实际应用中，这些问题在高频率视频流传输时尤为明显，尤其是在网络条件不佳的情况下，用户体验大打折扣。

三、WebRTC 的崛起——实时音视频传输的新标杆

3.1 为什么选择 WebRTC？

随着音视频实时生成技术的发展，WebRTC（Web Real-Time Communication）凭借其专为音视频通信设计的特性，逐渐取代了 WebSocket + mainSource 方案。以下是 WebRTC 的几大核心优势：

  1. 低延迟与实时性：WebRTC 内建了编解码、带宽自适应和流控制等优化机制，能够将音视频传输的延迟降到最低，非常适合实时互动场景。例如，在实时互动中，WebRTC 能够确保音视频数据的实时传输，提供流畅的用户体验。

  2. 自动带宽管理：WebRTC 能够根据网络状况动态调整音视频质量。例如，在网络较差时，它会自动降低视频分辨率，优先保证音频传输的流畅性。这种自适应机制不仅提高了带宽的利用效率，还确保了音视频流的稳定性。

  3. 内建音视频同步：WebRTC 通过时间戳机制自动处理音视频同步问题，无需开发者手动实现，大大降低了开发复杂度。例如，在数字人场景中，WebRTC 能够自动对齐音频和视频帧，确保音嘴同步的精确性。

  4. 强大的网络适应性：WebRTC 支持 STUN 和 TURN 服务器，能够轻松穿透 NAT 和防火墙，在各种网络环境下保持稳定连接。例如，在企业内网或公共 Wi-Fi 环境下，WebRTC 能够通过 STUN 服务器获取设备的公网 IP 地址，并通过 TURN 服务器实现中继传输，确保音视频流的稳定传输。

3.2 WebRTC 的架构

WebRTC整体架构从上到下一共分为三层：

  • 最上层是WbeAPI层，这一层是暴露给开发人员的用于开发WebRTC应用的JavaScript API

  • 中间的那一层是WebRTC技术最为关键核心的一层，一共包括三个模块，分别是音频引擎、视频引擎以及网络传输

  • 最下层是由各厂商自主开发的一层，用于实现音视频的采集和网络IO

音频引擎（VoiceEngine） 负责WebRTC的音频通信，通过一套完整的音频处理框架，解决了音频从外接设备如麦克风读入数据然后再通过网络进行传输的音频处理问题。主要分为两个模块：音频编解码和语音信号处理。其核心是回声消除（AcousticEchoCancceler，AEC）和降噪（NoiseReduction，NR）。回声消除是一种改善声音质量，消除产生的回声或防止其发生的方法。降噪是从信号中去除噪声的过程。音频机制主要分为iSAC和iLBC两大类编解码器。iLBC编解码器该窄带音频编解码器适用于IP上的语音通信。

视频引擎（VideoEngine） 负责WebRTC的视频通信，通过一套完整的视频处理框架，解决了视频从外接设备如摄像头采集数据然后再通过网络传输最后显示视频的视频处理问题。主要分为两个模块：视频图像编解码和视频图像处理。视频图像编解码方面，默认的编解码器是VP8，比较适合实时通信场景下的视频编解码。视频图像处理方面，通过两种方式来保证传输的视频图像的高质量、美观性，一方面，利用视频抖动缓冲器来减小由于抖动和丢包带来的影响，另一方面对采集到的图像进行颜色增强、降噪等处理来提升图像清晰度。

网络传输（Transport） 负责音视频数据的传输，通过一套完整的传输框架，解决了音视频数据的加密传输和防火墙穿透问题。一方面，通过SRTP协议保证音视频数据在加密的状态下进行传输，另一方面，通过整合了STUN和TURN的ICE协议来保证音视频数据可以突破防火墙和NAT网络的限制。

3.3 WebRTC 的关键概念

1. RTCPeerConnection（点对点连接）

RTCPeerConnection 用于建立点对点的实时通信连接。它允许在不同浏览器之间传输音频、视频和数据流。我们把发起 WebRTC 通信的两端被称为对等端，即是 Peer。所谓点对点通信（peer-to-peer）则是说两个客户端直连，发送数据不需要中间服务器，建立成功的连接则称为PeerConnection，而一次 WebRTC 通信可包含多个 PeerConnection。

2. ICE（Interactive Connectivity Establishment，交互式连通性建立）

ICE 不是一种协议，整合了 STUN 和 TURN 两种协议的框架，用于 NAT 和防火墙穿越。ICE通过收集并交换候选者（Candidate）信息，包括IP地址、端口号、协议等，并按优先级尝试连接。

3. STUN（Session Traversal Utilities for NAT，会话穿越实用程序）

STUN 协议用于获取设备的公共 IP 地址和端口。它帮助客户端了解自己的公共网络地址，以便在 NAT 环境中能够正确地进行通信。STUN 主要用于发现和共享 IP 地址和端口信息，并不用于数据转发。

4. TURN（Traversal Using Relays around NAT，NAT 中继穿越）

TURN 协议用于当直接连接不可用时，通过中继服务器转发数据。TURN 服务器充当一个中继角色，将数据从一个对等端转发到另一个对等端。TURN 适用于复杂的 NAT 环境，确保即使在所有直接连接方式都不可用时，依然能够传输数据。

5. Stream（流）

一个 MediaStream 对象表示一组相关的音频、视频或者其他媒体轨道的集合。例如，在一个视频通话中，可能存在一个 MediaStream 包含了音频轨道和视频轨道。

6. Track（轨道）

一个 MediaStreamTrack 表示音频、视频或其他类型的轨道，是 MediaStream 中的基本单元。每个 MediaStream 可以包含一个或多个 MediaStreamTrack。音频轨道包含音频源，视频轨道包含视频源。

7. Channel（通道）

在 WebRTC 中，channel 通常指的是 RTP（Real-time Transport Protocol）通道，用于实时传输音视频数据。每个 MediaStreamTrack 可以使用独立的 RTP 通道进行传输。

8. Source（源）

在 WebRTC 中，MediaStreamTrack 对象通常被称为 “track”，而一个 MediaStreamTrack 的数据源就是 “source”。MediaStreamTrack 可以是音频轨道（AudioTrack）或视频轨道（VideoTrack），它们分别表示音频或视频的输入源。

9. Sink（接收端）

在 WebRTC 中，sink 通常是指用于接收媒体流的端点（local/remote音视频渲染）。在 MediaStream 流的消费端，我们可以使用 MediaStreamTrack 对象创建 MediaStreamTrack 的 sink ，用于接收来自源（Source）的媒体流。

3.4 WebRTC 的连接建立流程

1.发送 SDP Offer:

  • 当一个 WebRTC 对等端（比如 Peer A）想要发起通信时，它会生成一个 SDP Offer，这个 Offer 包含了有关媒体会话的详细信息，如媒体类型、编解码器、网络参数等。

  • Peer A 将这个 SDP Offer 发送到信令服务器，信令服务器再将其转发给另一个对等端（比如 Peer B）。

2.接收 SDP Offer 并发送 SDP Answer:

  • Peer B 接收到 SDP Offer 后，会解析其中的内容，并生成一个 SDP Answer，其中包含 Peer B 对会话的响应信息。

  • Peer B 将 SDP Answer 发送回信令服务器，信令服务器将其转发回 Peer A。

3.ICE Candidate Discovery:

  • 在 SDP Offer 和 SDP Answer 交换之后，每个对等端开始生成 ICE Candidates。ICE Candidates 包括可能的网络路径，用于穿越 NAT 和防火墙。

  • 每个对等端会将其 ICE Candidates 通过信令服务器发送给对方。

  • 信令服务器将对等端的 ICE Candidates 转发给另一端的对等端。

4.测试和建立连接:

  • 一旦双方对 ICE Candidates 进行交换，各个对等端会进行连接性检查，测试这些候选者的有效性。

  • 根据测试结果，双方选择最佳的候选者对，建立实际的点对点连接。

  • 成功建立连接后，媒体流（如音频、视频）可以通过这个连接进行传输。

四、从 WebSocket 到 WebRTC 的切换——技术升级的实践

4.1 前端实现：建立 WebRTC 连接

在前端，我们通过 WebSocket 与后端建立信令通道，接收 WebRTC 的 offer、answer 和 ICE candidate 信息，并通过 RTCPeerConnection 建立点对点连接。视频流通过 MediaStream 组件进行播放，确保音视频同步。在数字人场景中，前端通过 RTCPeerConnection 接收 MuseTalk 生成的音嘴同步视频流，并将其展示在播放器中，确保用户能够实时看到虚拟角色的嘴型与音频的高度匹配。这种低延迟的连接机制，使得数字人的表现更加自然，用户交互体验显著提升。

4.2 后端实现：视频流的合并与传输

在后端，我们通过 WebSocket 接收前端请求，生成 WebRTC 的 offer 并发送给前端。同时，利用 VideoStreamMerger 组件将多个视频流合并，并通过 RTCPeerConnection 将合并后的视频流传输到前端。在数字人场景中，后端可以将不同摄像头捕捉的视频流或预先合成的音嘴同步视频流进行合并，并通过 WebRTC 传输到前端。这种合并与传输机制不仅提高了视频流的处理效率，还确保了多路视频的同步播放，为复杂的数字人场景提供了技术支持。

4.3 视频流管理：动态加载与连续播放

为了确保视频流的连续播放，后端会动态加载指定文件夹下的视频文件。当一个视频播放结束后，系统会自动加载并播放下一个视频文件，整个过程无需人工干预。在数字人场景中，这种动态加载机制特别适用于需要连续播放多段视频的场景，例如虚拟客服或教育助手。后端可以动态加载预先录制的回答视频或教学内容，并通过 WebRTC 实时传输到前端，确保用户能够连续观看虚拟角色的表现，提升交互的流畅性和自然度。

五、技术升级带来的实际收益

  1. 更低的延迟：WebRTC 的内建优化机制确保了音视频数据的实时传输，显著降低了延迟。在数字人场景中，低延迟的传输机制使得虚拟角色的嘴型与音频能够精确同步，避免了用户感知到的时间差，从而提供了更加逼真的互动体验。

  2. 更高的带宽效率：WebRTC 能够根据网络状况动态调整音视频质量，避免了带宽浪费和网络拥堵。在数字人场景中，这一特性确保了即使在网络条件不佳的情况下，虚拟角色的视频流仍能保持流畅播放，提升了用户体验的稳定性。

  3. 自动音视频同步：WebRTC 的内建同步机制消除了音视频不同步的问题，无需开发者手动实现复杂的同步逻辑。在数字人场景中，这种自动同步机制确保了虚拟角色的嘴型与音频帧的精确对齐，显著提升了音嘴同步的精度和自然度。

  4. 更强的网络适应性：WebRTC 支持 STUN 和 TURN 服务器，能够轻松穿透 NAT 和防火墙，在各种网络环境下保持稳定连接。在数字人场景中，这一特性确保了虚拟角色的视频流能够在企业内网、公共 Wi-Fi 等复杂网络环境下稳定传输，扩大了数字人技术的应用范围。

六、结语：技术驱动体验升级

从 WebSocket + mainSource 到 WebRTC 的转变，是数字人技术发展中的一个重要里程碑。这一技术升级不仅解决了音视频传输中的关键问题，还为数字人系统的未来发展奠定了坚实基础。技术的进步永无止境，而我们的目标始终不变——为用户提供更自然、更沉浸的数字人体验。未来，随着 5G、AI 和边缘计算等技术的进一步发展，数字人技术将在更多领域实现突破，为用户带来更加丰富的互动体验。我们期待通过持续的技术创新，推动数字人技术走向新的高度。