音频播放状态处理方法、装置、设备及存储介质与流程

本发明实施例涉及互联网技术领域，尤其涉及一种音频播放状态处理方法、装置、设备及存储介质。

背景技术：

随着互联网技术的发展，直播形式越来越多，例如语音直播和视频直播。听众可通过登录客户端，在直播页面中任选一个直播间，进入直播间与主播进行互动。

实际应用过程中，当听众进入实时多人互动语音直播间(又叫音频直播间)，收听主播语音时，由于听众端获取的是通过服务器合并处理后的直播流，因此听众无法清楚知晓当前语音属于哪位主播。相关技术中，为了获取当前语音所属的主播信息，听众端通过与服务器通信，从服务器端获取当前语音所属的主播信息。

然而，上述获取语音所属的主播信息不能保证和直播流完全同步，且同步快慢依赖于当前网络状态。其中，当网络状态良好时，状态同步延时小；当网络状态差时，状态同步延时加大。

技术实现要素：

本发明实施例提供一种音频播放状态处理方法、装置、设备及存储介质，有效地解决了多人音频直播间语音状态同步的问题。

第一方面，本发明实施例提供了一种音频播放状态处理方法，应用于服务端，该方法包括：将直播间中至少两个主播端的音频流合成一路音频流；确定所述至少两个主播端的播放状态信息；生成携带有所述至少两个主播端的播放状态信息的一路视频流；基于实时消息传输协议对所述音频流和所述视频流进行封装得到所述直播间的数据流，供听众端根据所述直播间的数据流得到所述至少两个主播端的播放状态信息。

第二方面，本发明实施例提供了一种音频播放状态处理方法，应用于听众端，该方法包括：获取直播间的数据流，其中所述直播间的数据流由服务端通过如下操作得到：将直播间中至少两个主播端的音频流合成一路音频流；确定所述至少两个主播端的播放状态信息；生成携带有所述至少两个主播端的播放状态信息的一路视频流；基于实时消息传输协议对所述音频流和所述视频流进行封装得到直播间的数据流；对所述直播间的数据流进行处理，得到所述至少两个主播端的播放状态信息。

第三方面，本发明实施例还提供了一种音频播放状态处理装置，配置于服务端，该装置包括：合成模块，用于将直播间中至少两个主播端的音频流合成一路音频流；确定模块，用于确定所述至少两个主播端的播放状态信息；生成模块，用于生成携带有所述至少两个主播端的播放状态信息的一路视频流；封装模块，用于基于实时消息传输协议对所述音频流和所述视频流进行封装得到所述直播间的数据流，供听众端根据所述直播间的数据流得到所述至少两个主播端的播放状态信息。

第四方面，本发明实施例还提供一种音频播放状态处理装置，配置于听众端，该装置包括：获取模块，用于获取直播间的数据流，其中所述直播间的数据流由服务端通过如下操作得到：将直播间中至少两个主播端的音频流合成一路音频流；确定所述至少两个主播端的播放状态信息；生成携带有所述至少两个主播端的播放状态信息的一路视频流；基于实时消息传输协议对所述音频流和所述视频流进行封装得到直播间的数据流；处理模块，用于对所述直播间的数据流进行处理，得到所述至少两个主播端的播放状态信息。

第五方面，本发明实施例还提供了一种计算机设备，该计算机设备包括：存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现第一方面实施例所述的音频播放状态处理方法，或第二方面实施例所述的音频播放状态处理方法。

第六方面，本发明实施例还提供了一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时以实现第一方面实施例所述的音频播放状态处理方法，或第二方面实施例所述的音频播放状态处理方法。

本发明实施例公开的技术方案，具有如下有益效果：

通过将直播间中至少两个主播端的音频流合成一路音频流，并确定至少两个主播端的播放状态信息，生成携带有至少两个主播端的播放状态信息的一路视频流，然后基于实时消息传输协议对音频流和视频流进行封装得到直播间的数据流，供听众端根据直播间的数据流得到至少两个主播端的播放状态信息。由此，实现了通过将主播端的播放状态携带在直播数据流中，使得用户通过直播内容即可确定当前音频对应的主播信息，从而减少了听众端与服务端之间的通信次数，还能避免当前网络状态对获取主播信息的不利影响，有效解决了多人音频直播间语音同步的问题，提高了用户体验。

