CN114900507A - Rtc音频数据的处理方法、装置、设备以及存储介质 - Google Patents

Abstract

本申请提供一种RTC音频数据的处理方法、装置设备以及存储介质。该方法包括：客户端通过第一线程，接收并解码服务端发送的RTC音频数据流得到目标音频数据流，并播放该目标音频数据流。缩短了媒体数据流播放的首帧时间，进而提升了客户端的启播速度。而不需要通过多个线程来对音频数据流进行数据处理，避免不同线程之间通过消息队列进行音频数据的搬运，提高了客户端的数据处理效率。

Description

RTC音频数据的处理方法、装置、设备以及存储介质

技术领域

本申请涉及网络技术领域，尤其涉及一种RTC音频数据的处理方法、装置、设备以及存储介质。

背景技术

在实时通信(Real-Time Communication，RTC)的音频数据传输场景中，云服务端向客户端发送下行的数据流时，由于数据流中的数据的采样率不固定，客户端基于网页即时通信(Web Real-Time Communication，WebRTC)技术，需要利用多个线程串行完成音频数据的接收、解码等操作，以使不同的线程通过在消息队列中搬运数据，来保持数据流中数据的时序。而在一些下行数据流中的数据时序稳定、或者下行数据流的时序不敏感的场景中，基于目前的WebRTC技术进行音频数据的数据处理，将导致客户端的数据处理效率较低。

发明内容

本申请实施例提供一种RTC音频数据的处理方法、装置、设备以及存储介质，以期提高客户端的数据处理效率。

第一方面，本申请实施例提供一种RTC音频数据的处理方法，包括：通过第一线程，接收并解码服务端发送的RTC音频数据流得到目标音频数据流；播放该目标音频数据流。

第二方面，本申请实施例提供一种RTC音频处理装置，包括：处理单元，用于通过第一线程，接收并解码服务端发送的RTC音频数据流得到目标音频数据流；播放单元，用于播放该目标音频数据流。

第三方面，本申请实施例提供一种电子设备，包括：至少一个处理器和存储器；该存储器存储计算机执行指令；该至少一个处理器执行该存储器存储的计算机执行指令，使得该至少一个处理器执行如第一方面提供的方法。

第四方面，本申请实施例提供一种计算机可读存储介质，该计算机可读存储介质中存储有计算机执行指令，当处理器执行该计算机执行指令时，实现如第一方面提供的方法。

第五方面，本申请实施例提供一种计算机程序产品，包括计算机指令，该计算机指令被处理器执行时实现第一方面提供的方法。

在本申请实施例中，客户端通过第一线程即可接收服务端发送的RTC音频数据流，并解码RTC音频数据流，得到最终可播放的目标数据流，而不需要通过多个线程来对音频数据流进行数据处理，避免不同线程之间通过消息队列进行音频数据的搬运，提高了数据处理效率。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1示出了本申请实施例提供的一种云游戏场景的示意图；

图2为本申请实施例提供的一种RTC音频数据的处理方法的流程示意图；

图3为本申请实施例提供的一种第一线程的示意图；

图4为本申请实施例提供的一种RTC音频数据的处理装置的示意性框图；

图5为本申请示例性实施例提供的一种电子设备的结构示意图。

具体实施方式

云计算(cloud computing)是一种基于互联网的计算模式，通过这种计算方式，共享的软硬件资源和信息可以按需求提供给各种终端。提供资源的网络被称为“云”。“云”中的资源在使用者看来是可以无限扩展的，并且可以随时获取，按需使用。

云游戏是云应用中的一种，是以云计算为基础的游戏方式，在云游戏的运行模式下，所有游戏都在服务端(例如云服务端)运行，并将渲染后的游戏通过网络传输给客户端。

图1示出了本申请实施例提供的一种云游戏场景100的示意图。结合图1所示，云服务端110用于为远程服务提供载体，该云服务端110可以是云计算资源池。云服务端110可以实现为云端的服务器或者服务器集群，例如图1中的服务器111，且云端的服务器111通过虚拟化技术虚拟出一个或多个虚拟机，例如服务器111中存在虚拟机111-1。服务器111中的虚拟机111-1通过网络130(例如以太网或者5G)向云服务的客户端提供云服务(例如提供云游戏的服务)。

参见图1，云服务的客户端(通常称为瘦客户端)120通过网络130接收云服务端虚拟机111-1提供的云服务，例如接收虚拟机映射的云游戏。

