CN117135148A - 一种基于WebRTC的音视频传输方法及系统 - Google Patents

Abstract

本申请提供一种基于WebRTC的音视频传输方法及系统，包括：建立WebRTC连接；在客户端或服务端通过JavaScript/WebAssembly实现基于WebRTC非可靠数据通道RTP传输；通过非可靠数据通道接收云游戏数据，并提交至音视频传输协议栈；在音视频传输协议栈中，将云游戏数据解码为原始的音视频流；将所述音视频流用音视频输出设备播放。本申请通过在客户端或服务端通过JavaScript/WebAssembly实现基于WebRTC非可靠数据通道RTP传输，非可靠通道具有错误纠正和恢复机制，同时可能会存在一定的数据丢失或延迟，但不会影响到主要的音视频传输，保证了实时、流畅的音视频通信。

Description

一种基于WebRTC的音视频传输方法及系统

技术领域

本申请涉及数据传输领域，尤其涉及一种基于WebRTC的音视频传输方法及系统。

背景技术

WebRTC是一种基于网络的音视频通信技术，可以让用户在使用浏览器时进行低延迟的音视频交流。这种技术可以应用于云游戏领域，让用户通过浏览器获得类似于游戏主机的游戏体验。

然而，当网络条件变差时，比如延迟高于50毫秒、丢包率高于5%，这种音视频通信的质量会受到明显影响。在这种情况下，游戏的体验可能会变得非常糟糕，导致用户无法正常进行游戏。因此，为了确保良好的游戏体验，应当保障网络连接的质量和稳定性。

发明内容

本申请的目的在于克服现有技术中存在的问题，提供一种基于WebRTC的音视频传输方法及系统。

本申请提供一种基于WebRTC的音视频传输方法，包括：

建立WebRTC连接；

在客户端或服务端通过JavaScript/WebAssembly实现基于WebRTC非可靠数据通道RTP传输；

通过所述非可靠数据通道接收云游戏数据，并提交至音视频传输协议栈；

在音视频传输协议栈中，将所述云游戏数据解码为原始的音视频流；

将所述音视频流用音视频输出设备播放。

可选地，所述通过所述非可靠数据通道接收云游戏数据，包括：

每一次传输的音视频数据包括前几次编码之后的音频数据。

可选地，所述云游戏数据，包括：

FEC包，解码时通过所述FEC包恢复丢失数据。

可选地，所述通过所述非可靠数据通道接收云游戏数据，包括：

将视频数据按照一定长度拆包成一组RTP数据包，使用所述非可靠数据通道传输到客户端或者服务端；

将接收到的视频数据包解包为完整的一帧视频数据。

可选地，还包括：

所述RTP数据包在发送/接收过程中出现丢包时，通过RTCP请求重发丢失数据。

本申请还提供一种基于WebRTC的音视频传输系统，包括：

连接模块，用于建立WebRTC连接；

创建模块，用于在客户端或服务端通过JavaScript/WebAssembly实现基于WebRTC非可靠数据通道RTP传输；

传输模块，用于通过所述非可靠数据通道接收云游戏数据，并提交至音视频传输协议栈；

解码模块，用于在音视频传输协议栈中，将所述云游戏数据解码为原始的音视频流；

播放模块，用于将所述音视频流用音视频输出设备播放。

可选地，所述传输模块通过所述非可靠数据通道接收云游戏数据，包括：

每一次传输的音视频数据包括前几次编码之后的音频数据。

可选地，所述云游戏数据，包括：

FEC包，解码时通过所述FEC包恢复丢失数据。

可选地，所述传输模块通过所述非可靠数据通道接收云游戏数据，包括：

将视频数据按照一定长度拆包成一组RTP数据包，使用所述非可靠数据通道传输到客户端或者服务端；

将接收到的视频数据包解包为完整的一帧视频数据。

可选地，还包括：

所述RTP数据包在发送/接收过程中出现丢包时，通过RTCP请求重发丢失数据。

本申请的优点和有益效果：