附图说明

图1是本发明实施例一提供的一种音频播放状态处理方法的流程示意图；

图2是本发明实施例二提供的一种音频播放状态处理方法的流程示意图；

图3是本发明实施例三提供的一个具体实施例的服务端与听众端进行信令交互的示意图；

图4是本发明实施例四提供的一种音频播放状态处理装置的结构示意图；

图5是本发明实施例五提供的一种音频播放状态处理装置的结构示意图；

图6是本发明实施例六提供的一种计算机设备的结构示意图。

具体实施方式

下面结合附图和实施例对本发明实施例作进一步的详细说明。可以理解的是，此处所描述的具体实施例仅仅用于解释本发明实施例，而非对本发明实施例的限定。另外还需要说明的是，为了便于描述，附图中仅示出了与本发明实施例相关的部分而非全部结构。

本发明实施例针对相关技术中，获取语音所属的主播信息不能保证和直播流完全同步，且同步快慢依赖当前网络状态，其中当网络状态好时，状态同步延时小，当网络状态不好时，状态同步延时大的问题，提出一种音频播放状态处理方法。

本发明实施例，通过将直播间中至少两个主播端的音频流合成一路音频流，并确定至少两个主播端的播放状态信息，以生成携带有至少两个主播端的播放状态信息的一路视频流，然后基于实时消息传输协议对音频流和视频流进行封装得到直播间的数据流，供听众端根据直播间的数据流得到至少两个主播端的播放状态信息。由此，实现了通过将主播端的播放状态携带在直播数据流中，使得用户通过直播内容即可确定当前音频对应的主播信息，从而减少了听众端与服务端之间的通信次数，还能避免当前网络状态对获取主播信息的不利影响，有效解决了多人音频直播间语音同步的问题，提高了用户体验。

下面参考附图描述本发明实施例的音频播放状态处理方法、装置、设备及存储介质进行详细说明。

首先，以服务端为例对本发明实施例的音频播放状态处理方法进行详细描述。

实施例一

图1是本发明实施例一提供的一种音频播放状态处理方法的流程示意图，本发明实施例可适用于在多人交互语音直播时，确定音频对应主播信息的场景，该方法可由音频播放状态处理装置来执行，以实现对确定音频对应主播信息进行控制，该音频播放状态处理装置可以由软件和/硬件实现，并该音频播放状态处理装置可应用于服务端中。其中，在本实施例中，服务端可包括多媒体服务器和合流服务器。该方法具体包括如下：

S101，将直播间中至少两个主播端的音频流合成一路音频流。

其中，直播间为语音直播间，主播端是指主播直播时使用的客户端。其中客户端可以是，但不限于：智能手机、个人数字助理等。

可选的，在执行S101之前，本实施例可在至少两个主播进入多人交互语音直播间进行语音直播时，通过至少两个主播端集成的麦克风采集对应主播的音频流，并对采集的音频流进行编码。然后，将编码后的音频流通过低延时网络发送给多媒体服务器，以通过多媒体服务器将接收到的编码后的音频流转发给合流服务器，通过合流服务器对上述至少两个编码后的音频流进行合流处理，得到一路音频流。同时，多媒体服务器还将除自身编码后的音频流之外的其他编码后的音频流发送给不同的主播端，以实现不同主播端的音频流交互。

进一步的，当合流服务器接收到多媒体服务器发送的至少两个编码后的音频流之后，可按照预设合成规则进行合成处理，得到一路音频流。

在本实施例中，预设合成规则可以是现有的，也可以是技术人员根据需要自定义设置的，此处对其不做具体限定。

