直播连麦中音视频合流处理方法、设备及存储介质

技术领域

本申请涉及多媒体处理技术领域，尤其涉及一种直播连麦中音视频合流处理方法、设备及存储介质。

背景技术

随着直播行业的发展，各大直播服务平台推出了直播连麦服务。目前，直播连麦形式已经从主播与观众之间的直播连麦形式发展到主播之间的直播连麦形式，主播之间的直播连麦形式可以有效提升直播间的留存率、活跃度和转化率。

在主播之间进行直播连麦的情况下，合流服务器可以从内容分发网络（ContentDelivery Network，CDN）中拉取参与直播连麦的各主播端的直播数据，对这些直播数据进行合流，并将合流后的直播数据推送给相应直播间的观众。然而，合流后的直播数据在观众端播放时，容易出现音画不同步、杂音等各种问题，影响了直播效果。

发明内容

本申请的多个方面提供一种直播连麦中音视频合流处理方法、设备及存储介质，用以解决合流后的直播数据在观众端播放时，容易出现音画不同步、杂音等各种问题。

本申请实施例提供一种直播连麦中音视频合流处理方法，应用于合流服务器，该方法包括：响应目标主播端与其它主播端的连麦，向内容分发网络CDN中的目标CDN节点发送第一拉流请求，以请求目标主播端的实时直播数据；接收目标CDN节点根据第一拉流请求发送的目标主播端的实时直播数据；在无法对目标主播端的实时直播数据解码时，向目标主播端发送第一关键帧请求，以请求目标主播端生成并提供解码所需的第一视频关键帧；自接收到第一视频关键帧开始，对目标主播端后续可解码的实时直播数据和其它主播端的可解码的实时直播数据进行合流处理，以得到合流直播数据。

本申请实施例还提供一种直播连麦中音视频合流处理方法，应用于内存分发网络CDN节点，该方法包括：接收合流服务器在目标主播端与其它主播端连麦时发送的第一拉流请求，第一拉流请求用于请求目标主播端的实时直播数据；根据第一拉流请求，向合流服务器返回目标主播端的实时直播数据，以使所述合流服务器在无法对所述实时直播数据解码时，自接收到所述目标主播端提供的第一视频关键帧开始，对所述目标主播端后续可解码的实时直播数据和所述其它主播端的可解码的实时直播数据进行合流处理，以得到合流直播数据；其中，所述目标主播端在接收所述合流服务器发送的第一关键帧请求时返回的所述第一视频关键帧。

本申请实施例还提供一种电子设备，包括：存储器和处理器；存储器，用于存储计算机程序；处理器耦合至存储器，用于执行计算机程序以用于执行直播连麦中音视频合流处理方法中的步骤。

本申请实施例还提供一种存储有计算机程序的计算机可读存储介质，当计算机程序被处理器执行时，致使处理器能够实现直播连麦中音视频合流处理方法中的步骤。

本申请实施例提供一种直播连麦中音视频合流处理方法、设备及存储介质，在本申请实施例中，在目标主播端与其它主播端的连麦的情况下，合流服务器从内容分发网络CDN中拉取目标主播端的实时直播数据；在无法对目标主播端的实时直播数据解码时，请求获取目标主播端提供解码所需的视频关键帧；自接收到视频关键帧开始，对目标主播端后续可解码的实时直播数据和其它主播端的可解码的实时直播数据进行合流处理，以得到合流直播数据。由此，提供一种新的直播数据合流方式，相比于从合流服务器的音视频缓冲区拉取缓存的直播数据，使用实时直播数据进行合流可以解决合流数据之间的时间同步问题，进而得到的合流直播数据在观众端播放时，能够极大地降低出现音画不同步、杂音等各种问题的概率，保证了直播效果；另外，在获取到的实时直播数据无法解码时，主动向主播端请求解码所需的视频关键帧，及时对实时直播数据进行解码、合流和播放，有利于满足直播连麦的响应延迟，具有更好的用户体验。

附图说明

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

图1为传统的直播系统的架构图；

图2为一种示例性的合流过程图；

图3为一种示例性的拉取的音视频帧；

图4为本申请实施例提供的一种直播连麦中音视频合流处理方法的交互图；

图5为本申请实施例提供的另一种直播连麦中音视频合流处理方法的交互图；

图6为本申请实施例提供的另一种直播连麦中音视频合流处理方法的交互图；

图7为另一种示例性的合流过程图；

图8为一种示例性的拉取的音视频帧；

图9为本申请实施例提供的一种直播连麦中音视频合流处理方法的流程图；

图10为本申请实施例提供的一种直播连麦中音视频合流处理装置的结构示意图；

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

具体实施方式

为使本申请的目的、技术方案和优点更加清楚，下面将结合本申请具体实施例及相应的附图对本申请技术方案进行清楚、完整地描述。显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

需要说明的是，本申请所涉及的用户信息（包括但不限于用户设备信息、用户个人信息等）和数据（包括但不限于用于分析的数据、存储的数据、展示的数据等），均为经用户授权或者经过各方充分授权的信息和数据，并且相关数据的收集、使用和处理需要遵守相关国家和地区的相关法律法规和标准，并提供有相应的操作入口，供用户选择授权或者拒绝。

随着直播行业的发展，各大直播服务平台推出了直播连麦服务。目前，直播连麦形式已经从主播与观众之间的直播连麦形式发展到主播之间的直播连麦形式，主播之间的直播连麦形式可以有效提升直播间的留存率、活跃度和转化率。

在主播之间进行直播连麦的情况下，合流服务器可以从内容分发网络（ContentDelivery Network，CDN）中拉取参与直播连麦的各主播端的直播数据，对这些直播数据进行合流，并将合流后的直播数据推送给相应直播间的观众。然而，合流后的直播数据在观众端播放时，容易出现音画不同步、杂音等各种问题，影响了直播效果。

为此，本申请实施例提供一种直播连麦中音视频合流处理方法、设备及存储介质，在本申请实施例中，在目标主播端与其它主播端的连麦的情况下，合流服务器从内容分发网络CDN中拉取目标主播端的实时直播数据；在无法对目标主播端的实时直播数据解码时，请求获取目标主播端提供解码所需的视频关键帧；自接收到视频关键帧开始，对目标主播端后续可解码的实时直播数据和其它主播端的可解码的实时直播数据进行合流处理，以得到合流直播数据。由此，提供一种新的直播数据合流方式，相比于从合流服务器的音视频缓冲区拉取缓存的直播数据，使用实时直播数据进行合流可以解决合流数据之间的时间同步问题，进而得到的合流直播数据在观众端播放时，能够极大地降低出现音画不同步、杂音等各种问题的概率，保证了直播效果；另外，在获取到的实时直播数据无法解码时，主动向主播端请求解码所需的视频关键帧，及时对实时直播数据进行解码、合流和播放，有利于满足直播连麦的响应延迟，具有更好的用户体验。