本申请提供一种基于WebRTC的音视频传输方法，包括：建立WebRTC连接；在客户端或服务端通过JavaScript/WebAssembly实现基于WebRTC非可靠数据通道RTP传输；通过所述非可靠数据通道接收云游戏数据，并提交至音视频传输协议栈；在音视频传输协议栈中，将所述云游戏数据解码为原始的音视频流；将所述音视频流用音视频输出设备播放。本申请通过在客户端或服务端通过JavaScript/WebAssembly实现基于WebRTC非可靠数据通道RTP传输，非可靠通道具有错误纠正和恢复机制，同时可能会存在一定的数据丢失或延迟，但不会影响到主要的音视频传输，保证了实时、流畅的音视频通信。

附图说明

图1是本申请中基于WebRTC的音视频传输示意图。

图2是本申请中WebRTC的系统框架图。

图3是本申请中音视频数据传输数据流程示意图。

图4是本申请中基于WebRTC的音视频传输系统示意图。

具体实施方式

下面结合附图和具体实施例对本申请作进一步说明，以使本领域的技术人员可以更好地理解本申请并能予以实施。

以下内容均是为了详细说明本申请要保护的技术方案所提供的具体实施过程的示例，但是本申请还可以采用不同于此的描述的其他方式实施，本领域技术人员可以在本申请构思的指引下，采用不同的技术手段实现本申请，因此本申请不受下面具体实施例的限制。

本申请提供一种基于WebRTC的音视频传输方法，包括：建立WebRTC连接；在客户端或服务端通过JavaScript/WebAssembly实现基于WebRTC非可靠数据通道RTP传输；通过所述非可靠数据通道接收云游戏数据，并提交至音视频传输协议栈；在音视频传输协议栈中，将所述云游戏数据解码为原始的音视频流；将所述音视频流用音视频输出设备播放。本申请通过在客户端或服务端通过JavaScript/WebAssembly实现基于WebRTC非可靠数据通道RTP传输，非可靠通道具有错误纠正和恢复机制，同时可能会存在一定的数据丢失或延迟，但不会影响到主要的音视频传输，保证了实时、流畅的音视频通信。

图1是本申请中基于WebRTC的音视频传输示意图。

请参照图1所示，所述基于WebRTC的音视频传输方法的步骤包括：

S101建立WebRTC连接。

创建PeerConnection对象（通话对象），然后获取本地媒体，将媒体添加到PeerConnection中。具体的，由客户端和服务端双方各自创建一个PeerConnection并交互信令以完成对接。

向STUN服务器发出请求，询问自己的公网IP。所述STUN（Session TraversalUtilities for NAT）服务器用于帮助客户端在因特网中寻找自身的公网IP地址。在WebRTC的建立过程中，STUN服务器可以被用于向客户端提供其公网IP的映射地址，有助于在因特网中进行点对点通信。

用PeerConnection对象Create offer，并将本地所支持的音视频信息分装成一个SDP信息，并发送到信令服务器。在WebRTC中，Create Offer是一种创建提供的过程，它用于建立点对点（Peer-to-Peer）的音视频通话。这个过程会生成一个包含各种音视频参数的offer，然后发送给对方，以与其进行协商。这个offer包含了用于建立连接所需的所有信息，例如媒体类型、端口号、编解码器等。

由信令服务器进行转发至回应点PeerB。在本申请中，PeerB是另一端的用户，即与PeerA进行音视频通话的另一方。

PeerB对这个SDP（会话描述协议）作出回应，同样封装成一个SDP消息回复，又信令服务器转发给PeerA。

PeerA封装一个ice candidate(IP，端口等信息)，通过信令服务器发送到PeerB。

PeerB通过询问STUN服务器，并封装自己的icecandidate信息，通过信令服务器发送给PeerA。

这样PeerA和PeerB就建立好了WebRTC的音视频流连接。

S102在客户端或服务端通过JavaScript/WebAssembly实现基于WebRTC非可靠数据通道RTP传输。

具体的，首先说明本申请WebRTC系统架构：

如图2所示，本申请涉及的一种新的WebRTC系统中，基于JavaScript/WebAssembly的本地通信引擎001是WebRTC系统中的核心组件，它负责管理数据流和媒体处理。在客户端方面，本地通信引擎001需要处理音视频编解码、数据流处理和网络传输等功能。同时，它还需要与信令服务器进行交互，以建立和管理通信连接。