例如，若主播端有三个，分别为：Y1、Y2、Y3，那么当三个主播端对应的三个主播进入语音直播间进行语音直播时，主播端Y1、主播端Y2、主播端Y3分别利用各自的麦克风采集对应主播的音频流k1、k2、k3。然后，主播端Y1对音频流k1进行编码得到K1，主播端Y2对音频流k2进行编码得到K2，主播端Y3对音频流k3进行编码得到K3，并将K1、K2、K3通过低延时网络发送给多媒体服务器，以使多媒体服务器将接收到的K1、K2、K3转发给合流服务器，并将K1发送给主播端Y2和Y3，将K2发送给主播端Y1和Y3，将K3发送给主播端Y1和Y2。其中，合流服务器接收到K1、K2、K3之后，按照预设合成规则将K1、K2、K3进行合成处理，得到一路音频流K。

S102，确定所述至少两个主播端的播放状态信息。

在本实施例中，播放状态信息包括：播放中和未播放。

可选的，本实施例中当合成服务器获取到至少两个主播端分别对应的音频流之后，可首先对至少两个主播端分别对应的音频流进行解码处理，然后分别计算每个主播音频流的音频音量，以根据音频音量，生成播放状态信息。

也就是说，本实施例确定至少两个主播端的播放状态信息，包括：根据所述至少两个主播端的音频流的音频音量，确定至少两个主播端的播放状态信息。

例如，假设预设的音量阈值为40分贝(dB)，主播端Y1的音频流的音频音量为45dB，主播端Y2的音频流的音频音量为12dB，主播端Y3的音频流的音频音量为3dB，那么确定出主播端Y1的音频流的音频音量45dB大于音量阈值40dB，则说明主播端Y1当前处于播放状态，主播端Y2和主播端Y3当前处于未播放状态。

进一步的，本实施例根据至少两个主播端的音频流的音频音量，确定至少两个主播端的播放状态信息的同时，还可确定至少两个主播端的主播标识信息，从而根据该主播标识信息对后续处理提供有利帮助。

其中，在本实施例中，主播标识信息可以包括：昵称、头像等，此处对其不做具体限定。

S103，生成携带有所述至少两个主播端的播放状态信息的一路视频流。

在本实施例中，所述视频流是纯色视频流。例如，黑色视频流。

可选的，在根据至少两个主播端分别对应的音频流，确定至少两个主播端的播放状态信息之后，合流服务器还可生成一路视频流。其中，该一路视频流中携带有至少两个主播端的播放状态信息。

需要说明的是，由于S102中除了确定至少两个主播端的播放状态信息之外，还确定了至少两个主播端的主播标识信息。因此本实施例中，还可将至少两个主播端的主播标识信息和播放状态信息一起携带到上述一路视频流中，以便于后续根据主播标识信息进行相应处理。

S104，基于实时消息传输协议对所述音频流和所述视频流进行封装得到所述直播间的数据流，供听众端根据所述直播间的数据流得到所述至少两个主播端的播放状态信息。

实际应用中，由于实时消息传输协议(Real Time Messaging Protocol，简称RTMP)不支持音频流中携带数据，而支持视频流中携带数据，因此本实施例中可利用RTMP协议对音频流和视频流进行封装得到直播间的数据流，使得听众端可根据上述数据流得到至少两个主播端的播放状态信息。

在本发明一实施例中，在对音频流和视频流进行封装时，还可将音频流的时间戳和视频流的时间戳关联，以达到音频流和视频流之间的同步。

也就是说，本实施例基于实时消息传输协议对所述音频流和所述视频流进行封装得到所述直播间的数据流，包括：基于实时消息传输协议，根据音频流的时间戳和视频流的时间戳，对所述音频流和所述视频流进行封装得到所述直播间的数据流，使所述数据流中音频信息和视频信息的时间同步。

进一步的，由于实际使用过程中，听众端的数量多，因此直接利用合流服务器响应不同听众端的获取请求时，存在带宽和并发能力不足的缺陷。