图1为传统的直播系统的架构图。参见图1，该直播系统包括主播端、观众端、CDN、直播服务器、连麦服务器和合流服务器。其中，CDN分别与主播端、观众端、合流服务器通信连接；直播服务器分别与主播端、观众端通信连接；连麦服务器分别与各个主播端或各个观众端通信连接。

其中，主播端例如包括但不限于：手机、平板电脑、台式计算机、可穿戴式智能设备等。主播端的数量为多个，例如，图1中包括主播端1、主播端2……主播端n等n个主播端，n为大于1的正整数。

主播端产生的直播数据以推流方式推送到CDN的一个CDN节点上，该CDN节点可以缓存主播端产生的直播数据，以及该CDN节点将直播数据分发给其他CDN节点进行缓存，以供各地的观众端就近获取主播端的直播数据并进行播放观看。

其中，观众端例如包括但不限于：手机、平板电脑、台式计算机、可穿戴式智能设备等。观众端的数量为多个，例如，图1中包括观众端1……观众端m等m个主播端，m为正整数。观众端以拉流方式就近访问一个CDN节点，以从CDN中拉取想要观看的主播的直播数据，并进行播放观看。

其中，CDN依靠部署在各地的CDN节点，使用户就近获取所需内容，降低网络拥塞，提高用户访问的响应速度和命中率。各个CDN节点所处位置可以按照实际应用需求灵活设置，任一CDN节点例如可以是终端设备或服务器。终端设备例如包括但不限于：平板电脑、台式计算机、可穿戴式智能设备、智能家居设备等。服务器例如包括但不限于：单个服务器或多个服务器组成的分布式服务器集群。应当理解的是，图1仅是一种内容分发网络的示意图，本申请实施例不对图1中包括的CDN节点的数量进行限定，也不对图1中CDN节点之间的位置关系进行限定。

其中，直播服务器负责普通的直播间管理、CDN节点分配等。连麦服务器用于建立至少两个主播端之间的直播连麦，或者主播端与观众端之间的直播连麦。合流服务器是具有合流功能的服务器，用于从CDN节点拉取至少两路直播数据，对至少两路直播数据进行合流处理，得到合流直播数据，以及将合流直播数据以推流方式推送到一个CDN节点，以供CDN节点缓存并分发给其他CDN节点进行缓存，为各个观众端就近拉取合流直播数据提供基础。

在传统的直播系统中，CDN节点提供缓存空间，主播端推送的直播数据缓存在CDN节点的缓存空间中。当某个观众进入该主播的直播间时，观众端可以就近访问CDN节点以拉取CDN节点中缓冲区的所缓存的直播数据进行播放并观看，这样能够保证观众用户观看直播的实时性，利用缓存机制，使播放体验更加流畅，降低播放时延。

在主播端与观众端之间的直播连麦场景中，观众端也会产生直播数据，观众端推送的直播数据缓存在CDN节点的缓存空间中。合流服务器为参与连麦的主播端和观众端分别分配音视频缓冲区，合流服务器从CDN节点的缓存空间拉取主播端的直播数据并缓存到对应的音视频缓冲区中，合流服务器从CDN节点的缓存空间拉取观众端的直播数据并缓存到对应的音视频缓冲区中，接着，合流服务器从对应的音视频缓冲区获取主播端的直播数据和观众端的直播数据进行合流处理，得到合流直播数据。合流服务器将合流直播数据推送给一个CDN节点进行缓存，并由该CDN节点分发给其他CDN节点进行缓存，这样，观众端可以从CDN节点获取合流直播数据进行播放观看。

由于在观众与主播连麦之后，CDN节点的缓存空间才会缓存观众的直播数据，相对来说，CDN节点的缓存空间缓存的观众的直播数据的数据量较少，合流服务器拉取到的是观众最新的直播数据，合流服务器在音视频缓冲区中缓存的观众的直播数据和主播的直播数据较为同步，相应的，合流直播数据在播放时不会出现音画不同步、杂音等各种问题，合流直播数据在观众端的直播效果较好。

在主播端与主播端之间的直播连麦场景中，当主播之间进行直播连麦时，合流服务器为参与连麦的主播端分别分配音视频缓冲区，合流服务器从缓存有音视频数据的CDN节点的缓存空间拉取各个主播端的直播数据并缓存到对应的音视频缓冲区中，接着，合流服务器从对应的音视频缓冲区获取各个主播端的直播数据进行合流处理，得到合流直播数据。合流服务器将合流直播数据推送给一个CDN节点进行缓存，并由该CDN节点分发给其他CDN节点进行缓存，这样，观众端可以从CDN节点获取合流直播数据进行播放观看。

由于各主播一直在直播，各主播的直播数据已经缓存在CDN节点的缓存空间，CDN节点所缓存的各个主播端的直播数据的数据量较大。在合流初期，为了保证拉到的直播数据可以立即播放，合流服务器默认从CDN节点的缓存空间中自最近的视频关键帧开始拉取一段的直播数据（包括一些历史直播流数）并缓存在音视频缓冲区中，容易导致在合流的初始阶段会拉取到大量的过去几秒内缓存的直播数据。拉取的直播数据会短时间内填满合流服务器的音视频缓冲区，造成音视频缓冲区出现堆积。如果快速消耗音视频缓冲区中的直播数据，会带来快进问题，导致合流初期不会的播放体验。如果不快速消耗音视频缓冲区中的直播数据，容易导致合流服务器从各个音视频缓冲区获取的多路直播数据之间存在较大的不同步，相应的，合流直播数据在播放时会出现音画不同步、杂音等各种问题，合流直播数据在观众端的直播效果较差。

音视频缓冲区的容量大小通常为一个GOP（Group of picture图像组）。GOP指两个关键帧之间的距离。GOP是一组连续的视频帧，通常包括一个I帧（关键帧）和若干个P帧（预测帧）和B帧（双向预测帧）。在直播过程中，如果GOP的大小过大，会导致接收端在等待I帧的到来时需要等待相对较长的时间，这就会增加视频的延迟。因此，降低GOP大小可以在一定程度上减小视频的延迟。

