一种音视频加工的方法及装置

技术领域

本申请实施例涉及多媒体数据处理技术，尤其涉及一种音视频加工的方法及装置。

背景技术

目前，随着网络通信技术的进步和宽带网络的提速，网络直播得到了越来越多的发展和应用。为了提升主播的直播效果，通常可以采用内容加工服务来对直播的视频进行内容加工，例如，对视频进行AI(Artificial Intelligence，人工智能)美颜、背景分割、白板处理等。

在相关技术中，如图1所示，对视频进行内容加工的方式包括如下流程：通过多个接收器receiver进行拉流，对每路视频流通过解码器decoder进行解码后，通过混流器(compositor)对解码后的视频流进行混流处理，在混流的过程中，采用使用Lua语言编写插件对混流后的视频流进行加工处理，然后将加工处理后的视频通过编码器(encoder)进行编码，并将编码后的视频流进行推流处理(pusher)。

但上述的内容加工方式存在如下不足：

1、只能使用Lua语言编写插件；

2、一次拉流、解码、混流、加工、编码、推流的过程只能进行一次加工处理，如果需要对视频进行多次加工处理，需要进行多次的推拉流和编解码，延迟较高。

发明内容

本申请提供一种音视频加工的方法及装置，以解决现有技术的加工方式中存在的加工延时高、加工插件限制的问题。

第一方面，本申请实施例提供了一种音视频加工的方法，所述方法包括：

接收加工任务，所述加工任务用于描述对音视频加工所需的加工流程，所述加工任务至少包括：待加工的音视频流的标识以及加工插件标识列表；

拉取与所述待加工的音视频流的标识对应的音视频流；

依次调用所述加工插件标识列表中各加工插件标识对应的加工插件，对所述音视频流进行内容加工处理。

第二方面，本申请实施例还提供了一种音视频加工的装置，所述装置包括：

任务接收模块，用于接收加工任务，所述加工任务用于描述对音视频加工所需的加工流程，所述加工任务至少包括：待加工的音视频流的标识以及加工插件标识列表；

拉流模块，用于拉取与所述待加工的音视频流的标识对应的音视频流；

内容加工模块，用于依次调用所述加工插件标识列表中各加工插件标识对应的加工插件，对所述音视频流进行内容加工处理。

第三方面，本申请实施例还提供了一种服务器，所述服务器包括：

一个或多个处理器；

存储装置，用于存储一个或多个程序，

当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现上述的方法。

第四方面，本申请实施例还提供了一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现上述的方法。

本申请所提供的技术方案，具有如下有益效果：

在本实施例中，提出了一种流水线的音视频加工方法，可以根据加工任务来对音视频流进行内容加工处理，具体的，当接收到加工任务以后，可以根据加工任务中的待加工的音视频流的标识进行拉流，获得音视频流。然后根据加工任务中的加工插件标识列表，依次调用该加工插件标识列表中各加工插件标识对应的加工插件对音视频流进行内容加工处理，通过上述过程可以实现对单独的音视频流进行多重加工处理，降低了加工延迟，提高了对音视频流的加工效率。

另外，本实施例可以根据加工插件标识列表进行加工插件的拼装，当需要多重内容加工时，只需要在流水线上增加对应的加工插件即可，丰富了内容加工的形式和灵活性。

另外，在进行多路音视频流处理时，在混流后也可以对合并帧数据进行后加工处理，一条加工流水即可实现多重加工能力，且只需要一次推拉流和编解码的开销，可以更好地降低内容加工产生的延迟。

附图说明

图1是本申请背景技术中提及的现有对视频进行内容加工的流程示意图；

图2是本申请实施例一提供的一种音视频加工的方法实施例的流程图；

图3是本申请实施例二提供的一种音视频加工的方法实施例的流程图；

图4是本申请实施例三提供的一种示例性的音视频加工流水线的示意图；

图5是本申请实施例三提供的对直播流进行内容加工的示例性流程示意图；

图5a是本申请实施例三提供的合成图像帧1的示意图；

图5b是本申请实施例三提供的合成图像帧2的示意图；

图6为本申请实施例四提供的一种音视频加工的装置实施例的结构框图；

图7是本申请实施例五提供的一种服务器的结构示意图。

具体实施方式

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

实施例一

图2为本申请实施例一提供的一种音视频加工的方法实施例的流程图，该音视频加工的方法是一种类似于流水线的云加工方法，可以在云端串联多个加工插件对音视频流进行加工处理。如图2所示，本实施例可以应用于服务器中，服务器可以通过一个加工进程来实现本实施例的方法。