在服务器端方面，本地通信引擎001需要提供数据流中转服务。当两个客户端之间的数据流传输经过服务器端时，服务器端的本地通信引擎001将负责接收并转发这些数据流。此外，服务器端的本地通信引擎001还需要处理安全连接和通信协议等问题。

基于上述的新的WebRTC系统，WebRTC提供了RTP（实时传输协议）用于传输音视频流数据，同时也支持非可靠数据通道（UDP）的传输。

下面是在客户端或服务端通过JavaScript/WebAssembly实现基于WebRTC的非可靠数据通道RTP传输的步骤：

首先需要创建一个RTCPeerConnection对象，它代表一个WebRTC连接。可以通过这个对象来创建、管理和关闭连接。

在RTCPeerConnection对象上创建并交换offer/answer SDP（会话描述协议）。这个过程涉及到创建offer或answer，设置本地和远程描述，并创建并发送ICE候选者。

在RTCPeerConnection对象上创建一个RTCDataChannel对象，该对象代表一个用于传输非可靠数据（如UDP）的通道。可以通过这个对象来发送和接收数据。

在RTCDataChannel对象上发送和接收数据。可以通过监听'message'事件来接收数据，通过调用send方法来发送数据。

当不再需要连接时，可以通过关闭RTCPeerConnection对象和RTCDataChannel对象来关闭连接。可以通过监听'close'事件来知道连接何时关闭。

S103通过所述非可靠数据通道接收云游戏数据，并提交至音视频传输协议栈。

将从数据通道接收到的云游戏数据提交给音视频传输协议栈进行处理。具体的提交方式取决于使用的音视频传输协议栈的实现。WebRTC框架中的音视频传输协议栈可以使用peerconnection.addTrack()方法来添加音视频流，然后通过peerconnection.createOffer()或peerconnection.createAnswer()方法创建并设置SDP消息，从而建立音视频通信。

进一步，每一次传输的音视频数据包括前几次编码之后的音频数据。

如图3所示，传输音视频数据流程包括：

S201对原始音频数据进行编码，将其转换为数字格式，以便于传输和存储。常用的音频编码格式包括MP3、AAC、OGG等。

S202在编码后的音频数据中，选择一定比例的数据作为冗余包。这些冗余包通常是前几次编码后的数据，可以用于后续的数据恢复。

S203将生成的冗余包与编码后的音频数据一起传输。

在接收端，检测是否有数据丢失或损坏。可以通过比较接收到的数据包与发送端发送的数据包数量和内容来完成。

如果检测到数据丢失或损坏，则使用冗余包来恢复丢失的数据。可以将冗余包与接收到的数据进行解码和合成，得到完整的音频编码后的数据。

最后，将恢复的音频编码后的数据解码为原始音频格式，然后进行播放。

进一步的，还进行音频前向纠错，具体步骤：

使用OPUS编码器对原始音频进行编码，生成编码后的音频数据。

在编码后的音频数据中，选择一定比例的数据作为前向纠错（FEC）包。这些FEC包通常包含一些冗余的编码数据，可以用于后续的数据恢复。

将生成的FEC包与编码后的音频数据一起传输。

在接收端，检测是否有数据丢失或损坏。这可以通过比较接收到的数据包与发送端发送的数据包数量和内容来完成。

如果检测到数据丢失或损坏，则使用FEC包来恢复丢失的数据。可以将FEC包与接收到的数据进行解码和合成，得到完整的音频编码后的数据。

最后，将恢复的音频编码后的数据解码为原始音频格式，然后进行播放。

其中，视频传输RTP packetizer (分包器)的具体步骤：

首先对原始视频数据进行编码，将其转换为数字格式，以便于传输和存储。常用的视频编码格式包括H.264、VP8、VP9等。

将编码后的视频数据按照一定长度拆包成一组RTP数据包。每个RTP数据包包含一部分视频数据，通常具有固定的字节数。

通过传输控制模块，使用非可靠数据通道将RTP数据包传输到服务端。在传输过程中。

视频传输RTP depacketizer (解包器)的具体步骤：

在接收端，接收到通过非可靠数据通道传输的RTP数据包。

将接收到的RTP数据包进行解包处理，将其合并为完整的一帧视频数据。这通常涉及到将多个RTP数据包中的数据按照正确的顺序进行组合和同步。