通常，音视频缓冲区最多可以缓存4秒钟的视频数据，这个GOP中包含一个关键帧和若干其它帧；随着时间推移，音视频缓冲区中的数据不断地被消费和不断地被更新，每当来一帧新的数据就存进来，直到存储一个GOP；当下一个GOP的第一帧出现时，就将整个音视频缓冲区清空，从新的GOP的第一帧开始，重新缓冲该新的GOP。数据传输时，一个帧会被切分为多个数据包，但存储或处理都是以“帧”为单位的。在此说明，音视频缓冲区中缓存音视频数据的时间长度可根据应用需求灵活而定，4秒钟是一个示例，并不限于此。

以图2为例，n个主播的直播数据推送到CDN节点中，各个CDN节点在缓存空间中缓存各个主播的直播数据，这样，当各主播的观众进入主播的直播间后，观众端可以从CDN节点拉取所进入直播间的主播的直播数据，并进行播放观看。

当主播1和主播2进行直播连麦的情况下，合流服务器从相应的CDN节点的缓存空间中拉取直播数据1和直播数据2，并分别缓存在合流服务器对应的音视频缓冲区中，合流服务器从对应的音视频缓冲区获取直播数据1和直播数据2进行合流处理，得到合流直播数据。合流服务器将合流直播数据推送给一个CDN节点，以由该CDN节点在缓存空间中缓存，并分发给其他CDN节点由其他CDN节点在各自的缓存空间中缓存。这样，主播1的观众或主播2的观众通过观众端从CDN节点拉取主播1和主播2的合流直播数据，并进行播放观看。

在主播1和主播2已经直播连麦一段时间之后，随着时间推移，主播n也加入主播1和主播2之间的直播活动，也即主播n分别与主播1和主播2进行直播连麦。合流服务器从相应的CDN节点的缓存空间中拉取直播数据n，直播数据n包括自最近的视频关键帧开始的一段的直播数据。合流服务器将直播数据n和合流主播1和主播2的直播数据得到的合流直播数据进行合流，得到主播1、主播2和主播n的合流直播数据，并将该到主播1、主播2和主播n的合流直播数据推送给一个CDN节点，以由该CDN节点在缓存空间中缓存，并分发给其他CDN节点由其他CDN节点在各自的缓存空间中缓存。这样，主播1的观众、主播2的观众、主播n的观众通过观众端从CDN节点拉取主播1、主播2和主播n的合流直播数据，并进行播放观看。

由于直播数据n包括自最近的视频关键帧开始的一段的直播数据，直播数据n与主播2和主播n的直播数据容易不同步，进而导致合流直播数据在播放时会出现音画不同步、杂音等各种问题，合流直播数据在观众端的直播效果较差。以图3为例，图3中的时间轴沿着箭头方向时间不断推移，随着时间推移，合流服务器从CDN节点的缓存空间拉取的音视频帧越来越多，按照时间先后顺序，从CDN节点的缓存空间拉取的视频帧分别为：V1（Key Frame,视频关键帧）、V2、V3、V4……Vt、Vt+1、Vt+2、Vt+3，其中，t为正整数；按照时间先后顺序，从CDN节点的缓存空间拉取的音频帧分别为：A1、A2、A3、A4、A5、A6、A7、A8、……At、At+1、At+2、At+3、At+4、At+5。在合流初期，合流服务器的音视频缓冲区短时间被填满，造成数据堆积，也即图3中虚线框内的数据为一个GOP数据，在虚线框中的数据表示缓存在音视频缓冲区的数据，虚线框外的数据表示还未缓存到音视频缓冲区中的数据。虚线框中的数据包括主播n一些的历史直播数据，这是导致合流直播数据不同步的关键原因。

以下结合附图，详细说明本申请各实施例提供的技术方案。

图4为本申请实施例提供的一种直播连麦中音视频合流处理方法的交互图。如图4所示，该方法可以包括以下步骤：

101、合流服务器响应目标主播端与其它主播端的连麦，向内容分发网络CDN中的目标CDN节点发送第一拉流请求，以请求目标主播端的实时直播数据。

具体而言，合流服务器可以是具有合流功能的云端合流服务器，也可以是具有合流功能的常规合流服务器，对此不做限制。可以一个主播对应一个合流服务器，也可以多个主播共享同一个合流服务器，对此不做限制。在合流服务器上，会为每个主播分配音视频缓冲区，合流之前的直播数据会存储到对应音视频缓冲区。

具体而言，可以有多个主播端进行直播连麦，目标主播端是参与直播连麦的多个主播端的一个，其它主播端是多个主播端中除目标主播端之外的主播端，其它主播端的数量可以是一个或多个。

实际应用中，目标主播端可以向连麦服务器发送连麦请求，连麦请求用于请求与其它主播端进行连麦，连麦服务器将连麦请求转发给其它主播端。若接收到其他主播端发送的指示同意连麦的连麦响应，连麦服务器确认目标主播端与其它主播端成功连麦；若接收到其他主播端发送的指示不同意连麦的连麦响应，连麦服务器确认目标主播端与其它主播端连麦失败。连麦服务器确认目标主播与其他主播成功连麦之后，可以通知合流服务器。

在本实施例中，合流服务器响应目标主播端与其它主播端的连麦，向内容分发网络中的目标CDN节点发送第一拉流请求，以请求目标主播端的实时直播数据。实时直播数据是相对于CDN节点上已经缓存在音视频缓冲区中的直播数据来说的，实时直播数据是指CDN节点最新接收到的且尚未缓存至其音视频缓冲区中的直播数据，例如以图3中所示的直播数据为例，实时直播数据可以是位于缓冲区之外的第t+1时刻的音频数据和视频数据。

具体而言，目标CDN节点是内容分发网络中与合流服务器连接的CDN节点，可以是内容分发网络中的任一CDN节点，第一拉流请求可以理解为请求目标CDN节点推送目标主播端的实时直播数据的拉流请求。目标主播端的实时直播数据可以理解为目标CDN节点实时推送的直播数据，相比于从合流服务器的音视频缓冲区拉取缓存的直播数据，实时请求目标CDN节点推送的实时直播数据的实时性更好。在此说明，如果目标CND节点上不存在目标主播端的实时直播数据，目标CDN节点会从内容分发网络中的其它CDN节点拉取目标主播端的实时直播数据，如果在其它CDN节点上拉取不到目标主播端的实时直播数据，会触发回流操作，从源站拉取目标主播端的实时直播数据。

可选的，为了准确拉流，合流服务器响应目标主播端与其它主播端的连麦，向内容分发网络CDN中的目标CDN节点发送第一拉流请求，以请求目标主播端的实时直播数据的一种实现方式为：接收连麦服务器发送的连麦通知消息，连麦通知消息中包括成功连麦的目标主播端的标识信息；根据目标主播端的标识信息，生成包含拉流参数的第一拉流请求，拉流参数用于指示下发目标主播端的实时直播数据；将第一拉流请求发送给CDN中的目标CDN节点，以请求目标主播端的实时直播数据。