本实施例可以包括如下步骤：

步骤201，接收加工任务，所述加工任务至少包括：待加工的音视频流的标识以及加工插件标识列表。

本实施例可以应用于对音视频流进行内容加工的场景，例如，在直播场景下对直播的视频进行美颜、背景分割等加工。对于待加工的音视频流，可以根据用户指示的加工需求，创建对应的加工任务，并把加工任务发送至实施本实施例的加工进程中。

本实施例关于需求方创建加工任务的方式不作限定，例如，需求方可以是服务器上的一个业务服务，也可以是终端上的软件程序(如手机上的APP)，当需求方检测到用户触发的加工业务需求时，则可以根据用户触发的需求创建加工任务。

本实施例的加工任务用于描述对音视频加工所需的加工流程，示例性地，加工任务至少可以包括：待加工的音视频流的标识以及加工插件标识列表。其中，该加工插件标识列表为加工本实施例的音视频流所需的加工插件的标识组成的列表，列表中可以包括一个或多于一个的加工插件标识，各加工插件标识对应的加工插件被用于对待加工的音视频流进行加工。

步骤202，拉取与所述待加工的音视频流的标识对应的音视频流。

在一种实现中，当确定待加工的音视频流的标识以后，加工进程可以通过拉流线程(Puller)拉取与该待加工的音视频流的标识对应的音视频流。

需要说明的是，本实施例的音视频流可以有一个或多个，当有多个时，则可以采用多个Puller进行多路拉流。Puller可以适配不同的输入流，例如，该音视频流可以包括rtmp协议的音视频流、指定音视频网络的音视频数据或者是mp4、flv格式的文件等。

在一种实施方式中，在步骤202完成拉流以后，本实施例还可以包括如下步骤：

将所述音视频流解码成帧数据，并将所述帧数据存储在共享内存中。

在该步骤中，当拉流以后，Puller可以将拉取的音视频流传递给解码器(Decorder)进行解码，Decorder对音视频流进行解码后得到帧数据，其中，对于视频而言，该帧数据可以为rgba格式的图像帧；对于音频而言，该帧数据可以为未经过压缩的PCM格式。

然后，可以将帧数据存储在共享内存中，在共享内存中，帧数据可以以内存偏移量进行标记，即，可以首先获取该帧数据在共享内存中的存储位置，然后计算该存储位置的内存偏移量。

步骤203，依次调用所述加工插件标识列表中各加工插件标识对应的加工插件，对所述音视频流进行内容加工处理。

在该步骤中，可以调用加工插件标识列表中各加工插件标识对应的加工插件对帧数据进行内容加工处理。其中，加工插件标识列表中各加工插件标识对应的加工插件可以串联工作，前一个加工插件的输出可以作为后一个加工插件的输入，直到所有加工插件都处理完毕。

在一种实施例中，加工插件可以是不同能力团队提供的云美颜、云背景替换等各种音频或视频加工插件。本实施例支持加工插件的拼装，可以按照业务需求随意接入各种加工插件。并且，本实施例对加工插件的编写预言不作限定，插件的接入方可以自由选择Lua、Python、C++等等语言来编写加工插件。

在一种实施方式中，加工插件标识列表中可以包括至少两个加工插件标识，以及，该至少两个加工插件标识的执行顺序，则步骤203可以包括如下步骤：

步骤203-1，按照所述执行顺序依次遍历所述加工插件标识列表中的加工插件标识，针对当前的加工插件标识，调用所述加工插件标识对应的加工插件，并将当前待处理的帧数据的内存偏移量发送至所述加工插件中。

在该实施例中，加工插件标识列表中如果包含有两个以上的加工插件标识，则加工插件标识列表中还可以标记该两个以上的加工插件标识的执行顺序。加工进程可以按照该执行顺序依次遍历该加工插件标识列表中的加工插件标识。

对于当前遍历到的加工插件标识，可以根据该加工插件标识调用对应的加工插件，然后将当前待处理的帧数据的内存偏移量发送至该加工插件中。

在一种实施方式中，可以基于远程过程调用协议RPC协议的thrift接口(即ThriftRPC)，调用加工插件标识对应的加工插件。当然，除此以外，加工进程还可以采用其他协商好的通信协议与各加工插件进行通信。

步骤203-2，由所述加工插件根据所述内存偏移量从所述共享内存中读取对应的帧数据，并对所述帧数据进行加工处理。