将解包后的视频数据进行解码，将其转换为原始的视频格式。

最后，将解码后的视频数据进行显示和播放。

进一步的，云游戏数据，包括：FEC包，解码时通过所述FEC包恢复丢失数据。

具体的，在编码后的音频数据中，选择一定比例的数据作为前向纠错（FEC）包。这些FEC包通常包含一些冗余的编码数据，可以用于后续的数据恢复。将生成的FEC包与编码后的音频数据一起传输。在传输过程中，可能会发生数据丢失或损坏的情况。在接收端，检测是否有数据丢失或损坏。这可以通过比较接收到的数据包与发送端发送的数据包数量和内容来完成。如果检测到数据丢失或损坏，则使用FEC包来恢复丢失的数据。可以将FEC包与接收到的数据进行解码和合成，得到完整的音频编码后的数据。最后，将恢复的音频编码后的数据解码为原始音频格式，然后进行播放。

进一步的，在音频编码器和解码器中选择适当的FEC算法和参数，以平衡数据冗余和计算复杂度之间的关系。

常见的FEC算法包括CRC校验、哈希函数、Reed-Solomon编码等。

在选择适当的FEC算法后，确定适当的冗余度。冗余度是指为了恢复丢失的数据而添加的额外数据的比例。

在选择了适当的FEC算法和冗余度后，优化计算复杂度。

所述优化计算复杂度，包括但不限于：

数据分片：将音频数据分片为较小的片段，可以降低单个数据包丢失对整体数据的影响。同时，使用FEC算法对每个数据片段进行冗余编码，可以降低计算复杂度。

并行处理：将音频数据和FEC编码的计算任务分配给多个处理单元或线程，并使用并行计算方法来加速处理过程。通过增加处理单元的数量，可以在给定的时间内完成更多的计算任务，从而降低计算复杂度。

硬件加速：利用专门的硬件设备（如FPGA、GPU等）来加速音频数据和FEC编码的计算过程。这些硬件设备通常被设计为执行特定的计算任务，具有比传统处理器更高的性能和计算能力，可以加速处理过程并降低计算复杂度。

近似算法：使用近似的算法来代替精确的算法。在某些情况下，精确算法的计算复杂度较高，而近似算法可以在牺牲一定精度的情况下降低计算复杂度。例如，可以使用低复杂度的哈希函数来近似Reed-Solomon编码的计算过程。

然后，在选择优化方式时，通过以下评价数学公式：

计算效率表示为：

Efficiency = T(A) / T(B)

其中，T(A)表示采用优化方式A的处理时间，T(B)表示采用优化方式B的处理时间。

空间复杂度表示为：

Space_Complexity = S(A) / S(B)

其中，S(A)表示采用优化方式A所需的存储空间，S(B)表示采用优化方式B所需的存储空间。

时间复杂度表示为：

Time_Complexity = T(A) / T(B)

其中，T(A)表示采用优化方式A的处理时间，T(B)表示采用优化方式B的处理时间。

综合考虑计算效率、空间复杂度和时间复杂度等因素，得出综合评价公式：

Evaluation = w1 * Efficiency + w2* Space_Complexity + w3 * Time_Complexity

其中，w1、w2和w3是权重系数，根据实际需求进行调整。

综合评价结果越高，表明优化方式越优。根据综合评价结果，动态选择最优的优化方式。

S104在音视频传输协议栈中，将所述云游戏数据解码为原始的音视频流。

在接收端，通过非可靠数据通道接收云游戏数据。包括音频编码数据、视频编码数据以及用于前向纠错的FEC包。

如果在传输过程中发生了数据丢失或损坏，可以使用FEC包来恢复丢失的数据。涉及到将FEC包与接收到的数据进行解码和合成，以得到完整的音频或视频编码后的数据。

对于音频数据，使用适当的解码器（例如OPUS解码器）将其解码为原始的音频流。对于视频数据，使用适当的解码器（例如H.264、VP8或VP9解码器）将其解码为原始的视频帧。

在解码后的音频流和视频帧之间进行同步处理，以确保它们的时间戳和播放速度保持一致。这可以通过使用适当的同步算法和缓冲机制来实现。