示例性的，在图1所示的云游戏场景100中，在客户端120与云服务端110之间可以存在数据的上行传输和数据的下行传输。在数据的上行传输过程中，用户可以通过游戏手柄、或者触摸操作与客户端120进行交互，以输入游戏指令、音/视频数据等。客户端120对输入的游戏指令、音/视频数据发送至云服务端110，以使云服务端110得到用户输入的数据流。

在数据的下行传输过程中，云服务端110对待发送的音/视频数据进行编码以及封装，并将封装后的音/视频数据发送至客户端120，客户端120接收云服务端110发送的封装后的音/视频数据，并对其进行解封装，再解码得到音频数据和/或视频数据。进而，客户端120输出该音频数据和/或视频数据，以向用户播放该音频数据和/或视频数据。

需要说明的是，上述上行传输和下行传输过程中的数据均可以是数据流(datastream)。其可以理解为一组有序的，有起点和终点的字节的数据序列，或者一组有序的数据包。

云服务端110和客户端120之间可以通过流化协议实现数据流传输的协议。例如实时传输协议(Real-time Transport Protocol，RTP)、实时传输控制协议(Real-timeTransport Control Protocol，RTCP)、安全实时传输协议(Secure Real-time TransportProtocol，SRTP)、安全实时传输控制协议(Secure Real-time Transport ControlProtocol，SRTCP)或实时流传输协议(Real Time Streaming Protocol，RTSP)等。

在上述音频数据的下行传输中，客户端120通常基于WebRTC技术，接收云服务端110发送的音频数据。应理解，WebRTC还可以应用于网络电话、电话会议、视频聊天、直播等场景中，在这些场景中，云服务端发送的下行数据流中的数据的采样率不固定，因此基于WebRTC技术，客户端120需要利用多个线程串行完成音/视频数据的接收、解封装、解码等操作，以使不同的线程通过在消息队列中搬运数据，来保持数据流中数据的时序。而对于上述云游戏场景来说，云服务端110发送的音频数据通常是基于固定的采样率进行采样得到的，相较于网络电话、视频聊天等场景来说，云服务端110发送的下行数据流的时序是稳定可控的，基于现有WebRTC技术对下行数据流进行数据处理，将导致客户端的数据处理效率较低。

进一步地，同样因为WebRTC应用于网络电话、电话会议、视频聊天、直播等场景，导致云服务端发送的下行数据流中的音频数据存在环境回声和环境噪声，因此，客户端需要基于WebRTC技术，对接收的下行数据流中的音频数据进行回声消除、纠错补偿、重采样、静音补零等中的至少一项预处理操作。而本申请实施例中，客户端对接收到的音频数据进行解封装后，不需要经过上述任一预处理操作，直接对音频数据进行解码，并播放解码后的音频数据，进一步提高了数据处理的效率，降低了客户端处理器的开销。

本申请实施例仅以云游戏为例进行说明，但并不对此进行限定，例如云服务还可以是云桌面服务或任意云应用服务等。

本申请适用于任意一种RTC的音频数据传输场景，尤其适用于数据流中的数据时序稳定、或者数据流的时序不敏感的场景。

上述客户端120可以实现为任意具有处理器的终端设备，例如普通计算机PC、手机(mobile phone)、平板电脑(pad)、智能可穿戴设备、带无线收发功能的电脑、虚拟现实(virtual reality，VR)终端设备、增强现实(augmented reality，AR)终端设备、工业控制(industrial control)中的无线终端、无人驾驶(self driving)中的无线终端、远程手术(remote medical surgery)中的无线终端、智能电网(smart grid)中的无线终端、运输安全(transportation safety)中的无线终端、智慧城市(smart city)中的无线终端、智慧家庭(smart home)中的无线终端等。

示例性的，客户端120实现的终端设备中，可以部署有基于第五代精简指令集计算机(Reduced Instruction Set Computer，RISC)，或称作RISC-V指令集的D1芯片。其中，RISC-V是基于精简指令集计算原理建立的开放指令集架构(Instruction SetArchitecture，ISA)。可选的，该D1芯片集成64位单核CPU，1GHz主频，支持最高4K的H.265/H.264解码。

示例性的，客户端120可以基于开源发布的WebRTC开发套件(Open WebRTCToolkit，OWT)的流化技术获取虚拟机的云游戏音/视频数据流。其中，OWT是一款端到端媒体服务器软件，OWT软件客户端包含JavaScript/Android/iOS/Linux/Windows C++SDK等开发环境，OWT软件服务端支持选择性转发单元(Selective Forwarding Unit，SFU)和多点控制单元(MultiPoint Control Unit，MCU)两种模式，可实现实时音视频分析功能，在云游戏场景具有较好的低延时性能。