在该步骤中，被调用的加工插件接收到当前待处理的帧数据的内存偏移量以后，可以根据该内存偏移量确定当前待处理的帧数据在共享内存中的存储位置，并从该存储位置中读取对应的帧数据，然后采用当前加工插件的加工逻辑对该读取的帧数据进行内容加工处理。

步骤203-3，将加工处理后的帧数据存储在所述共享内存中，并继续遍历下一个加工插件标识，调用对应的加工插件从所述共享内存中读取所述加工处理后的帧数据进行加工，以此类推，直到所述加工插件标识列表中的加工插件标识遍历完毕。

在该步骤中，当前加工插件对帧数据进行内容加工处理以后，可以将加工处理后的帧数据存储在共享内存中。在一种实现中，该加工处理后的帧数据可以存储在原来的存储位置，并覆盖原有的帧数据。同时，当将加工处理后的帧数据存入共享内存以后，当前加工插件可以向加工进程发送一个通知消息，以通知加工进程当前插件的加工完成，触发下一个插件的加工。

加工进程接收到该通知消息以后，则可以判定当前加工插件已经工作完成，并继续遍历加工插件标识列表中的下一个加工插件标识，调用对应的加工插件，以及将帧数据的内存偏移量发送给该加工插件，该加工插件重复步骤203-2以及步骤203-3的流程，直到加工插件标识列表的所有加工插件标识遍历完毕，以及所有加工插件标识对应的加工插件都处理完毕为止。

在其他实施例中，加工处理后的帧数据也可以不存储在原来的存储位置，而是存储在其他位置，此时，当前加工插件可以获取该加工处理后的帧数据的内存偏移量，并在通知消息中携带该内存偏移量。则加工进程在调用下一个加工插件时，可以从该通知消息中提取该内存偏移量并发送至下一加工插件，下一加工插件则可以根据该内存偏移量读取加工处理后的帧数据并进行再次加工。

在该实施例中，将帧数据存放在共享内存中，进程与插件之间不传输帧数据只传递内存偏移量，可以有效避免多级插件之间传输帧数据引起的传输延迟。

当然，在其他实施例中，在没有共享内存的实施方案中，Decorder对音视频流进行解码后，可以直接将解码得到帧数据传输给加工插件标识列表的第一个加工插件标识对应的加工插件(此处的第一个加工插件标识是指执行顺序第一，后续的第二个等是类似的)，第一个加工插件对帧数据完成内容加工以后，可以将加工后的帧数据传输给加工插件标识列表的第二个加工插件标识对应的加工插件，由第二个加工插件进行处理，第二个加工插件处理完后将加工后的帧数据传递给第三个加工插件，以此类推，直到加工插件标识列表的所有加工插件标识对应的加工插件均处理完毕，由最后一个加工插件输出的帧数据就是当前阶段的加工结果。

在一种实施方式中，当被调用的加工插件的数量为至少两个时，则该至少两个加工插件可以部署在同一台物理机器的一个或多个容器中。

在该实施例中，当所需的加工插件为两个或以上时，可以将这些加工插件都部署在同一个容器中，也可以每个加工插件具有独立的容器，或者将加工插件部署在多个容器的，即部分容器中具有一个加工插件，部分容器具有至少两个加工插件，具体部署的方式可以根据业务需求确定，本实施例对此不作限制，但为了降低传输延时，这些插件需要部署在同一台机器中。

当然，在其他实现中，也可以将加工插件部署在不同机器中，以满足不同的业务需求。

在本实施例中，提出了一种流水线的音视频加工方法，可以根据加工任务来对音视频流进行内容加工处理，具体的，当接收到加工任务以后，可以根据加工任务中的待加工的音视频流的标识进行拉流，获得音视频流。然后根据加工任务中的加工插件标识列表，依次调用该加工插件标识列表中各加工插件标识对应的加工插件对音视频流进行内容加工处理，通过上述过程可以实现对单独的音视频流进行多重加工处理，降低了加工延迟，提高了对音视频流的加工效率。

另外，本实施例可以根据加工插件标识列表进行加工插件的拼装，当需要多重内容加工时，只需要在流水线上增加对应的加工插件即可，丰富了内容加工的形式和灵活性。并且以加工任务的方式来触发内容加工，可以按照实际的业务需求自定义输入和输出的路数和参数。

实施例二