具体而言，合流服务器在接收到连麦通知消息后，从连麦通知消息获取目标主播端的标识信息。需要在第一拉流请求中添加拉流参数，拉流参数用于指示下发目标主播端的实时直播数据，另外，拉流参数还能禁止从合流服务器的音视频缓冲区拉取缓存的直播数据。

实际应用中，目标主播端的标识信息例如包括但不限于：目标主播端的主播名称、IP地址（Internet Protocol Address，互联网协议地址）、目标主播端的统一资源定位器（uniform resource locator，URL）。

作为一种示例，根据目标主播端的标识信息，生成包含拉流参数的第一拉流请求时，在目标主播端的URL中添加拉流参数，根据添加拉流参数的URL，生成第一拉流请求。

作为另一种示例，根据目标主播端的标识信息，生成包含拉流参数的第一拉流请求时，根据目标主播的URL生成初始拉流请求，在初始拉流请求中添加新字段，用新字段承载拉流参数，以得到第一拉流请求。

102、合流服务器接收目标CDN节点根据第一拉流请求发送的目标主播端的实时直播数据。

具体而言，合流服务器向目标CDN节点发送第一拉流请求后，目标CDN节点响应第一拉流请求获取目标主播端的实时直播数据，并向合流服务器推送目标主播端的实时直播数据。

103、合流服务器在无法对目标主播端的实时直播数据解码时，向目标主播端发送第一关键帧请求，以请求目标主播端生成并提供解码所需的第一视频关键帧。

实际应用中，若目标主播端的实时直播数据解码包括视频关键帧，则合流服务器可以对目标主播端的实时直播数据解码成功。若目标主播端的实时直播数据解码不包括视频关键帧，则合流服务器需要请求目标主播端发送解码所需的视频关键帧（在此称作为第一视频关键帧）。

实际应用中，合流服务器在无法对目标主播端的实时直播数据解码时，可以直接向目标主播端发送第一关键帧请求，以请求目标主播端生成并提供解码所需的第一视频关键帧。或者，合流服务器在无法对目标主播端的实时直播数据解码时，向CDN中目标CDN节点发送第一关键帧请求，目标CDN节点向目标主播端转发第一关键帧请求，以请求目标主播端生成并提供解码所需的第一视频关键帧。

可选的，为了准确高效地请求第一视频关键帧，合流服务器在无法对目标主播端的实时直播数据解码时，向CDN中目标CDN节点发送FIR（Full Intra Request，完整的内部请求）消息，以使目标CDN节点在确定FIR消息的发送方为合流服务器的情况下将FIR消息转发至目标主播端。可以理解的是，FIR信息是一种具体的第一关键帧请求，该FIR信息指示请求目标主播端生成并提供解码所需的第一视频关键帧。其中，目标CDN节点可能与目标主播端直连，则可以直接将FIR消息转发给目标主播端；或者，目标CDN节点不与目标主播端直连，则可以经过内容分发网络中的其它CDN节点进行中转，进而将FIR消息转发给目标主播端。

104、合流服务器自接收到第一视频关键帧开始，对目标主播端后续可解码的实时直播数据和其它主播端的可解码的实时直播数据进行合流处理，以得到合流直播数据。

具体而言，在合流服务器接收到来自于目标主播端的第一视频关键帧后，说明可以对目标主播端在第一视频关键帧之后的实时直播数据（也即后续的实时直播数据）进行解码。合流服务器获取目标主播端后续可解码的实时直播数据。另外，连麦服务器发送的连麦通知消息中还包括目标主播端所成功连麦的其它主播端的标识信息，合流服务器根据其它主播端的标识信息获取其它主播端的可解码的实时直播数据。最后，合流服务器对目标主播端后续可解码的实时直播数据和其它主播端的可解码的实时直播数据进行合流处理，以得到合流直播数据。

实际应用中，合流服务器可以记录接收到第一视频关键帧的时间，在此将所记录的时间称作为第一目标时间。以第一目标时间为依据，获取参与合流的直播数据。于是，可选的，为准确高效地合流，合流服务器执行104步骤的实现方式为：自接收到第一视频关键帧开始，对目标主播端在第一目标时间之后的实时直播数据进行解码，以得到目标主播端在第一目标时间之后的直播解码数据，第一目标时间是第一视频关键帧的接收时间；将目标主播端在第一目标时间之后的直播解码数据和其它主播端在第一目标时间之后的直播解码数据进行合流，以得到合流结果数据；对合流结果数据进行编码，以得到合流直播数据。

实际应用时，对合流直播数据中各个主播的直播间画面的画面布局信息不做限制，例如，位于承载合流直播数据的画面的中心、左上角或右下角是哪个主播的直播数据，不做限制。

可选的，为了提高直播效果，将目标主播端在第一目标时间之后的直播解码数据和其它主播端在第一目标时间之后的直播解码数据进行合流，以得到合流结果数据的实现方式为：根据目标主播端的画面布局信息，确定目标主播端与其它主播端之间的相对画面位置；根据相对画面位置，将目标主播端在第一目标时间之后的直播解码数据和其它主播端在第一目标时间之后的直播解码数据进行合流，以得到合流结果数据。

具体而言，根据目标主播端的画面布局信息，确定目标主播端与其它主播端之间的相对画面位置。例如，目标主播端的画面布局信息指示该目标主播端的直播间画面位于承载合流直播数据的画面的中心，则目标主播端与其它主播端之间的相对画面位置指示其它主播端的直播间画面位于承载合流直播数据的画面的左上角或右下角。可以理解的是，相对画面位置可以指示各个主播端的直播间画面位于承载合流直播数据的画面中的位置信息。基于相对画面位置控制承载合流直播数据的画面中各主播对应的直播间画面的布局。

在一些可选的实施例中，合流服务器在接收到第一视频关键帧的情况下，还可以丢弃在第一视频关键帧之前接收到目标主播端的实时直播数据，进一步使得合流直播数据在观众端播放时，能够极大地降低出现音画不同步、杂音等各种问题的概率。在此说明，直播数据中的音频数据和视频数据是分开传输的，合流服务器在接收到第一视频关键帧之前，由于无法解法直播数据中的视频数据，所以在接收到视频数据时，可以直接将视频数据丢弃，而关于音频数据可以先缓存至音频数据对应的缓冲区中，在接收到第一视频关键帧的情况下，根据第一视频关键帧中携带的时间信息与缓冲区中的音频数据进行时间对齐，从而确定出第一视频关键帧之前的音频数据，并将之前的音频数据丢弃，最终达到丢弃第一视频关键帧之前接收到的实时直播数据的目的。