示例性的，客户端120可以通过自身部署的播放装置，播放音/视频数据流。或者，客户端120可以与外部设备连接，例如通过高清多媒体接口(High Definition MultimediaInterface，HDMI)与显示器连接，将音/视频数据流推送至显示器进行显示。

针对上述客户端数据处理效率较低的问题，本申请实施例考虑通过一个线程(thread)(如下文中的第一线程)进行数据流的接收、解码等处理，以期提高客户端的数据处理效率。

需要说明的是，线程是独立调度和分派的基本单位，是操作系统能够运行调度的最小单位，其被包含于进程之中，是进程中的实际运作单位。一个线程是指进程中一个单一顺序的控制流。

下面结合附图对本申请实施例提供的RTC音频数据的处理方法做详细说明。

应理解，下文仅为便于理解和说明，以客户端为执行主体为例详细说明本申请实施例所提供的方法。示例性的，该客户端可以是图1中的客户端120，或者客户端120中的部件，例如芯片或芯片系统。下文中提到的服务端可以是图1中的云服务端110，或者云服务端110中的部件，例如芯片或者芯片系统。

图2为本申请实施例提供的一种RTC音频数据的处理方法的流程示意图。如图2所示，该方法包括：

S210，通过第一线程，接收并解码服务端发送的RTC音频数据流，得到目标音频数据流；

S220，播放目标音频数据流。

RTC音频数据流可以理解为在RTC场景下传输的音频数据流。在上述S210中，客户端通过第一线程即可接收服务端发送的RTC音频数据流，并解码RTC音频数据流，得到最终可播放的目标数据流，而不需要通过多个线程来对音频数据流进行数据处理，避免不同线程之间通过消息队列进行音频数据的搬运，提高了数据处理效率。

在上述S220中，客户端可以通过自身部署的播放装置，例如扬声器，播放目标音频数据流；或者，客户端可以通过其连接的外部设备，例如音箱、或者具有扬声器的显示器、手机等终端设备，播放目标音频数据流。

可选的，客户端播放目标音频数据流可以通过上述第一线程或者不同于第一线程的第二线程。其区别在于，通过第一线程播放目标音频数据流可以进一步提高客户端数据处理的效率，通过第二线程播放目标音频数据流，可以基于消息队列实现线程间的消息异步传输，使第二线程从消息队列中读取第一线程处理放入消息队列中的音频数据，避免第一线程在数据处理过程中发送异常而影响目标音频数据流的播放效果。

在一些实施例中，RTC音频数据流可以包括多个音频数据包，该音频数据包包括音频编码数据。在音频数据流包括多个音频数据包的情况下，客户端可以通过第一线程对每个音频数据包进行音频解码，得到每个音频数据包对应的音频解码数据，且各音频数据包对应的音频解码数据可以组成上述目标音频数据流。

接续上述实施例，客户端可以播放目标音频数据流中的各音频解码数据，以实现对目标音频数据的播放。例如，客户端可以通过第一线程播放目标音频数据流中的各音频解码数据。

举例而言，服务端将实时采样的音频数据进行编码，得到音频编码数据，并对音频编码数据进行封装，得到音频数据包，在不同采样时间段采样、编码并封装可以得到多个具有时序关系的音频数据包，以形成前述RTC音频数据流。

该音频数据包可以是基于流化协议封装的音频数据包，例如前述RTP、SRTP等，基于RTP封装的音频数据包可以简称为RTP数据包，基于SRTP封装的音频数据包可以简称为SRTP数据包。

假设音频数据流中的音频数据包是上述RTP数据包，客户端通过第一线程接收该RTP数据包后可以基于RTP对该RTP数据包进行解封装，以得到该RTP数据包中的音频编码数据，进而通过第一线程对RTP数据包中的音频编码数据进行解码，得到音频解码数据。进一步地，客户端通过第一线程播放该音频解码数据。

假设音频数据流中的音频数据包是上述SRTP数据包，结合图3所示，客户端通过第一线程接收该SRTP数据包后可以基于SRTP对该SRTP数据包进行解密，得到RTP数据包，可以理解的是，客户端对SRTP数据包的解密也可以描述为第一线程对SRTP的解封装，二者可以替换使用，其表达的含义相同。进一步地，客户端通过第一线程基于RTP对该RTP数据包进行解封装，得到RTP数据包中的音频编码数据，再对该音频编码数据进行解码，得到音频解码数据。进一步地，客户端通过第一线程播放该音频解码数据。