图3为本申请实施例二提供的一种音视频加工的方法实施例的流程图，本实施例在实施例一的基础上执行，本实施例中的音视频流可以包括多路音视频流，则加工任务还可以包括：一个或多个混流目标，以及各混流目标对应的后加工插件标识列表，其中，每个后加工插件标识列表可以包括一个或多个加工插件标识。

在上述实施例一的步骤203之后，本实施例还可以包括如下步骤：

步骤204，针对各混流目标，对各路音视频流中同一时刻的、进行内容加工处理后的帧数据按照该混流目标进行合并，生成合并帧数据。

在该步骤中，当通过步骤203分别对各路帧数据进行加工处理后，可以对加工处理后的各帧数据进行混流合并，生成合并帧数据。在本实施例中，加工任务还可以包括一个或多个混流目标，其中，一个混流目标可以对应合并成一帧合并帧数据。

示例性地，混流目标可以包括合并效果，或者混流所需的步骤，例如，一个混流目标可以为，合成图像帧并添加进度条。

在一种实施方式中，步骤204可以包括如下步骤：

步骤204-1，调用所述混流目标对应的混流插件。

在本实施例中，除了有加工插件，还可以包括混流插件，各混流插件具有相关的功能描述，可以根据混流目标选择对应的混流插件进行混流处理，混流插件的作用是将多帧数据合并成一帧数据，并进行相关的画面处理。

步骤204-2，采用所述混流插件对各路音视频流中同一时刻的、进行内容加工处理后的帧数据进行合并。

在该步骤中，当确定混流插件以后，则可以采用该混流插件的混流逻辑对同一时刻的多路帧数据进行合并加工处理，生成合并帧数据。

在存在共享内存的应用场景中，混流插件可以从共享内存中读取同一时刻的多路帧数据，并对多路帧数据进行混流处理。

在没有共享内存的应用场景中，混流插件可以接收各路音视频流经过最后的加工插件加工后的帧数据，然后将多个帧数据组合成单个帧数据。

步骤205，依次调用该混流目标对应的、后加工插件标识列表中的加工插件标识对应的加工插件，对所述合并帧数据进行后加工处理。

在该实施例中，针对混流后得到的合并帧数据，如果加工任务中存在与混流目标对应的一个或多个后加工插件标识列表，表示需要对该合并帧数据进行后加工处理。

具体的，一个后加工插件标识列表表示一条加工需求，对应输出一路音视频流，因此，如果有多个后加工插件标识列表，则可以输出多路音视频流。对于每个后加工插件标识列表，可以依次调用该后加工插件标识列表中的加工插件标识对应的加工插件，对当前合并帧数据进行后加工处理，其后加工处理的过程与参考步骤203中对混流前的帧数据进行内容加工的过程类似，可以参考步骤203的实现，此处不再赘述了。

步骤206，对后加工处理后的合并帧数据进行编码，生成目标音视频流，并对所述目标音视频流进行推流处理。

当对合并帧数据进行后加工处理完成以后，可以将后加工处理后的合并帧数据进行编码合流，生成目标音视频数据，然后对目标音视频数据进行推流处理。

在本实施例中，需加工的音视频任务派发进来后，进行拉流、解码、插件加工、混流、插件后加工、编码、推流等一系列音视频流操作后，输出了加工后的音视频流，一条加工流水即可实现多重加工能力，且只需要一次推拉流和编解码的开销，可以更好地降低内容加工产生的延迟，例如，通过本实施例的方案可以将内容加工延迟控制在50ms以内。

实施例三

图4为本申请实施例三提供的一种示例性的音视频加工流水线的示意图，本实施例综合实施例一和实施例二，对多路音视频流的加工过程以及混流后的后处理过程进行说明。

本实施例相比于背景技术，重新定义了内容加工的框架，如同一个流水线，帧数据经过多个工序处理后得到产品就是内容加工后的音视频。如图4所示，该实例可以在加工节点pod(pod是可以在Kubernetes中创建和管理的、最小的可部署的计算单元，Pod可能包含单个容器或少量紧密合作的多个容器)中执行，整个内容加工过程可以包括Puller(拉流)、MediaFlow(插件加工)、Compositor(混流)、Pusher(推流)几个阶段，其中，各个阶段的说明如下：

Puller：整个阶段的工作是适配不同的输入，可能是rtmp协议的音视频流、制定音视频网络的音视频数据，也可能是mp4、flv格式的文件。经过解码器解码后，Puller阶段的输出统一成帧数据。