为此，为了能够实现并发流数目，减少单点失效带来的不良影响，本实施例可以采用将直播间的数据流转发给内容分发网络(Content Delivery Network，简称CDN)服务器，通过CDN服务器响应不同听众端的获取请求，从而能够在一定程度上保证端到端的服务质量。

本发明实施例提供的音频播放状态处理方法，通过将直播间中至少两个主播端的音频流合成一路音频流，并确定至少两个主播端的播放状态信息，生成携带有至少两个主播端的播放状态信息的一路视频流，然后基于实时消息传输协议对音频流和视频流进行封装得到直播间的数据流，供听众端根据直播间的数据流得到至少两个主播端的播放状态信息。由此，实现了通过将主播端的播放状态携带在直播数据流中，使得用户通过直播内容即可确定当前音频对应的主播信息，从而减少了听众端与服务端之间的通信次数，还能避免当前网络状态对获取主播信息的不利影响，有效解决了多人音频直播间语音同步的问题，提高了用户体验。

实施例二

下面结合附图，以听众端为例对本发明实施例提出的音频播放状态处理方法进行详细描述。

图2是本发明实施例二提供的一种音频播放状态处理方法的流程示意图。

如图2所示，该音频播放状态处理方法可以包括以下：

S201，获取直播间的数据流。

其中，所述直播间的数据流由服务端通过如下操作得到：将直播间中至少两个主播端的音频流合成一路音频流；确定所述至少两个主播端的播放状态信息；生成携带有所述至少两个主播端的播放状态信息的一路视频流；基于实时消息传输协议对所述音频流和所述视频流进行封装得到直播间的数据流。

可选的，在本实施例中，当听众端进入多人语音直播间之后，听众端获取直播间的数据流方式，可以是主动拉取直播间的数据流，也可以是获取服务端推送的直播间的数据流，此处对其不做具体限定。

需要说明的是，本实施例中得到直播间的数据流的具体方式，可具体参见上述实施例，此处对其不做过多赘述。

S202，对所述直播间的数据流进行处理，得到所述至少两个主播端的播放状态信息。

本实施例中，当获取到直播间的数据流之后，听众端可对直播间的数据进行解封处理，得到对应的音频流和视频流。进一步的，通过对视频流进行解析，得到至少两个主播端的播放状态信息；对音频流进行解码，得到至少两个主播端的播放内容。

也就是说，本实施例对直播间的数据流进行处理，包括：

对所述直播间的数据流进行解封装处理，得到所述数据流中的视频流部分和音频流部分；

对所述音频流部分进行解码，得到所述至少两个主播端的播放内容；

根据所述视频流部分，确定所述至少两个主播端的播放状态信息。

需要说明的是，由于前述实施例中，生成一路视频流时，还可将至少两个主播端的主播标识信息和播放状态一起携带在一路视频流中。因此本实施例中，对视频流进行解析，得到至少两个主播端的播放状态信息之外，还能得到至少两个主播端的主播标识信息。

在本发明的一实施例中，在得到至少两个主播端的播放状态信息之后，还包括：根据至少两个主播端的播放状态信息，为至少两个主播端添加播放状态标识，用于向听众展示所述至少两个主播端的播放状态。

其中，播放状态标识可以是，但不限于：动态音波、气泡等。

也就是说，当确定任一主播端的播放状态信息为播放中，则相应在该主播端上添加播放状态标识，以使听众端的用户可以轻松的确定当前处于语音直播状态的主播信息。

在本发明的另一实施例中，在得到至少两个主播端的播放状态信息之后，本实施例还可以根据至少两个主播端的播放状态信息，为至少两个主播端的主播标识信息位置上添加播放状态标识，以标识当前为该主播端的主播进行语音直播，使得用户可以轻松的确定当前处于语音直播状态的主播。

例如，若确定主播端Y2当前处于播放中，则可在主播端Y2的主播头像上显示气泡，以代表主播端Y2对应的主播当前处于语音播放中。

又如，若确定主播端Y2当前处于播放中，则可在主播端Y2的主播头像上显示动态音波，以代表主播端Y2对应的主播当前处于语音播放中。