S105将所述音视频流用音视频输出设备播放。

将解码后的音频流和视频帧提供给播放器或显示设备，以进行实时播放或渲染。

如图4所示，本申请还提供一种基于WebRTC的音视频传输系统，包括：

连接模块301，用于建立WebRTC连接；

创建模块302，用于在客户端或服务端通过JavaScript/WebAssembly实现基于WebRTC非可靠数据通道RTP传输；

传输模块303，用于通过所述非可靠数据通道接收云游戏数据，并提交至音视频传输协议栈；

解码模块304，用于在音视频传输协议栈中，将所述云游戏数据解码为原始的音视频流；

播放模块305，用于将所述音视频流用音视频输出设备播放。

进一步的，所述传输模块通过所述非可靠数据通道接收云游戏数据，包括：

每一次传输的音视频数据包括前几次编码之后的音频数据。

进一步的，所述云游戏数据，包括：

FEC包，解码时通过所述FEC包恢复丢失数据。

进一步的，所述传输模块通过所述非可靠数据通道接收云游戏数据，包括：

将视频数据按照一定长度拆包成一组RTP数据包，使用所述非可靠数据通道传输到客户端或者服务端；

将接收到的视频数据包解包为完整的一帧视频数据。

进一步的，还包括：

所述RTP数据包在发送/接收过程中出现丢包时，通过RTCP请求重发丢失数据。

Claims (10)

1.一种基于WebRTC的音视频传输方法，其特征在于，包括：

建立WebRTC连接；

在客户端或服务端通过JavaScript/WebAssembly实现基于WebRTC非可靠数据通道RTP传输；

通过所述非可靠数据通道接收云游戏数据，并提交至音视频传输协议栈；

在音视频传输协议栈中，将所述云游戏数据解码为原始的音视频流；

将所述音视频流用音视频输出设备播放。

2.根据权利要求1所述基于WebRTC的音视频传输方法，其特征在于，通过所述非可靠数据通道接收云游戏数据，包括：

每一次传输的音视频数据包括前几次编码之后的音频数据。

3.根据权利要求1所述基于WebRTC的音视频传输方法，其特征在于，所述云游戏数据，包括：

FEC包，解码时通过所述FEC包恢复丢失数据。

4.根据权利要求1所述基于WebRTC的音视频传输方法，其特征在于，通过所述非可靠数据通道接收云游戏数据，包括：

将视频数据按照一定长度拆包成一组RTP数据包，使用所述非可靠数据通道传输到客户端或者服务端；

将接收到的视频数据包解包为完整的一帧视频数据。

5.根据权利要求4所述基于WebRTC的音视频传输方法，其特征在于，还包括：

所述RTP数据包在发送/接收过程中出现丢包时，通过RTCP请求重发丢失数据。

6.一种基于WebRTC的音视频传输系统，其特征在于，包括：

连接模块，用于建立WebRTC连接；

创建模块，用于在客户端或服务端通过JavaScript/WebAssembly实现基于WebRTC非可靠数据通道RTP传输；

传输模块，用于通过所述非可靠数据通道接收云游戏数据，并提交至音视频传输协议栈；

解码模块，用于在音视频传输协议栈中，将所述云游戏数据解码为原始的音视频流；

播放模块，用于将所述音视频流用音视频输出设备播放。

7.根据权利要求6所述基于WebRTC的音视频传输系统，其特征在于，所述传输模块通过所述非可靠数据通道接收云游戏数据，包括：

每一次传输的音视频数据包括前几次编码之后的音频数据。

8.根据权利要求6所述基于WebRTC的音视频传输系统，其特征在于，所述云游戏数据，包括：

FEC包，解码时通过所述FEC包恢复丢失数据。

9.根据权利要求6所述基于WebRTC的音视频传输系统，其特征在于，所述传输模块通过所述非可靠数据通道接收云游戏数据，包括：

将视频数据按照一定长度拆包成一组RTP数据包，使用所述非可靠数据通道传输到客户端或者服务端；

将接收到的视频数据包解包为完整的一帧视频数据。

10.根据权利要求9所述基于WebRTC的音视频传输系统，其特征在于，还包括：

所述RTP数据包在发送/接收过程中出现丢包时，通过RTCP请求重发丢失数据。