MediaFlow：帧数据加工的关键部件，如图4所示，每个MediaFlow可以定义N个加工插件，输入和输出都是帧数据，帧数据依次从第1个加工插件输入经过处理后输出，再从第2个加工插件输入经过处理后输出，依次类推。加工插件的顺序和功能可以自由组装，例如，定义了插件a将帧数据灰度化，插件b将帧数据黑白处理，经过了a+b后MediaFlow的输出就是灰白和黑白处理。进程采用thrift rpc与插件进行通信，支持python、c++、lua等等语言，对于接入方选择自由度更高。同时，将帧数据存放在共享内存池中，使得进程与插件之间不传输帧数据只传递内存偏移，也避免了多级插件之间帧数据的传输延迟。

Compositor：这个阶段的工作是混合，定义了多个输入，并将所有输入的帧数据组合成单个帧数据，最终只有一路输出。

Pusher：这个阶段的工作是将帧数据转换为不同的输出形式。输入是帧数据，输出可以是rtmp协议的音视频流，也可以是mp4、flv格式的文件。

如图4所示，当有任务派发过来时，加工进程(即图4中的守护进程)通过Pipeline(视频流加工流水线服务)接收加工任务，然后对加工任务进行分析，获得待加工的音视频流的标识。然后在Puller阶段通过拉流线程Puller 1…Puller N从各待加工的音视频流的标识对应的源端进行拉流，并对拉取的音视频流通过Decorder进行解码，得到帧数据。

然后，在一种方式中，可以将Puller阶段解码生成的帧数据存入共享内存中，以供后续的加工插件通过内存偏移量进行读取。在另一种方式中，Decorder可以直接将音频帧或者视频帧(Audio/Video，简称A/V)发送给加工插件进行加工。

然后来到MediaFlow阶段，各路音视频流都具有对应的MediaFlow，各MediaFlow中包括一个或多个加工插件(即图4中的插件1…插件N，如用于美颜的美颜插件、用于进行背景分割的背景分割插件等)，通过插件1…插件N依次对音频帧或者视频帧进行内容加工，多个加工插件串联执行，前一个加工插件的加工结果可以作为后一个加工插件的输入，最后一个加工插件的输出作为当前MediaFlow的输出。

如果是通过共享内存来存储帧数据，则每个加工插件可以将加工后的结果存入共享内存中，并获取该结果在共享内存的内存偏移量发给加工进程，由加工进程调用下一个加工插件，下一个加工插件根据该内存偏移量读取对应的帧数据进行加工处理，以此类推。在一种实现中，同一个帧数据在共享内存中的存储位置是相同的，在该位置上，后面存储的数据会覆盖前面存储的数据。其中，如图4所示的共享内存IPC是指一个pod里的容器共享相同的IPC命名空间，可以使用SystemV信号系统或POSIX共享内存通信。

各路音视频流的MediaFlow完成以后，则进入Compositor阶段，Compositor通过接收加工完的帧数据，或者，通过从共享内存中读取对应的帧数据，然后对其按照混流目标进行混流处理。

混流处理完成以后，进入后加工处理MediaFlow阶段，在该阶段中，可以通过调用一个或多个加工插件对混流后生成的合并帧数据进行后加工处理，然后将后加工处理得到的帧数据编码成音视频流，进入推流Pusher阶段进行推流处理。

以下举一个具体例子对上述的加工过程进行说明：

如图5所示，假设在直播场景下，有两路输入流，分别是主播1的视频流1和主播2的视频流2，通过拉流和解码后可以得到rgb格式的图像帧。在加工阶段，对于主播1的图像帧，采用美颜插件进行美颜加工处理，或者，采用虚拟形象插件开启虚拟形象效果；同时，对于主播2的图像帧，也采用美颜插件进行美颜加工处理，或者，采用虚拟形象插件开启虚拟形象效果；然后对加工处理后的主播1的图像帧和主播2的图像帧进行混流处理，根据不同的混流目标，可以得到不同的合成图像，例如，在图5中，其中一种混流目标是合成图像并添加PK条，得到合成图像帧1，比如合成图像帧1可以如图5a所示；另一种混流目标是合成图像并使用不同的布局或者画面大小，得到合成图像帧2，比如合成图像帧2可以如图5b所示。

对于混流后的合成图像帧，可以根据不同的后加工目标进行后加工处理，例如，如图5所示，对于合成图像帧1，可以采用加工插件把背景替换掉(即图5中的后加工处理1)；对于合成图像帧2可以采用其他加工插件进行后加工处理(即图5中的后加工处理2)。然后对后处理后的图像帧进行编码，生成合成流，并发布所述合成流。