在一些可选的实施例中，将合流直播数据发送至CDN中，以供各主播端的观众从CDN中拉取合流直播数据。观众通过其观众端从CDN拉取并播放合流直播数据，满足观众观看各主播直播连麦的需求，有效提升直播间的留存率、活跃度和转化率。

本申请实施例提供的技术方案，在目标主播端与其它主播端的连麦的情况下，合流服务器从内容分发网络CDN中拉取目标主播端的实时直播数据；在无法对目标主播端的实时直播数据解码时，请求获取目标主播端提供解码所需的视频关键帧；自接收到视频关键帧开始，对目标主播端后续可解码的实时直播数据和其它主播端的可解码的实时直播数据进行合流处理，以得到合流直播数据。由此，提供一种新的直播数据合流方式，相比于从合流服务器的音视频缓冲区拉取缓存的直播数据，使用实时直播数据进行合流可以解决合流数据之间的时间同步问题，进而得到的合流直播数据在观众端播放时，能够极大地降低出现音画不同步、杂音等各种问题的概率，保证了直播效果；另外，在获取到的实时直播数据无法解码时，主动向主播端请求解码所需的视频关键帧，及时对实时直播数据进行解码、合流和播放，有利于满足直播连麦的响应延迟，具有更好的用户体验。

实际应用中，目标主播仅仅与一个其他主播段进行连麦，则在合流过程中需要拉取两个主播各自的实时直播数据。为此，介绍两个主播直播连麦时的合流方式。图5为本申请实施例提供的另一种直播连麦中音视频合流处理方法的交互图。如图5所示，该方法可以包括以下步骤：

201、合流服务器响应目标主播端与其它主播端的连麦，向内容分发网络CDN中的目标CDN节点发送第一拉流请求，以请求目标主播端的实时直播数据。

202、合流服务器接收目标CDN节点根据第一拉流请求发送的目标主播端的实时直播数据。

203、合流服务器在无法对目标主播端的实时直播数据解码时，经目标CDN向目标主播端发送第一关键帧请求，以请求目标主播端生成并提供解码所需的第一视频关键帧。

关于步骤201至203的实现方式可以参见前述实施例中相关介绍，在此不再赘述。

204、合流服务器向CDN中的目标CDN节点发送第二拉流请求，以请求其它主播端的实时直播数据。

本实施例对步骤201和步骤204的执行顺序不做限制，例如，步骤201和步骤204同步或异步执行。

205、合流服务器接收目标CDN节点根据第二拉流请求发送的其它主播端的实时直播数据。

具体而言，第二拉流请求可以理解为请求目标CDN节点推送目标主播端的实时直播数据的拉流请求。目标主播端的实时直播数据可以理解为目标CDN节点实时推送的直播数据，相比于从合流服务器的音视频缓冲区拉取缓存的直播数据，实时请求目标CDN节点推送的实时直播数据的实时性更好。

可选的，为了准确拉流，合流服务器向内容分发网络CDN中的目标CDN节点发送第二拉流请求，以请求其它主播端的实时直播数据的一种实现方式为：接收连麦服务器发送的连麦通知消息，连麦通知消息中包括成功连麦的其他主播端的标识信息；根据其他主播端的标识信息，生成包含拉流参数的第二拉流请求，拉流参数用于指示下发其他主播端的实时直播数据；将第二拉流请求发送给CDN中的目标CDN节点，以请求其它主播端的实时直播数据。

具体而言，合流服务器在接收到连麦通知消息后，从连麦通知消息获取其它主播端的标识信息。需要在第二拉流请求中添加拉流参数，拉流参数用于指示下发其它主播端的实时直播数据，另外，拉流参数还能禁止从合流服务器的音视频缓冲区拉取缓存的直播数据。

实际应用中，其他主播端的标识信息例如包括但不限于：其他主播端的主播名称、IP地址、其他主播端的URL。

作为一种示例，根据其他主播端的标识信息，生成包含拉流参数的第二拉流请求时，在其他主播端的URL中添加拉流参数，根据添加拉流参数的URL，生成第二拉流请求。

作为另一种示例，根据其他主播端的标识信息，生成包含拉流参数的第二拉流请求时，根据其他主播的URL生成初始拉流请求，在初始拉流请求中添加新字段，用新字段承载拉流参数，以得到第二拉流请求。

206、合流服务器在无法对其它主播端的实时直播数据解码时，经目标CDN节点向其它主播端发送第二关键帧请求，以请求其它主播端生成并提供解码所需的第二视频关键帧。

207、合流服务器自接收到第二视频关键帧开始，对其它主播端在第二目标时间之后的实时直播数据进行解码，以得到其它主播端在第二目标时间之后的直播解码数据，第二目标时间是第二视频关键帧的接收时间。

在此说明，在本申请实施例中，并不限定发送第一拉流请求和第二拉流请求的先后顺序，可以并行执行，也可以顺序执行。相应地，本申请实施例也不限定发送第一关键帧请求和第二关键帧请求的先后顺序，具体可视直播情况而定，同理，第一视频关键帧和第二视频关键帧返回的先后顺序也不做限定。

实际应用中，若其它主播端的实时直播数据解码包括视频关键帧，则合流服务器可以对其它主播端的实时直播数据解码成功。若其它主播端的实时直播数据解码不包括视频关键帧，则合流服务器需要请求其它主播端发送解码所需的视频关键帧（在此称作为第二视频关键帧）。

实际应用中，合流服务器在无法对其它主播端的实时直播数据解码时，可以直接向其它主播端发送第二关键帧请求，以请求其它主播端生成并提供解码所需的第二视频关键帧。或者，合流服务器在无法对其它主播端的实时直播数据解码时，向CDN中目标CDN节点发送第二关键帧请求，目标CDN节点向其它主播端转发第二关键帧请求，以请求其它主播端生成并提供解码所需的第二视频关键帧。

可选的，为了准确高效地请求第二视频关键帧，合流服务器在无法对其它主播端的实时直播数据解码时，向CDN中目标CDN节点发送FIR（Full Intra Request，完整的内部请求）消息，以使目标CDN节点在确定FIR消息的发送方为合流服务器的情况下将FIR消息转发至其它主播端。可以理解的是，FIR信息是一种具体的第二关键帧请求，该FIR信息指示请求其它主播端生成并提供解码所需的第二视频关键帧。

实际应用中，合流服务器可以记录接收到第二视频关键帧的时间，在此将所记录的时间称作为第二目标时间。以第二目标时间为依据，利用第二视频关键帧对对其它主播端在第二目标时间之后的实时直播数据进行解码，以得到其它主播端在第二目标时间之后的直播解码数据。