进一步的，当确定至少两个主播端的播放状态信息发生变化时，本实施例还可对听众端的显示界面进行更新，使得用户不需要进行任何操作，即可实现获取当前处于播放状态的主播端，提高了用户体验。

本发明实施例提供的音频播放状态处理方法，通过获取直播间的数据流，并对获取的直播间的数据流进行处理，得到至少两个主播端的播放状态信息。由此，实现了通过将主播端的播放状态携带在直播数据流中，使得用户通过直播内容即可确定当前音频对应的主播信息，从而减少了听众端与服务端之间的通信次数，还能避免当前网络状态对获取主播信息的不利影响，有效解决了多人音频直播间语音同步的问题，提高了用户体验。

实施例三

下面通过一个具体实施例，对上述实施例音频播放状态处理方法进行具体说明，具体参见图3。图3是本发明实施例三提供的一个具体实施例的服务端与听众端进行信令交互的示意图。

假设本实施例中，服务端包括多媒体服务器X1、合流服务器X2及内容分发网络服务器X3、听众端可为N个，分别为：N1、N2、…Nn、主播端可为M个，分别为：M1、M2、…Mn，则服务端与听众端的交互过程可包括以下：

S301，主播端M1、M2、…Mn利用各自的麦克风采集对应主播的音频流m1、m2…mn，并对音频流m1、m2…mn进行编码，发送给多媒体服务器X1。

S302，多媒体服务器X1接收主播端M1、M2、…Mn分别发送的音频流m1、m2…mn，并将音频流m1、m2…mn转发给合流服务器X2。

S303，合流服务器X2将获取到的M个音频流进行合流，得到一路音频流。

S304，合流服务器X3对M个音频流进行解析处理，确定主播端M1、M2、…Mn的播放状态。

S305，合成服务器X3生成携带有M个主播端的播放状态的一路视频流。

S306，合成服务器X3基于RTMP对音频流和视频流进行封装得到直播间的数据流，并将直播间的数据流转发给内容分发网络服务器X3。

S307，内容分发网络服务器X3接收到听众端N1、N2、…Nn拉取操作时，将直播间的数据流发送给听众端N1、N2、…Nn。

S308，听众端N1、N2、…Nn对获取到的直播间的数据流进行处理，得到主播端M1、M2、…Mn的播放状态。

通过上述实施例提供的音频播放状态处理方法，通过将主播端的播放状态携带在直播数据流中，使得用户通过直播内容即可确定当前音频对应的主播信息，从而减少了听众端与服务端之间的通信次数，还能避免当前网络状态对获取主播信息的不利影响，有效解决了多人音频直播间语音同步的问题，提高了用户体验。

实施例四

为了实现上述目的，本发明实施例四提出了一种音频播放状态处理装置，其中该音频播放状态处理装置，配置于服务端。

图4是本发明实施例四提供的一种音频播放状态处理装置的结构示意图。

如图4所示，本发明实施例音频播放状态处理装置包括：合成模块110、确定模块112、生成模块114及封装模块116。

其中，合成模块110用于将直播间中至少两个主播端的音频流合成一路音频流；

确定模块112用于确定所述至少两个主播端的播放状态信息；

生成模块114用于生成携带有所述至少两个主播端的播放状态信息的一路视频流；

封装模块116用于基于实时消息传输协议对所述音频流和所述视频流进行封装得到所述直播间的数据流，供听众端根据所述直播间的数据流得到所述至少两个主播端的播放状态信息。

作为本发明实施例的一种可选的实现方式，确定模块112具体用于：

根据所述至少两个主播端的音频流的音频音量，确定至少两个主播端的播放状态信息。

作为本发明实施例的一种可选的实现方式，所述视频流是纯色视频流。

作为本发明实施例的一种可选的实现方式，所述封装模块116具体用于：

基于实时消息传输协议，根据音频流的时间戳和视频流的时间戳，对所述音频流和所述视频流进行封装得到所述直播间的数据流，使所述数据流中音频信息和视频信息的时间同步。