当然，本申请仅以音频数据流包括多个音频数据包为例进行说明，但并不应理解为对本申请构成任何限定。例如音频数据流中可以包括编码后的多个音频编码数据，在不封装的情况下由服务端发送至客户端，此种情况下，客户端通过第一线程对接收到的音频编码数据进行解码，得到音频解码数据，进而通过第一线程播放该音频解码数据。

在一些场景中，服务端发送的音频数据通常是基于固定的采样率进行采样得到的。当服务端基于固定的采样率进行音频数据的采样时，RTC音频数据流中的多个音频数据包均包括相同时长的音频编码数据。此种情况下，服务端可以按照预设时长向客户端发送音频数据包，客户端可以在每个接收周期，接收服务端发送的音频数据包，一般来说，接收周期与预设时长相同。例如，服务端每隔20ms预设时长，将采样的音频数据编码后进行封装，得到RTP数据包，该RTP数据包包括20ms的音频编码数据，服务端在每次封装后将封装得到的RTP数据包发送至客户端，也即服务端每隔20ms向客户端发送一个RTP数据包，相应的，客户端通过第一线程，每隔20ms接收一个RTP数据包。

当服务端发送的客户端的音频数据流中的多个音频数据包均包括相同预设时长的音频编码数据时，音频数据流的时序是稳定可控的。此种情况下，客户端通过第一线程接收的音频数据流的多个音频数据包具有稳定的时序关系，进而，客户端可以在不需要消息队列的情况下，维持音频数据流中的多个音频数据包的时序关系，以使客户端继续对该多个音频数据包进行解密、解封装、解码等操作。

在上述实施例中，客户端通过第一线程对音频数据流中的多个音频数据包分别进行解封装以及解码的操作。在另一些实施例中，客户端可以通过第一线程对音频数据流中的多个音频数据包中的一些音频数据包中的音频编码数据进行合并，并通过第一线程对合并后的音频编码数据进行解码。例如，通过第一线程对多个音频数据包中的一些音频数据包进行解封装，得到属于同一帧的音频编码数据，将属于同一帧的音频编码数据合并，再通过第一线程对合并后的一帧的音频编码数据进行解码。

因此，本申请实施例通过第一线程，接收并解码服务端发送的RTC音频数据流得到目标音频数据流，进而播放该目标音频数据流，避免通过多线程对RTC音频数据流进行数据处理以得到所需播放的音频数据流，而导致数据处理效率较低的问题。

在本申请的各个实施例中，如果没有特殊说明以及逻辑冲突，各个实施例之间的属于和/或描述具有一致性、且可以相互引用，不同的实施例中的技术特征根据其内在的逻辑关系可以组合形成新的实施例。

需要说明的是，本文中的“第一”、“第二”等描述，是用于区分不同的线程等，不代表先后顺序，也不限定“第一”和“第二”是不同的类型。

图4为本申请实施例提供的一种RTC音频数据的处理装置的示意性框图。如图4所示，该RTC音频数据的处理装置400可以包括处理单元410和播放单元420。

可选的，该RTC音频数据的处理装置400可对应于上文方法实施例中的客户端，例如可以为前述客户端的一种实现，或者配置于客户端中的部件(如芯片或芯片系统等)。

其中，处理单元410可以用于通过第一线程，接收并解码服务端发送的RTC音频数据流得到目标音频数据流；该播放单元420可以用于播放该目标音频数据流。

在一些实施例中，该RTC音频数据流包括多个音频数据包，该音频数据包包括音频编码数据，该处理单元410具体用于：针对该多个音频数据包中的每个音频数据包，通过该第一线程，对该音频数据包中的音频编码数据进行音频解码，得到该音频数据包对应的音频解码数据；该多个音频数据包分别对应的音频解码数据组成该目标音频数据流。

在一些实施例中，该播放单元420具体用于：通过该第一线程，播放该目标音频数据流中的各音频解码数据。

在一些实施例中，该RTC音频数据流中的各音频数据包均包括预设时长的音频编码数据；该处理单元410具体用于：通过该第一线程，在每个接收周期，接收该服务端发送的该多个音频数据包中的一个，该接收周期等于该预设时长。