208、合流服务器自接收到第一视频关键帧开始，对目标主播端后续可解码的实时直播数据和其它主播端的可解码的实时直播数据进行合流处理，以得到合流直播数据。

实际应用中，对第二目标时间与第一目标时间的时间先后顺序不做限定。若第二目标时间早于第一目标时间，则合流服务器自接收到第一视频关键帧开始，对目标主播端后续可解码的实时直播数据和其它主播端的可解码的实时直播数据进行合流处理，以得到合流直播数据。若第二目标时间晚于第一目标时间，则合流服务器自接收到第二视频关键帧开始，对目标主播端后续可解码的实时直播数据和其它主播端的可解码的实时直播数据进行合流处理，以得到合流直播数据。关于合流的实现方式可以参见前述实施例，在此不再赘述。

本申请实施例提供的技术方案，在目标主播端与一个其它主播端的连麦的情况下，合流服务器从内容分发网络CDN中拉取目标主播端和其它主播端的实时直播数据；在无法对目标主播端或其它主播端的实时直播数据解码时，请求获取目标主播端或其它主播端提供解码所需的视频关键帧；自接收到视频关键帧开始，对目标主播端和其它主播端后续可解码的实时直播数据进行合流处理，以得到合流直播数据。由此，提供一种新的直播数据合流方式，相比于从合流服务器的音视频缓冲区拉取缓存的直播数据，使用实时直播数据进行合流可以解决合流数据之间的时间同步问题，进而得到的合流直播数据在观众端播放时，能够极大地降低出现音画不同步、杂音等各种问题的概率，保证了直播效果；另外，在获取到的实时直播数据无法解码时，主动向主播端请求解码所需的视频关键帧，及时对实时直播数据进行解码、合流和播放，有利于满足直播连麦的响应延迟，具有更好的用户体验。

实际应用中，目标主播与多个其他主播段进行连麦，则在合流过程中需要拉取两个以上的主播各自的实时直播数据。为此，介绍两个以上的主播直播连麦时的合流方式。图6为本申请实施例提供的另一种直播连麦中音视频合流处理方法的交互图。如图6所示，该方法可以包括以下步骤：

301、合流服务器响应目标主播端与其它主播端的连麦，向内容分发网络CDN中的目标CDN节点发送第一拉流请求，以请求目标主播端的实时直播数据。

302、合流服务器接收目标CDN节点根据第一拉流请求发送的目标主播端的实时直播数据。

303、合流服务器在无法对目标主播端的实时直播数据解码时，经目标CDN节点向目标主播端发送第一关键帧请求，以请求目标主播端生成并提供解码所需的第一视频关键帧。

关于步骤301至303的实现方式可以参见前述实施例中相关介绍，在此不再赘述。

本实施例对步骤201和步骤204的执行顺序不做限制，例如，步骤201和步骤204同步或异步执行。

304、响应目标主播端与至少两个其它主播端的连麦，从CDN中拉取至少两个其它主播端可解码的实时直播数据；并对至少两个其它主播端可解码的实时直播数据进行解码，以得到至少两个其它主播端的直播解码数据；以及从至少两个其它主播端的直播解码数据中，选择至少两个其它主播端各自在第一目标时间之后的直播解码数据。

本实施例对步骤301和步骤304的执行顺序不做限制，例如，步骤301和步骤304同步或异步执行。

具体而言，针对目标主播加入至少两个已经连麦的其他主播的直播活动中，只需要按照步骤301至步骤303拉取目标主播的实时且能解码的实时直播数据。已连麦的其他主播不断地将各自的实时直播数据以推流方式推到CDN中。由于已连麦的其他主播参与直播连麦的时间早于目标主播参与直播连麦，合流服务器已经是获取了已连麦的其他主播对应的视频关键帧。目标主播加入直播连麦之前，合流服务器已经从CDN中实时拉取已连麦的其他主播的实时直播数据，并利用已连麦的其他主播对应的视频关键帧实时对已连麦的其他主播的实时直播数据进行解码，得到其它主播端的直播解码数据。当然已连麦的其他主播的实时直播数据，在最开始参与合流时，也可以采用按照步骤301至步骤303进行数据拉取。其它主播端的实时直播数据会一直解码，从中选择第一目标时间之后的直播解码数据参与合流。

305、合流服务器自接收到第一视频关键帧开始，对目标主播端后续可解码的实时直播数据和其它主播端的可解码的实时直播数据进行合流处理，以得到合流直播数据。

关于步骤305的实现方式可以参见前述实施例中相关介绍，在此不再赘述。

本申请实施例提供的技术方案，在目标主播端与多个其它主播端的连麦的情况下，合流服务器从内容分发网络CDN中拉取目标主播端的实时直播数据；在无法对目标主播端的实时直播数据解码时，请求获取目标主播端提供解码所需的视频关键帧；以及获取至少两个其它主播端各自在第一目标时间之后的直播解码数据；自接收到视频关键帧开始，对目标主播端后续可解码的实时直播数据和其它主播端的可解码的实时直播数据进行合流处理，以得到合流直播数据。由此，提供一种新的直播数据合流方式，这样得到的合流直播数据在观众端播放时，能够极大地降低出现音画不同步、杂音等各种问题的概率，保证了直播效果。

为了更好地理解本申请实施例提供的技术方案，下面结合图7和图8进行说明。

以电商平台的主播之间进行直播连麦为例，主播1、主播2等多个主播已经成功进行了直播连麦。当第n个主播想要加入主播1、主播2等多个主播的直播连麦时，合流服务器从CDN以拉流方式拉取主播n以推流方式推到CDN的实时直播数据。若合流服务器拉起的主播n的实时直播数据没有视频关键帧，则合流服务器向CDN发送FIR请求，合流服务器向主播n的主播端转发FIR请求，主播n的主播端响应FIR请求向CDN发送视频关键帧。CDN将视频关键帧转发给合流服务器。合流服务器丢弃在接收到视频关键帧之前拉取的主播n的实时直播数据，并对自视频关键帧开启开始合流。合流时，对主播n在接收到视频关键帧之后的实时直播数据和主播1、主播2等多个已经连麦的主播的实时直播数据进行合流。合流服务器向CDN推送合流直播数据，以供各主播的观众通过观众端从CDN拉取合流直播数据进行播放观看。

以图8为例，图8中的时间轴沿着箭头方向时间不断推移，随着时间推移，合流服务器从CDN节点的主播n的音视频帧越来越多，其中，虚线框内拉取时间比较早的音视频帧中没有视频关键帧，在接收到Vt+1时，合流服务器触发FIR请求。随着时间推移，合流服务器接收到视频关键帧Vt+3，自视频关键帧Vt+3开始进行合流，而不是从缓冲区内已经缓存的直播数据开始合流，能够极大地降低出现音画不同步、杂音等各种问题的概率，保证了直播连麦的效果。