需要说明的是，前述对音频播放状态处理方法实施例的解释说明也适用于该实施例的音频播放状态处理装置，其实现原理类似，此处不再赘述。

本发明实施例提供的音频播放状态处理装置，通过将直播间中至少两个主播端的音频流合成一路音频流，并确定至少两个主播端的播放状态信息，生成携带有至少两个主播端的播放状态信息的一路视频流，然后基于实时消息传输协议对音频流和视频流进行封装得到直播间的数据流，供听众端根据直播间的数据流得到至少两个主播端的播放状态信息。由此，实现了通过将主播端的播放状态携带在直播数据流中，使得用户通过直播内容即可确定当前音频对应的主播信息，从而减少了听众端与服务端之间的通信次数，还能避免当前网络状态对获取主播信息的不利影响，有效解决了多人音频直播间语音同步的问题，提高了用户体验。

实施例五

图5是本发明实施例五提供的一种音频播放状态处理装置的结构示意图，其中该音频播放状态处理装置，配置于听众端。

如图5所示，本发明实施例音频播放状态处理装置包括：获取模块210及处理模块212。

其中，获取模块210，用于获取直播间的数据流，其中所述直播间的数据流由服务端通过如下操作得到：将直播间中至少两个主播端的音频流合成一路音频流；确定所述至少两个主播端的播放状态信息；生成携带有所述至少两个主播端的播放状态信息的一路视频流；基于实时消息传输协议对所述音频流和所述视频流进行封装得到直播间的数据流；

处理模块212，用于对所述直播间的数据流进行处理，得到所述至少两个主播端的播放状态信息。

作为本发明实施例的一种可选的实现方式，所述处理模块112，包括：处理子单元、解码子单元及确定子单元。

其中，处理子单元用于对所述直播间的数据流进行解封装处理，得到所述数据流中的视频流部分和音频流部分；

解码子单元用于对所述音频流部分进行解码，得到所述至少两个主播端的播放内容；

确定子单元用于根据所述视频流部分，确定所述至少两个主播端的播放状态信息。

作为本发明实施例的一种可选的实现方式，音频播放状态处理装置还包括：添加标识模块。

其中，添加标识模块，用于根据所述至少两个主播端的播放状态信息，为所述至少两个主播端添加播放状态标识，用于向听众展示所述至少两个主播端的播放状态。

需要说明的是，前述对音频播放状态处理方法实施例的解释说明也适用于该实施例的音频播放状态处理装置，其实现原理类似，此处不再赘述。

本发明实施例提供的音频播放状态处理装置，通过获取直播间的数据流，并对获取的直播间的数据流进行处理，得到至少两个主播端的播放状态信息。由此，实现了通过将主播端的播放状态携带在直播数据流中，使得用户通过直播内容即可确定当前音频对应的主播信息，从而减少了听众端与服务端之间的通信次数，还能避免当前网络状态对获取主播信息的不利影响，有效解决了多人音频直播间语音同步的问题，提高了用户体验。

实施例六

为了实现上述目的，本发明实施例六还提出了一种计算机设备。

图6是本发明实施例六提供的一种计算机设备的结构示意图，如图6所示，该计算机设备包括处理器61、存储器62、输入装置63和输出装置64；计算机设备中处理器61的数量可以是一个或多个，图6中以一个处理器61为例；计算机设备中的处理器61、存储器62、输入装置63和输出装置64可以通过总线或其他方式连接，图6中以通过总线连接为例。

存储器62作为一种计算机可读存储介质，可用于存储软件程序、计算机可执行程序以及模块，如本发明实施例中的音频播放状态处理方法对应的程序指令/模块(例如，音频播放状态处理装置中的合成模块110、确定模块112、生成模块114及封装模块116；或者，音频播放状态处理装置中的获取模块210和处理模块212)。处理器61通过运行存储在存储器62中的软件程序、指令以及模块，从而执行计算机设备的各种功能应用以及数据处理，即实现上述第一方面实施例的音频播放状态处理方法，或第二方面实施例的音频播放状态处理方法。