在一些实施例中，该RTC音频数据流中的各音频数据包均为加密数据包，该通过该第一线程，对该RTC音频数据流进行音频解码，得到目标音频数据流之前，该处理单元410还用于：通过该第一线程，对该多个有序的音频数据包进行解密。

在一些实施例中，该处理单元410具体用于：通过该第一线程，对该音频数据包进行解封装，得到该音频数据包中的音频编码数据；通过该第一线程，对该音频编码数据进行解码，得到该音频数据包对应的音频解码数据。

在一些实施例中，该音频数据包为基于实时传输协议RTP封装的数据包，或者该一弄数据包为基于安全实时传输协议SRTP封装的数据包。

以上装置中各单元的划分仅是一种逻辑功能的划分，实际实现时可以全部或部分集成到一个物理实体上，也可以物理上分开。

应理解，各单元执行上述相应步骤的具体过程在上述方法实施例中已经详细说明，为了简洁，在此不再赘述。

图5为本申请示例性实施例提供的一种电子设备的结构示意图。该电子设备可以实现为上文方法实施例中的客户端。如图5所示，该电子设备500包括：处理器510和收发器520。可选地，该电子设备500还包括存储器530。其中，处理器510、收发器520和存储器530之间可以通过内部连接通路互相通信，传递控制和/或数据信号，该存储器530用于存储计算机程序，该处理器510用于从该存储器530中调用并运行该计算机程序，以控制该收发器520收发信号。可选地，电子设备500还可以包括天线540，用于将收发器520输出的上行数据或上行控制信令通过无线信号发送出去。

上述处理器510可以和存储器530可以合成一个处理装置，处理器510用于执行存储器530中存储的程序代码来实现上述功能。具体实现时，该存储器530也可以集成在处理器510中，或者独立于处理器510。

上述收发器520可以包括接收器(或称接收机、接收电路)和发射器(或称发射机、发射电路)。其中，接收器用于接收信号，发射器用于发射信号。

可选地，上述电子设备500还可以包括电源550，用于给电子设备500中的各种器件或电路提供电源。

除此之外，为了使得该终端设备的功能更加完善，该电子设备500还可以包括输入单元560、显示单元570、音频电路580、摄像头590和传感器600等中的一个或多个，所述音频电路还可以包括扬声器580a、麦克风580b等。

应理解，图5所示的电子设备500能够实现上文方法实施例中涉及第一终端或第二终端的各个过程。电子设备500中的各个模块的操作和/或功能，分别为了实现上述方法实施例中的相应流程。具体可参见上述方法实施例中的描述，为避免重复，此处适当省略详细描述。

本申请还提供了一种处理装置，包括至少一个处理器，所述至少一个处理器用于执行存储器中存储的计算机程序，以使得所述处理装置执行上述方法实施例中客户端执行的方法。

本申请实施例还提供了一种处理装置，包括处理器和输入输出接口。所述输入输出接口与所述处理器耦合。所述输入输出接口用于输入和/或输出信息。所述信息包括指令和数据中的至少一项。所述处理器用于执行计算机程序，以使得所述处理装置执行上述方法实施例中客户端执行的方法。

本申请实施例还提供了一种处理装置，包括处理器和存储器。所述存储器用于存储计算机程序，所述处理器用于从所述存储器调用并运行所述计算机程序，以使得所述处理装置执行上述方法实施例中客户端执行的方法。

应理解，上述处理装置可以是一个或多个芯片。例如，该处理装置可以是现场可编程门阵列(field programmable gate array，FPGA)，可以是专用集成芯片(applicationspecific integrated circuit，ASIC)，还可以是系统芯片(system on chip，SoC)，还可以是处理器(central processor unit，CPU)，还可以是网络处理器(network processor，NP)，还可以是数字信号处理电路(digital signal processor，DSP)，还可以是微控制器(micro controller unit，MCU)，还可以是可编程控制器(programmable logic device，PLD)或其他集成芯片。

在实现过程中，上述方法的各步骤可以通过处理器中的硬件的集成逻辑电路或者软件形式的指令完成。结合本申请实施例所公开的方法的步骤可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器，处理器读取存储器中的信息，结合其硬件完成上述方法的步骤。为避免重复，这里不再详细描述。