图9为本申请实施例提供的一种直播连麦中音视频合流处理方法的流程图。应用于内容分发网络CDN节点，该方法包括：

901、接收合流服务器在目标主播端与其它主播端连麦时发送的第一拉流请求，第一拉流请求用于请求目标主播端的实时直播数据。

902、根据第一拉流请求，向合流服务器返回目标主播端的实时直播数据。

在本实施例中，所述合流服务器在无法对所述实时直播数据解码时，自接收到所述目标主播端提供的第一视频关键帧开始，对所述目标主播端后续可解码的实时直播数据和所述其它主播端的可解码的实时直播数据进行合流处理，以得到合流直播数据；其中，所述目标主播端在接收所述合流服务器发送的第一关键帧请求时返回的所述第一视频关键帧。

进一步可选的，上述方法还包括：若接收到合流服务器发送的第一关键帧请求，将第一关键帧请求转发给目标主播端，以请求目标主播端生成并提供解码所需的第一视频关键帧；以及将目标主播端提供的第一视频关键帧发送给合流服务器，以供合流服务器根据第一视频关键帧对目标主播端和其它主播端的实时直播数据进行合流处理。

关于本实施例方法中各步骤的详细实施方式以及有益效果已经在前述实施例中进行了详细描述，此处将不做详细阐述说明。

本申请实施例提供的技术方案，在目标主播端与其它主播端的连麦的情况下，合流服务器从内容分发网络CDN中拉取目标主播端的实时直播数据；在无法对目标主播端的实时直播数据解码时，请求获取目标主播端提供解码所需的视频关键帧；自接收到视频关键帧开始，对目标主播端后续可解码的实时直播数据和其它主播端的可解码的实时直播数据进行合流处理，以得到合流直播数据。由此，提供一种新的直播数据合流方式，相比于从合流服务器的音视频缓冲区拉取缓存的直播数据，使用实时直播数据进行合流可以解决合流数据之间的时间同步问题，进而得到的合流直播数据在观众端播放时，能够极大地降低出现音画不同步、杂音等各种问题的概率，保证了直播连麦效果；另外，在获取到的实时直播数据无法解码时，主动向主播端请求解码所需的视频关键帧，及时对实时直播数据进行解码、合流和播放，有利于满足直播连麦的响应延迟，具有更好的用户体验。

需要说明的是，上述实施例所提供方法的各步骤的执行主体均可以是同一设备，或者，该方法也由不同设备作为执行主体。比如，步骤901至步骤902的执行主体可以为设备A；又比如，步骤901的执行主体可以为设备A，步骤902的执行主体可以为设备B；等等。

另外，在上述实施例及附图中的描述的一些流程中，包含了按照特定顺序出现的多个操作，但是应该清楚了解，这些操作可以不按照其在本文中出现的顺序来执行或并行执行，操作的序号如901、902等，仅仅是用于区分开各个不同的操作，序号本身不代表任何的执行顺序。另外，这些流程可以包括更多或更少的操作，并且这些操作可以按顺序执行或并行执行。需要说明的是，本文中的“第一”、“第二”等描述，是用于区分不同的消息、设备、模块等，不代表先后顺序，也不限定“第一”和“第二”是不同的类型。

图10为本申请实施例提供的一种直播连麦中音视频合流处理装置的结构示意图。该装置应用于合流服务器，参见图10，该装置可以包括：

第一请求模块11，用于响应目标主播端与其它主播端的连麦，向内容分发网络CDN中的目标CDN节点发送第一拉流请求，以请求目标主播端的实时直播数据；

接收模块12，用于接收目标CDN节点根据第一拉流请求发送的目标主播端的实时直播数据；

第二请求模块13，用于在无法对目标主播端的实时直播数据解码时，向目标主播端发送第一关键帧请求，以请求目标主播端生成并提供解码所需的第一视频关键帧；

合流模块14，用于自接收到第一视频关键帧开始，对目标主播端后续可解码的实时直播数据和其它主播端的可解码的实时直播数据进行合流处理，以得到合流直播数据。

进一步可选的，第一请求模块11，具体用于：接收连麦服务器发送的连麦通知消息，连麦通知消息中包括成功连麦的目标主播端的标识信息；根据目标主播端的标识信息，生成包含拉流参数的第一拉流请求，拉流参数用于指示下发目标主播端的实时直播数据；将第一拉流请求发送给CDN中的目标CDN节点，以请求目标主播端的实时直播数据。

进一步可选的，目标主播端的标识信息包括目标主播端的统一资源定位器URL，则第一请求模块11根据目标主播端的标识信息，生成包含拉流参数的第一拉流请求时，具体用于：在目标主播端的URL中添加拉流参数，根据添加拉流参数的URL，生成第一拉流请求；或者根据目标主播的URL生成初始拉流请求，在初始拉流请求中添加新字段，用新字段承载拉流参数，以得到第一拉流请求。

进一步可选的，第二请求模块13具体用于：在无法对目标主播端的实时直播数据解码时，向CDN中目标CDN节点发送完整帧请求FIR消息，以使目标CDN节点在确定FIR消息的发送方为合流服务器的情况下将FIR消息转发至目标主播端。

进一步可选的，合流模块14，具体用于：自接收到第一视频关键帧开始，对目标主播端在第一目标时间之后的实时直播数据进行解码，以得到目标主播端在第一目标时间之后的直播解码数据，第一目标时间是第一视频关键帧的接收时间；将目标主播端在第一目标时间之后的直播解码数据和其它主播端在第一目标时间之后的直播解码数据进行合流，以得到合流结果数据；对合流结果数据进行编码，以得到合流直播数据。

进一步可选的，合流模块14将目标主播端在第一目标时间之后的直播解码数据和其它主播端在第一目标时间之后的直播解码数据进行合流，以得到合流结果数据时，具体用于：根据目标主播端的画面布局信息，确定目标主播端与其它主播端之间的相对画面位置；根据相对画面位置，将目标主播端在第一目标时间之后的直播解码数据和其它主播端在第一目标时间之后的直播解码数据进行合流，以得到合流结果数据。

进一步可选的，第一请求模块11还用于向CDN中的目标CDN节点发送第二拉流请求，以请求其它主播端的实时直播数据；

接收模块12，还用于接收目标CDN节点根据第二拉流请求发送的其它主播端的实时直播数据；

第二请求模块13，还用于在无法对其它主播端的实时直播数据解码时，向其它主播端发送第二关键帧请求，以请求其它主播端生成并提供解码所需的第二视频关键帧；