通过本实施例可以得到如下有益效果：

低延迟：经过本实施例的延迟能控制在50ms以内；

支持多语言的插件：基于进程外的插件设置，使插件的接入方可以自由选择python、c/c++、lua、nodejs等语言来编写插件；

支持拼装能力：一个框架，灵活应用到各种业务。

实施例四

图6为本申请实施例四提供的一种音视频加工的装置实施例的结构框图，可以包括如下模块：

任务接收模块601，用于接收加工任务，所述加工任务用于描述对音视频加工所需的加工流程，所述加工任务至少包括：待加工的音视频流的标识以及加工插件标识列表；

拉流模块602，用于拉取与所述待加工的音视频流的标识对应的音视频流；

内容加工模块603，用于依次调用所述加工插件标识列表中各加工插件标识对应的加工插件，对所述音视频流进行内容加工处理。

在一种实施方式中，所述装置还可以包括如下模块：

解码模块，用于在拉取与所述待加工的音视频流的标识对应的音视频流之后，将所述音视频流解码成帧数据；

存储模块，用于将所述帧数据存储在共享内存中。

在一种实施方式中，所述加工插件标识列表包括至少两个加工插件标识，以及，所述至少两个加工插件标识的执行顺序；

所述内容加工模块603可以包括如下子模块：

插件调用子模块，用于按照所述执行顺序依次遍历所述加工插件标识列表中的加工插件标识，针对当前的加工插件标识，调用所述加工插件标识对应的加工插件，并将当前待处理的帧数据的内存偏移量发送至所述加工插件中；

加工子模块，用于由所述加工插件根据所述内存偏移量从所述共享内存中读取对应的帧数据，并对所述帧数据进行加工处理；

存储子模块，用于将加工处理后的帧数据存储在所述共享内存中，并继续遍历下一个加工插件标识，调用对应的加工插件从所述共享内存中读取所述加工处理后的帧数据进行加工，以此类推，直到所述加工插件标识列表中的加工插件标识遍历完毕。

在一种实施方式中，所述插件调用子模块具体用于：

基于远程过程调用协议RPC协议的thrift接口，调用所述加工插件标识对应的加工插件。

在一种实施方式中，当被调用的加工插件的数量为至少两个时，则该至少两个加工插件部署在同一台物理机器的一个或多个容器中。

在一种实施方式中，所述音视频流包括多路音视频流；所述加工任务还包括：一个或多个混流目标，以及各混流目标对应的后加工插件标识列表；

所述装置还可以包括如下模块：

帧数据合并模块，用于针对各混流目标，对各路音视频流中同一时刻的、进行内容加工处理后的帧数据按照该混流目标进行合并，生成合并帧数据；

后加工处理模块，用于依次调用该混流目标对应的、后加工插件标识列表中的加工插件标识对应的加工插件，对所述合并帧数据进行后加工处理；

编码推流模块，用于对后加工处理后的合并帧数据进行编码，生成目标音视频流，并对所述目标音视频流进行推流处理。

在一种实施方式中，所述帧数据合并模块具体用于：

调用所述混流目标对应的混流插件；

采用所述混流插件对各路音视频流中同一时刻的、进行内容加工处理后的帧数据进行合并。

本申请实施例所提供的装置可执行本申请实施例一至实施例三所提供的方法，具备执行方法相应的功能模块和有益效果。

实施例五

图7为本申请实施例五提供的一种服务器的结构示意图，如图7所示，该服务器包括处理器710、存储器720、输入装置730和输出装置740；服务器中处理器710的数量可以是一个或多个，图7中以一个处理器710为例；服务器中的处理器710、存储器720、输入装置730和输出装置740可以通过总线或其他方式连接，图7中以通过总线连接为例。

存储器720作为一种计算机可读存储介质，可用于存储软件程序、计算机可执行程序以及模块，如本申请实施例中的上述实施例对应的程序指令/模块。处理器710通过运行存储在存储器720中的软件程序、指令以及模块，从而执行服务器的各种功能应用以及数据处理，即实现上述的方法实施例中提到的方法。

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

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

实施例六

本申请实施例六还提供一种包含计算机可执行指令的存储介质，所述计算机可执行指令在由计算机处理器执行时用于执行上述方法实施例中的方法。

当然，本申请实施例所提供的一种包含计算机可执行指令的存储介质，其计算机可执行指令不限于如上所述的方法操作，还可以执行本申请任意实施例所提供的方法中的相关操作。

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

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

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