应注意，本申请实施例中的处理器可以是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法实施例的各步骤可以通过处理器中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器可以是通用处理器、数字信号处理器(DSP)、专用集成电路(ASIC)、现场可编程门阵列(FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器，处理器读取存储器中的信息，结合其硬件完成上述方法的步骤。

可以理解，本申请实施例中的存储器可以是易失性存储器或非易失性存储器，或可包括易失性和非易失性存储器两者。其中，非易失性存储器可以是只读存储器(read-only memory，ROM)、可编程只读存储器(programmable ROM，PROM)、可擦除可编程只读存储器(erasable PROM，EPROM)、电可擦除可编程只读存储器(electrically EPROM，EEPROM)或闪存。易失性存储器可以是随机存取存储器(random access memory，RAM)，其用作外部高速缓存。通过示例性但不是限制性说明，许多形式的RAM可用，例如静态随机存取存储器(static RAM，SRAM)、动态随机存取存储器(dynamic RAM，DRAM)、同步动态随机存取存储器(synchronous DRAM，SDRAM)、双倍数据速率同步动态随机存取存储器(double data rateSDRAM，DDR SDRAM)、增强型同步动态随机存取存储器(enhanced SDRAM，ESDRAM)、同步连接动态随机存取存储器(synchlink DRAM，SLDRAM)和直接内存总线随机存取存储器(directrambus RAM，DR RAM)。应注意，本文描述的系统和方法的存储器旨在包括但不限于这些和任意其它适合类型的存储器。

根据本申请实施例提供的方法，本申请还提供一种计算机程序产品，该计算机程序产品包括：计算机程序代码，当该计算机程序代码在计算机上运行时，使得该计算机执行上述方法实施例中的客户端执行的方法。

根据本申请实施例提供的方法，本申请还提供一种计算机可读存储介质，该计算机可读存储介质存储有程序代码，当该程序代码在计算机上运行时，使得该计算机执行上述方法实施例中的客户端执行的方法。

以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。

Claims (10)

1.一种实时通信RTC音频数据的处理方法，其特征在于，包括：

通过第一线程，接收并解码服务端发送的RTC音频数据流得到目标音频数据流；

播放所述目标音频数据流。

2.根据权利要求1所述的方法，其特征在于，所述RTC音频数据流包括多个音频数据包，所述音频数据包包括音频编码数据，所述通过所述第一线程，解码所述RTC音频数据流得到目标音频数据流，包括：

针对所述多个音频数据包中的每个音频数据包，通过所述第一线程，对所述音频数据包中的音频编码数据进行音频解码，得到所述音频数据包对应的音频解码数据；

所述多个音频数据包分别对应的音频解码数据组成所述目标音频数据流。

3.根据权利要求2所述的方法，其特征在于，

所述播放所述目标音频数据流，包括：

通过所述第一线程，播放所述目标音频数据流中的各音频解码数据。

4.根据权利要求2或3所述的方法，其特征在于，所述RTC音频数据流中的各音频数据包均包括预设时长的音频编码数据；

所述通过第一线程，接收服务端发送的RTC音频数据流，包括：

通过所述第一线程，在每个接收周期，接收所述服务端发送的所述多个音频数据包中的一个，所述接收周期等于所述预设时长。

5.根据权利要求2或3所述的方法，其特征在于，所述RTC音频数据流中的各音频数据包均为加密数据包，所述通过所述第一线程，对所述RTC音频数据流进行音频解码，得到目标音频数据流之前，所述方法还包括：

通过所述第一线程，对所述多个有序的音频数据包进行解密。

6.根据权利要求2或3所述的方法，其特征在于，所述通过所述第一线程，对所述音频数据包中的音频编码数据进行音频解码，得到所述音频数据包对应的音频解码数据，包括：

通过所述第一线程，对所述音频数据包进行解封装，得到所述音频数据包中的音频编码数据；

通过所述第一线程，对所述音频编码数据进行解码，得到所述音频数据包对应的音频解码数据。

7.根据权利要求2或3所述的方法，其特征在于，所述音频数据包为基于实时传输协议RTP封装的数据包，或者所述音频数据包为基于安全实时传输协议SRTP封装的数据包。

8.一种RTC音频处理装置，其特征在于，包括：

处理单元，用于通过第一线程，接收并解码服务端发送的RTC音频数据流得到目标音频数据流；

播放单元，用于播放所述目标音频数据流。

9.一种电子设备，其特征在于，包括：至少一个处理器和存储器；

所述存储器存储计算机执行指令；

所述至少一个处理器执行所述存储器存储的计算机执行指令，使得所述至少一个处理器执行如权利要求1至11中任一项所述的方法。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有计算机执行指令，当处理器执行所述计算机执行指令时，实现如权利要求1至7中任一项所述的方法。

Images