合流模块14，还用于自接收到第二视频关键帧开始，对其它主播端在第二目标时间之后的实时直播数据进行解码，以得到其它主播端在第二目标时间之后的直播解码数据，第二目标时间是第二视频关键帧的接收时间。

进一步可选的，合流模块14，还用于响应目标主播端与至少两个其它主播端的连麦，从CDN中拉取至少两个其它主播端可解码的实时直播数据；对至少两个其它主播端可解码的实时直播数据进行解码，以得到至少两个其它主播端的直播解码数据；从至少两个其它主播端的直播解码数据中，选择至少两个其它主播端各自在第一目标时间之后的直播解码数据。

进一步可选的，合流模块14，还用于执行以下至少一种操作：在接收到第一视频关键帧的情况下，丢弃在第一视频关键帧之前接收到目标主播端的实时直播数据；将合流直播数据发送至CDN中，以供各主播端的观众从CDN中拉取合流直播数据。

图10所示的装置可以执行图2所示的方法，其实现原理和技术效果不再赘述。对于上述实施例中的图10所示的装置其中各个模块、单元执行操作的具体方式已经在有关该方法的实施例中进行了详细描述，此处将不做详细阐述说明。

图11为本申请实施例提供的一种电子设备的结构示意图。如图11所示，该电子设备包括：存储器21和处理器22；

存储器21，用于存储计算机程序，并可被配置为存储其它各种数据以支持在计算平台上的操作。这些数据的示例包括用于在计算平台上操作的任何应用程序或方法的指令，联系人数据，电话簿数据，消息，图片，视频等。

存储器21可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器（Static Random-AccessMemory，SRAM），电可擦除可编程只读存储器（Electrically Erasable Programmable read only memory，EEPROM），可擦除可编程只读存储器（Erasable Programmable Read Only Memory，EPROM），可编程只读存储器（Programmable read-only memory，PROM），只读存储器（Read-Only Memory，ROM），磁存储器，快闪存储器，磁盘或光盘。

处理器22，与存储器21耦合，用于执行存储器21中的计算机程序，以用于：执行直播连麦中音视频合流处理方法中的步骤。

进一步可选的，如图11所示，该电子设备还包括：通信组件23、显示器24、电源组件25、音频组件26等其它组件。图11中仅示意性给出部分组件，并不意味着电子设备只包括图11所示组件。另外，图11中虚线框内的组件为可选组件，而非必选组件，具体可视电子设备的产品形态而定。本实施例的电子设备可以实现为台式电脑、笔记本电脑、智能手机或IOT（物联网，Internet of things）设备等终端设备，也可以是常规服务器、云服务器或服务器阵列等服务端设备。若本实施例的电子设备实现为台式电脑、笔记本电脑、智能手机等终端设备，可以包含图11中虚线框内的组件；若本实施例的电子设备实现为常规服务器、云服务器或服务器阵列等服务端设备，则可以不包含图11中虚线框内的组件。

关于处理器执行各动作的详细实施过程可参见前述方法实施例或设备实施例中的相关描述，在此不再赘述。

相应地，本申请实施例还提供一种存储有计算机程序的计算机可读存储介质，计算机程序被执行时能够实现上述方法实施例中可由电子设备执行的各步骤。

相应地，本申请实施例还提供一种计算机程序产品，包括计算机程序/指令，当计算机程序/指令被处理器执行时，致使处理器能够实现上述方法实施例中可由电子设备执行的各步骤。

上述通信组件被配置为便于通信组件所在设备和其他设备之间有线或无线方式的通信。通信组件所在设备可以接入基于通信标准的无线网络，如WiFi（WirelessFidelity，无线保真）、2G（2Generation，2代）、3G（3Generation，3代）、4G（4Generation，4代）/LTE（long Term Evolution，长期演进）、5G（5Generation，5代）等移动通信网络，或它们的组合。在一个示例性实施例中，通信组件经由广播信道接收来自外部广播管理系统的广播信号或广播相关信息。在一个示例性实施例中，通信组件还包括近场通信（Near FieldCommunication，NFC）模块，以促进短程通信。例如，在NFC模块可基于射频识别（RadioFrequency Identification，RFID）技术，红外数据协会（The Infrared DataAssociation，IrDA）技术，超宽带（Ultra Wide Band，UWB）技术，蓝牙（Bluetooth，BT）技术和其他技术来实现。

上述显示器包括屏幕，其屏幕可以包括液晶显示器（Liquid Crystal Display，LCD）和触摸面板（Touch Panel，TP）。如果屏幕包括触摸面板，屏幕可以被实现为触摸屏，以接收来自用户的输入信号。触摸面板包括一个或多个触摸传感器以感测触摸、滑动和触摸面板上的手势。触摸传感器可以不仅感测触摸或滑动动作的边界，而且还检测与触摸或滑动操作相关的持续时间和压力。

上述电源组件，为电源组件所在设备的各种组件提供电力。电源组件可以包括电源管理系统，一个或多个电源，及其他与为电源组件所在设备生成、管理和分配电力相关联的组件。

上述音频组件，可被配置为输出和/或输入音频信号。例如，音频组件包括一个麦克风（microphone，MIC），当音频组件所在设备处于操作模式，如呼叫模式、记录模式和语音识别模式时，麦克风被配置为接收外部音频信号。所接收的音频信号可以被进一步存储在存储器或经由通信组件发送。在一些实施例中，音频组件还包括一个扬声器，用于输出音频信号。

本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可读存储介质（包括但不限于磁盘存储器、CD-ROM、光学存储器等）上实施的计算机程序产品的形式。

本申请是参照根据本申请实施例的方法、设备（系统）、和计算机程序产品的流程图和／或方框图来描述的。应理解可由计算机程序指令实现流程图和／或方框图中的每一流程和／或方框、以及流程图和／或方框图中的流程和／或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和／或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和／或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和／或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中，计算设备包括一个或多个处理器(Central ProcessingUnit，CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器 (RandomAccess Memory，RAM)和/或非易失性内存等形式，如只读存储器(Read Only Memory，ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变化内存(Phase Change RAM，PRAM)、静态随机存取存储器(Static Random-Access Memory，SRAM)、动态随机存取存储器(DynamicRandom Access Memory，DRAM)、其他类型的随机存取存储器(Random Access Memory，RAM)、只读存储器(Read Only Memory，ROM)、电可擦除可编程只读存储器(Electrically-Erasable Programmable Read-Only Memory，EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(Digital versatile disc，DVD)或其他光学存储、磁盒式磁带，磁带磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括要素的过程、方法、商品或者设备中还存在另外的相同要素。

以上仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。