存储器62可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序；存储数据区可存储根据终端的使用所创建的数据等。此外，存储器62可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他非易失性固态存储器件。在一些实例中，存储器62可进一步包括相对于处理器61远程设置的存储器，这些远程存储器可以通过网络连接至设备/终端/服务器。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

输入装置63可用于接收输入的数字或字符信息，以及产生与计算机设备的用户设置以及功能控制有关的键信号输入。输出装置64可包括显示屏等显示设备。

需要说明的是，前述对音频播放状态处理方法实施例的解释说明也适用于该实施例的计算机设备，其实现原理类似，此处不再赘述。

本发明实施例提供的计算机设备，通过将直播间中至少两个主播端的音频流合成一路音频流，并确定至少两个主播端的播放状态信息，生成携带有至少两个主播端的播放状态信息的一路视频流，然后基于实时消息传输协议对音频流和视频流进行封装得到直播间的数据流，供听众端根据直播间的数据流得到至少两个主播端的播放状态信息。由此，实现了通过将主播端的播放状态携带在直播数据流中，使得用户通过直播内容即可确定当前音频对应的主播信息，从而减少了听众端与服务端之间的通信次数，还能避免当前网络状态对获取主播信息的不利影响，有效解决了多人音频直播间语音同步的问题，提高了用户体验。

实施例七

为了实现上述目的，本发明实施例七还提出了一种计算机可读存储介质。

本发明实施例七提供的一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现如第一方面实施例所述的音频播放状态处理方法，该音频播放状态处理方法包括：将直播间中至少两个主播端的音频流合成一路音频流；确定所述至少两个主播端的播放状态信息；生成携带有所述至少两个主播端的播放状态信息的一路视频流；基于实时消息传输协议对所述音频流和所述视频流进行封装得到所述直播间的数据流，供听众端根据所述直播间的数据流得到所述至少两个主播端的播放状态信息。

或者，实现如第二方面实施例所述的音频播放状态处理方法，该音频播放状态处理方法包括：获取直播间的数据流，其中所述直播间的数据流由服务端通过如下操作得到：将直播间中至少两个主播端的音频流合成一路音频流；确定所述至少两个主播端的播放状态信息；生成携带有所述至少两个主播端的播放状态信息的一路视频流；基于实时消息传输协议对所述音频流和所述视频流进行封装得到直播间的数据流；对所述直播间的数据流进行处理，得到所述至少两个主播端的播放状态信息。

当然,本发明实施例所提供的一种计算机可读存储介质,其计算机可执行指令不限于如上所述的方法操作,还可以执行本发明实施例任意实施例所提供的音频播放状态处理方法中的相关操作。

通过以上关于实施方式的描述，所属领域的技术人员可以清楚地了解到，本发明实施例可借助软件及必需的通用硬件来实现，当然也可以通过硬件实现，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明实施例的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在计算机可读存储介质中，如计算机的软盘、只读存储器(Read-Only Memory,ROM)、随机存取存储器(Random Access Memory,RAM)、闪存(FLASH)、硬盘或光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明实施例各个实施例所述的方法。

值得注意的是，上述搜索装置的实施例中，所包括的各个单元和模块只是按照功能逻辑进行划分的，但并不局限于上述的划分，只要能够实现相应的功能即可；另外，各功能单元的具体名称也只是为了便于相互区分，并不用于限制本发明实施例的保护范围。

注意，上述仅为本发明实施例的较佳实施例及所运用技术原理。本领域技术人员会理解，本发明实施例不限于这里所述的特定实施例，对本领域技术人员来说能够进行各种明显的变化、重新调整和替代而不会脱离本发明实施例的保护范围。因此，虽然通过以上实施例对本发明实施例进行了较为详细的说明，但是本发明实施例不仅仅限于以上实施例，在不脱离本发明实施例构思的情况下，还可以包括更多其他等效实施例，而本发明实施例的范围由所附的权利要求范围决定。