CN114489572A - 业务需求调整方法和相关设备 - Google Patents

Abstract

本申请提供了一种业务需求调整方法和相关设备，包括：根据更新业务需求构建第一元件集合，该第一元件集合包括多媒体处理框架中执行更新业务需求所需的所有第一元件的标识和第一时序关系，其中，第一时序关系用于标识所有第一元件之间的调用关系；然后，根据第一元件集合调整第二元件集合，第二元件集合包括多媒体处理框架中执行原业务需求的所有第二元件以及第二元件之间的调用关系；并按照调整后的第二元件集合完成业务需求处理。如此，可以实现在多媒体处理框架中将原业务需求调整为更新业务需求，从而实现了对于业务需求的调整。

Description

业务需求调整方法和相关设备

技术领域

本申请涉及计算机技术领域，尤其涉及一种业务需求调整方法、装置、设备、加速卡和计算机可读存储介质。

背景技术

随着深度学习技术的兴起，人工智能技术(artificial intelligence，AI)已经渗透到各行各业的应用中，例如，多媒体处理。通常地，多媒体处理由多媒体处理框架完成，多媒体处理框架是一种利用软硬件资源进行音视频等流媒体处理的软件框架，例如，Gstreamer 流媒体处理框架等，此类框架均可以对外提供模块化的元件或流媒体处理应用编程接口 (application programming interface，API)，用户(如开发者等)可以基于该框架开发流媒体处理应用，例如，英伟达

的deepstream等，这类应用可以进一步提供自研的插件和业务流编排程序，以支撑包括安防、制造、医疗等应用场景的业务需求。

虽然上述多媒体处理框架提供了可供调用的功能模块，但是其并不支持用户在多媒体处理框架中调整业务需求，而实际应用中，由于实施场景的不同，业务需求会随之变化，这使得用户难以在多媒体处理框架中根据实际应用的需要调整业务需求，降低了用户的使用体验。因此，如何提供一种更好体验的多媒体处理框架成为亟待解决的技术问题。

发明内容

本申请提供了一种业务需求调整方法、装置、设备、加速卡、计算机可读存储介质及计算机程序产品，用以在多媒体处理框架中调整业务需求，从而实现提供一种更好体验的多媒体处理框架。

第一方面，提供一种业务需求调整方法，该方法可以由业务需求调整系统执行，具体实现时，在调整业务需求的过程中，业务需求调整系统根据更新业务需求构建第一元件集合，该第一元件集合包括多媒体处理框架中执行该更新业务需求所需的所有第一元件的标识和第一时序关系，其中，该第一时序关系用于标识所有第一元件之间的调用关系，而所有第一元件基于第一时序关系串联，即可得到更新业务需求所对应的更新业务流。本发明技术方案中，是在原业务需求所对应的原始业务流的基础上生成更新业务流，因此，在构建出第一元件集合后，可以根据该第一元件集合调整第二元件集合，而该第二元件集合包括多媒体处理框架中执行原业务需求的所有第二元件以及第二元件之间的调用关系，也即根据该第二元件集合调整原始业务流，而调整后的原始业务流即为用户所期望的更新业务流，用于实现更新业务需求，从而可以按照调整后的第二元件集合完成业务需求处理。

如此，当用户的业务需求发生变化时，在多媒体处理框架中将执行原业务需求的元件以及元件之间的调用关系调整为执行更新业务需求的元件以及元件之间的调用关系，也即实现了从原业务需求到更新业务需求的调整，从而使得多媒体处理框架能够支持用户对于业务需求的调整，提高用户的使用体验。

在一种可能的实施方式中，业务需求调整系统可以预先获取原业务需求对应的原始业务流，具体的，业务需求调整系统可以在根据更新业务需求构建第一元件集合之前，获取第二元件集合，该第二元件集合包括多媒体处理框架中执行原业务需求所需的所有第二元件和第二时序关系，其中，第二时序关系用于标识所有第二元件之间的调用关系，该第二元件基于第二时序关系进行串联，即为原业务需求对应的原始业务流。如此，业务需求调整系统可以在获取的第二元件集合的基础上，对元件进行相应的增加、删除和替换，并对元件之间的时序关系进行相应的调整。

在另一种可能的实施方式中，业务需求调整系统在构建第一元件集合时，具体可以是在多媒体流处理框架中确定执行该更新业务需求所需的所有第一元件，同时，按照处理该更新业务需求的流程确定所有第一元件之间所满足的第一时序关系，从而可以根据确定的第一元件以及第一时序关系构建第一元件集合。如此，业务需求调整在确定更新业务需求后，可以根据该更新业务需求自动构建第一元件集合，而无需用户参与构建，简化了用户的操作，提高了用户体验。

在另一种可能的实施方式中，第一元件集合具体可以是第一有向图，该第一有向图可以用于标识所有第一元件和所述第一时序关系；第二元件集合包括第二有向图，该第二有向图用于标识所述所有第二元件和所述第二时序关系。这样，通过有向图可以体现原业务需求所对应的业务流以及更新业务需求对应的更新业务流中包含哪些元件以及这些元件之间的调用关系，以便于用户通过查看该有向图确定构成业务流的元件以及元件之间的连接，从而方便用户利用有向图实现对业务流的调整和编辑。

在另一种可能的实施方式中，业务需求调整系统在调整第二元件集合时，具体可以是先比较原业务需求对应的第一有向图与更新业务需求对应的第二有向图之间的差异，确定两个有向图所表征的两个业务流中的差异元件以及差异时序关系，从而可以根据该差异元件和差异时序关系确定第一有向图中的至少一个组，其中，每个组中包括至少一个差异元件，然后，业务需求调整系统可以根据第一有向图中的至少一个组对第二元件集合进行调整，具体是调整第二元件集合中的元件以及元件之间的调用关系等。如此，业务需求调整系统可以通过有向图确定原业务需求对应的原始业务流与更新业务需求对应的更新业务流之间差异，从而针对于该差异实现对原始业务流的调整，进而实现将原业务需求修改为更新业务需求。

在另一种可能的实施方式中，当第一有向图中至少一个组中存在一个组包括两个或两个以上差异元件时，该两个或两个以上差异元件为第一有向图中需要连续调整的元件，即，第一有向图与第二有向图中的差异部分不包括相同的元件，如此，可以将两个有向图之间的差异部分按照较小粒度进行划分，以便于在对原始业务流进行调整时，可以按照较小的粒度逐个对组内的差异元件进行调整，降低调整业务需求对于媒体数据流的处理影响。

在另一种可能的实施方式中，业务需求调整系统在调整第二元件集合时，具体可以是将第二有向图中的至少一个组包括的差异元件，替换成为第一有向图中的至少一个组包括的差异元件。如此，通过以组为单位实现对于原始业务流中元件的调整，从而实现对业务需求的调整。

在另一种可能的实施方式中，第二有向图中的至少一个组包括第一组，则业务需求调整系统在为原始业务流替换元件的过程中，可以先探测第二有向图中传输至第一组的起始位置的数据，该起始位置为第二有向图中与第一组相邻的前一元件的数据输出位置；当在起始位置处探测到存在数据要传输至该第一组时，可以拦截在第二有向图中第一组的起始位置处探测到的数据，并将拦截到的数据输入至第一组在第一有向图中对应的差异元件，即拦截的数据可以交由替换的新元件进行处理，而无需再由原始业务流中的旧元件进行处理。如此，可以使得在调整业务需求的过程，避免因重启执行原业务需求所涉及的元件导致中断媒体数据流的处理，使得业务流在调整过程中能够持续输出经过处理的媒体数据流，进而可以使得播放媒体数据流时不容易出现卡顿或者终止。

在另一种可能的实施方式中，该第一组还具有终止位置，终止位置为第二有向图中与第一组相邻的后一元件的数据输入位置。业务需求调整系统可以从第二有向图中第一组的起始位置处开始传输结束事件，该结束事件用于标识第二有向图中第一组包括的元件处理完数据，即当第二有向图中的元件在接收到该结束事件，通常仅在处理完当前正在处理以及缓存的数据后才将数据向后传输至下一元件，这样，当在第二有向图中第一组的终止位置处探测到该结束事件，表征第一组中的元件均已完成对数据的处理并传输至与第一组连接的下一元件，从而第一组中的元件所处理以及缓存的数据不会在调整业务需求的过程中发生丢失。相应的，业务需求调整系统在该终止位置处探测到结束事件后，可以删除该结束事件，避免该结束事件继续向后传输而对后续元件产生影响。

在另一种可能的实施方式中，业务需求调整系统还可以呈现业务流编辑界面，这样，用户可以在该业务流编辑界面对业务流进行编辑，从而业务需求调整系统可以响应用户在该业务流编辑界面针对于更新业务需求对应的业务流编辑操作，构建出第一元件集合。如此，可以实现用户对于更新业务需求的自由定义，方便了用户的使用。

在另一种可能的实施方式中，业务需求调整系统还可以呈现调整结果显示界面，该调整结果显示界面显示此次业务需求是否调整成功、原始业务流对应的第一有向图、更新业务流对应的第二有向图、原始业务流与更新业务流中存在差异的元件、该差异元件的功能描述等信息。当然，也可以是显示其中的部分信息或者其他信息等，如此，可以使得用户基于该调整结果显示界面确定业务需求是否调整成功以及调整业务需求的具体详情，方便了用户对于信息的查看。

第二方面，本申请还提供了一种业务需求调整装置，所述业务需求调整装置包括用于执行第一方面或第一方面任一种可能实现方式中的业务需求调整的方法的各个模块。

第三方面，本申请还提供了一种业务需求调整系统，包括：处理器和存储器；该存储器用于存储指令，当该业务需求调整系统运行时，该处理器执行该存储器存储的该指令，以使该业务需求调整系统执行上述第一方面或第一方面的任一实现方法中业务需求调整方法。需要说明的是，该存储器可以集成于处理器中，也可以是独立于处理器之外。业务需求调整系统还可以包括总线。其中，处理器通过总线连接存储器。其中，存储器可以包括可读存储器以及随机存取存储器。

第四方面，本申请还提供了一种加速卡，该加速卡可以应用于计算设备，使得计算设备执行上述第一方面以及第一方面中任意一种实施方式所述的方法。

第五方面，本申请提供一种计算机可读存储介质，所述计算机可读存储介质中存储有指令，当其在计算机上运行时，使得计算机执行上述第一方面以及第一方面中任意一种实施方式所述的方法。

第六方面，本申请提供了一种包含指令的计算机程序产品，当其在计算机上运行时，使得计算机执行上述第一方面以及第一方面中任意一种实施方式所述的方法。

本申请在上述各方面提供的实现方式的基础上，还可以进行进一步组合以提供更多实现方式。

附图说明

图1为本申请实施例提供的一种业务流示意图；

图2为本申请实施例提供的一种基于Gstreamer开发的系统架构示意图；

图3为本申请实施例提供的一种应用场景示意图；

图4为本申请实施例提供的一种业务流调整方法的流程示意图；

图5为本申请实施例提供的用于识别视频中车辆的业务流的示意图；

图6为本申请实施例提供的一示例性业务流编排界面示意图；

图7为本申请实施例提供的一种原始业务流与更新业务流之间的差异部分示意图；

图8为本申请实施例提供的又一种原始业务流与更新业务流之间的差异部分示意图；

图9为本申请实施例提供的一示例性调整结果显示界面示意图；

图10为本申请实施例提供的原始业务流与更新业务流的示意图；

图11为本申请提供的又一种业务需求调整方法的流程示意图；

图12为本申请提供的一种业务需求调整装置的结构示意图；

图13为本申请提供的一种业务需求调整系统的结构示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请中的技术方案进行描述。

在安防、制造、医疗等应用场景中，用户(如开发者)需求的变更使得对媒体数据流的处理逻辑通常会基于实际应用的需求而发生变化，从而难免需要对正在处理媒体数据流的多媒体处理框架中元件或API进行调整。其中，媒体数据流是指包括被多媒体处理框架处理的音视频形式的媒体数据的集合，该媒体数据流可以由多媒体应用/人工智能(Artificial Intelligence，AI)应用等按需生成。为了便于描述，也将多媒体处理框架中处理用户当前正在执行的一个业务需求所包含的所有元件和/或API的集合称为一个业务流。而当用户需求变更时，当前的多媒体处理框架并不支持用户对业务需求进行调整，即多媒体处理框架仅支持特定业务需求对应的业务流，并不支持用户在已有业务流的基础上将业务流调整为满足用户变更的业务需求的业务流。比如，对于监控视频的视频流，多媒体处理框架可能仅提供识别出该监控视频中的车辆的业务流，但是当用户的业务需求变更为识别出该监控视频中出现的人物时，多媒体处理框架无法支持对于监控视频中的人物识别，这使得多媒体处理框架无法适应用户业务需求的变更，降低了用户的使用体验。

基于此，本申请提供了一种业务需求调整方法，以实现在多媒体处理框架中调整业务需求，从而使得多媒体处理框架能够适用于用户的业务需求变更。具体实现时，可以构建更新业务需求(也即用户变更后的业务需求)的有向图，并将该有向图与原业务需求的有向图进行比较，确定在处理原业务需求的基础上需要调整的元件，再确定原业务需求的有向图中待调整的位置，通过探测机制拦截数据流，然后更新处理原业务需求的元件；并进一步结合事件机制解决业务需求修改过程中数据拦截和数据丢失问题，以此实现在线更新业务需求的过程。

每个业务需求可以对应特定的业务流，如图1所示，在部分流媒体处理框架中，如Gstreamer、Deepstream流媒体处理框架等，框架内的各功能模块通常被封装成元件(Element，即模块化封装的具备一定功能的处理单元)，从而各元件可以按需串联成一个完整的管道 (Pipeline)可以构成完整的业务流。其中，每个元件可以具有作为输入/输出端口的衬垫 (Pad)，用于不同元件之间的数据传递。当用户的业务需求发生变更时，实现该业务需求的业务流也会发生变更，而业务流的变更，也即为多媒体处理框架中处理业务需求所包含的元件和/或API发生变更。

其中，上述业务需求调整方法可以由业务需求调整系统实现。示例性的，该业务需求调整系统可以是云平台所提供的云服务，或者，作为功能模块应用于应用平台(如多媒体应用平台、AI应用平台等)、某个应用(Application)中，或者也可以是应用于终端、本地服务器等设备。

示例地，业务调整系统可以包括Gstreamer系统架构，参见图2所示Gstreamer系统架构，该系统架构包括应用层100、Gstreamer层200、硬件层300。进一步的，应用平台还可以包括扩展层400。

其中，应用层100可以提供应用平台110，或者，应用层100可以包括多媒体应用120以及AI应用130等。则业务需求调整系统可以应用于应用平台110、多媒体应用120以及 AI应用130中，并对该应用平台或者应用中的业务流进行相应的调整。

Gstreamer层200可以包括Gstreamer处理框架210以及一些适用于Gstreamer处理框架的插件(即图2所示的Gstreamer插件220，可以用于实现相应的功能，比如数据编码、解码、目标检测、对象识别、格式转换等功能)。其中，Gstreamer层210可以用于支持应用层100的应用/应用平台实现、对应用平台或者应用中的业务流的处理。

硬件层300，是指运行多媒体框架的硬件平台，为一种底层硬件实现方式，具体可以基于X86或者ARM硬件架构构建，或者，也可以是基于现场可编程门阵列 (field-programmable gate array，FPGA)、Ascend芯片实现等，本实施例对此并不进行限定。

扩展层400，可以包括摄像头410、硬件420、传感器430以及显示器440等设备中的一种或多种，当然也可以是包括其它设备，本实施例对此并不进行限定。示例性的，扩展层400，可以为应用层100提供相应的输入或存储能力等。举例来说，当扩展层400包括摄像头410，该摄像头410可以为应用层100中的应用平台或者应用提供视频流，并由应用平台或者应用中的业务流对该视频流进行相应的处理。

应当理解，图2所示的系统架构仅作为一种示例性说明，并不用于对本实施例所适用的系统架构进行限定。实际应用中，可以对该系统架构中的部分设备或者功能模块、单元进行适应性增加、删减及替换等，本实施例对此并不进行限定。

作为一种可能的实施例，业务需求调整系统也可以通过软件实现。例如，该业务需求调整系统可以是嵌入在应用平台110、多媒体应用120或AI应用130中的应用程序，如软件开发工具包(software development kit，SDK)等，用于实现上述对业务流的调整，其对于上述业务流的调整过程，可以由Gstreamer层200中的Gstreamer处理框架210以及Gstreamer插件220实现，其处理的数据流可以由扩展层400中的设备提供。可选地，为了提升业务需求调整系统的运算能力，也可以利用单独的硬件实现上述业务需求调整系统的功能，例如，利用专用集成电路(application-specific integrated circuit，ASIC)实现，或可编程逻辑器件(programmable logic device，PLD)实现，上述PLD可以是复杂程序逻辑器件(complex programmable logical device，CPLD)、FPGA、通用阵列逻辑(generic arraylogic， GAL)或其任意组合实现上述业务需求调整系统的功能。

此外，无论业务需求调整系统以软件还是硬件形式实现，具体实施过程中，业务需求调整系统还可以向用户或开发者提供可视化操作界面，以便于用户或开发者更好的使用该平台。如图3所示，业务需求调整系统可以对外向用户500提供输入端510以及服务端520。其中，输入端510例如可以是提供给用户500的客户端(client)、Web页面或者命令行(command)输入界面等，而用户500可以通过该输入端510向业务需求调整系统输入调整后的业务流，或者通过该用户输入端510触发对业务流的调整。进一步的，用户500还可以通过该输入端510向业务需求调整系统对业务流进行编排等。服务端520，例如可以是上述应用平台或者应用等，用于根据用户输入的业务流处理逻辑对媒体数据流进行处理，以及根据用户对业务流的调整操作对业务流进行相应的调整。

下面，结合图4进一步介绍本申请提供的业务需求调整的方法，图4为本申请实施例提供的一种业务流调整方法的流程示意图，该方法可以应用于上述由软件或者硬件实现的业务需求调整系统中。该方法具体可以包括：

S401：业务需求调整系统根据更新业务需求构建第一元件集合，该第一元件集合包括多媒体处理框架中执行的该更新业务需求所需的所有第一元件的标识以及第一时序关系，其中，该第一时序关系用于标识所有第一元件之间的调用关系。

业务需求，可以通过在多媒体处理框架中执行相应的业务流实现，而业务流是由多个流媒体处理框架下的多个元件按照处理业务需求的流程构建的带有时序关系的元件组合，每个元件用于对媒体数据流执行相应的处理功能，而多个元件对媒体数据流的依次处理构成了该业务流的处理逻辑。如图5所示的用于识别视频中车辆的业务流，其是由数据源提供元件、解码元件、目标检测元件、车辆识别元件以及显示元件进行串联而成。其中，数据源提供元件可以是基于实时流传输协议(Real Time Streaming Protocol，RTSP)提供在业务流中传输的视频流；解码元件用于对接收到的视频流进行解码；目标检测元件用于根据解码得到的视频流对视频中包含的对象进行检测；车辆识别元件用于对检测到的对象中的车辆进行识别；显示元件用于显示视频流对应的视频内容以及车辆识别结果。其中每个元件可以通过源衬垫(src pad)向下一元件传输数据流，并通过接收衬垫(sink pad)接收前一个元件传输的数据流。

由于用户的业务需求可能会因为实施场景而发生变更，从而在实现该业务需求时多媒体处理框架的业务流中对于媒体数据流的处理逻辑需要随着业务需求的变更而进行调整，因此，用户可以触发业务需求调整系统对当前正在运行的业务流进行相应的调整。本实施例中，为便于描述，对于变更前的业务需求，称之为原业务需求，而对于变更后的业务需求，称之为更新业务需求。相应的，用于实现原业务需求的业务流称之为原始业务流，而用于实现更新业务需求的业务流称之为更新业务流。

在实现在多媒体处理框架中将原业务需求调整为更新业务需求的过程中，业务需求调整系统可以先根据更新业务需求构建出第一元件集合，以确定业务需求变更后，执行变更后的更新业务需求所需的元件以及元件之间的调用关系。

作为一种示例，业务需求调整系统可以根据更新业务需求在多媒体处理框架中确定执行该更新业务需求所需的所有第一元件，并进一步确定出该第一元件对应的标识；同时，业务需求调整系统可以按照处理该更新业务需求的数据流处理流程确定第一元件所满足的第一时序关系，该第一时序关系标识了所有第一元件之间的调用关系，从而业务需求调整系统可以根据该第一时序关系以及所有第一元件的标识构建第一元件集合。如此，可以实现根据更新业务需求自动构建第一元件集合。

作为另一种示例，业务需求调整系统也可以是根据用户的操作构建第一元件集合。具体的，业务需求调整系统可以向用户提供如图6所示的业务流编排界面。该界面左侧栏可以包括业务需求调整系统所能提供元件对应的图标(也即该元件的标识)，并提供指示各个元件之间的连接关系的连接线；同时，该界面中还包括用于编辑业务流的编辑区域。这样，当用户期望对当前正在运行的业务流进行修改时，可以在编辑区域中对构成更新业务流的元件进行编排，具体可以是从左侧栏中选择相应的元件图标，并通过拖拽、点击等方式将该元件图标添加编辑区域中，如图6中用户将元件1、元件2以及元件3添加至编辑区域；然后，用户可以为编辑区域中的各个元件添加具有方向的连接线，如图6所示的“→”，用于指示媒体数据流从元件1中传输至元件2，再从元件2中传输至元件3。如此，业务需求调整系统可以根据用户在所述业务流编辑界面的编辑操作，也即在编辑区域中添加的元件(标识)以及元件之间的具有方向的连接线，获取到更新业务需求的第一元件集合。

基于用户在图6所示界面上的编辑，业务需求调整系统所生成的第一元件指示信息具体可以是该更新业务需求对应的有向图，该有向图包括节点和边。其中，该有向图中的节点，用于指示业务流中的元件；而该有向图中的边，即用于指示业务流中元件之间的第一时序关系，该第一时序关系标识了元件之间的调用关系；该边的方向，用于指示数据流在元件之间的传输方向。以下将更新业务需求对应的有向图称之为第一有向图。

实际应用中，用户也可以是在图6所示的业务流编辑界面上完成原始业务流的开发，其具体实现方式与上述开发更新业务流的实现方式类似，在此不做赘述。相应的，业务需求调整系统可以在用户开发原始业务流时，生成原始业务流对应的第二有向图，该第二有向图可以用于描述原始业务流对应的第二元件集合，该第二元件集合包括多媒体处理框架中用于执行该原业务需求所需的所有第二元件以及第二元件所满足的第二时序关系，该第二时序关系用于标识第二元件之间的调用关系。在调整业务需求之前，可以根据原始业务流对应的第二有向图，在多媒体处理框架中创建相应的第二元件并按照第二有向图所描述的第二时序关系对创建的第二元件进行连接，从而所得到的串联的第二元件即可构成该原业务需求对应的原始业务流。

可选的，在其它构建第一元件集合的示例中，业务需求调整系统也可以针对多种业务需求预先完成多种业务流的定义，而原始业务流可以是预先定义的多种业务流中的一种。当用户期望对业务需求进行调整时，业务需求调整系统可以向用户提供该预先完成定义的多种业务流，并在业务流选择界面以有向图的形式向用户展示每种业务流的结构，以便于用户对呈现的多种业务流进行查看和选择。这样，业务需求调整系统可以根据用户在该业务流选择界面上针对业务流的选择操作，将用户所选择的业务流作为更新业务流，而在多媒体处理框架中执行该更新业务流所能满足的业务需求即为更新业务需求。如此，可以得到上述第一元件集合(即更新业务需求对应的有向图)。

S402：业务需求调整系统根据第一元件集合调整第二元件集合，该第二元件集合包括多媒体处理框架中执行原业务需求的所有第二元件以及该第二元件之间的调用关系。

S403：业务需求调整系统按照调整后的第二元件集合完成业务需求处理。

业务需求调整系统在调整业务需求时，具体可以是将原业务需求对应的原始业务流所处理的媒体数据流交由更新业务需求对应的更新业务流进行处理，从而得到经过更新业务流处理的媒体数据流，也即实现了业务需求的调整。

在一种可能的实施方式中，业务需求调整系统可以在构建更新业务需求对应的第一有向图的同时，获取原业务需求对应的第二有向图，并比较第一有向图与第二有向图之间的差异，确定这两个有向图所描述的业务流中的差异元件以及差异时序关系，该差异元件指示了原始业务流与更新业务流中的存在差异的元件，该差异时序关系指示了原始业务流与更新业务流中存在差异的元件之间的时序关系。然后，业务需求调整系统可以根据两个有向图之间的差异，对差异部分进行分组，可以在第一有向图以及第二有向图中确定出一个或者多个分组，并且，两个有向图中对应分组所包含的元件存在差异，即第一有向图中的差异分组或者第二有向图中的差异分组至少包括一个差异元件。比如，第一有向图中的差异分组中可以包含第二有向图的差异部分中不包含的元件，即更新业务流是在原始业务流的基础上新增了部分元件；又比如，第二有向图中的差异分组中可以包含第一有向图的差异部分中不包含的元件，即更新业务流是在原始业务流的基础上删除了部分元件。

这样，业务需求调整系统可以根据第一有向图中的至少一个差异分组对原始业务流对应的第二元件集合中所包括的第二元件以及第二元件之间的调用关系进行调整。示例性的，业务需求调整系统可以将第二有向图中的至少一个组包括的差异元件，替换成第一有向图中的至少一个组所包括的差异元件，从而原始业务流在经过差异元件的替换后，所形成的新的业务流即为更新业务需求所对应的业务流。其中，当第一有向图与第二有向图中存在差异(包括元件差异和/或元件之间调用关系差异)的部分被划分为多个组时，业务流调整系统可以在原始业务流的基础上，逐个替换每个组对应的差异元件。即，以组为单位，在原始业务流的基础上，业务需求调整系统将原始业务流中每个分组所包括的元件替换成更新业务流中相应分组所包含的元件。示例性的，业务流调整系统逐个替换每个组对应的差异元件的顺序，可以是随机的，也可以是按照媒体数据流在各组元件中的传输顺序进行逐个组的元件替换，本实施例对此并不进行限定。

进一步的，针对于第一有向图中相对于第二有向图存在差异部分所划分的每个组，若该组中包含两个或者两个以上的差异元件，则这两个或两个以上的差异元件存在连接，并为第一有向图中需要连续调整的元件。即，针对于第一有向图与第二有向图之间的差异部分，第一有向图所对应的分组中包括的元件与第二有向图所对应的分组中包括的元件不存在相同元件。例如，原始业务流与更新业务流的差异部分可以包括两组元件，如图7所示的组1和组2，其中，原始业务流对应的组1包括元件2、组2包括元件4，更新业务流对应的组1包括元件6、组2包括元件7。则，在将原始业务流的差异部分中的元件替换为更新业务流中差异部分中的元件时，业务需求调整系统可以仅创建更新业务流相对于原始业务流出现的新元件，并利用该新元件对原始业务流中的元件进行替换。

可选的，在其它可能的实施方式中，第一有向图所对应的分组中包括的元件与第二有向图所对应的分组中包括的元件可以包含相同元件。例如，原始业务流与更新业务流之间的差异部分可以如图8所示，原始业务流的差异部分包括元件2、元件3以及元件4，而更新业务流的差异部分包括元件6、元件3以及元件7，即原始业务流以及更新业务流的差异部分可以包含相同的元件3。则，在将原始业务流的差异部分中的元件替换为更新业务流的差异部分中的元件时，业务需求调整系统可以重新创建元件3，并利用新创建的元件3替换原先的元件3。

由于在调整业务需求的过程中，媒体数据流可能在原始业务流中持续传输，因此，业务需求调整系统在对原始业务流中的元件进行替换时，可以先对原始业务流中传输至差异部分的媒体数据流进行拦截，并断开原始业务流中相对于更新业务流的差异部分元件与非差异部分元件之间的连接，再将原始业务流中差异部分元件替换为更新业务流中差异部分元件，然后再建立原始业务流中的非差异部分元件与新替换的元件之间的连接，此时，当前串联的元件即可构建成更新业务流。然后，业务需求调整系统可以将拦截的媒体数据流输入至新替换的元件中继续进行处理，并可以停止对媒体数据流的拦截。

具体的，业务需求调整系统在原始业务流的基础上更换差异元件之前，针对于任意一个分组(以下称之为第一组)，可以先确定该第一组在第二有向图中的起始位置以及终止位置，其中，该起始位置为第二有向图中与第一组相邻的前一个元件的数据输出位置，而该终止位置为第二有向图中与第一组相邻的后一个元件的数据输入位置。然后，业务需求调整系统可以拦截第二有向图中第一组的起始位置处探测到的数据，并断开该第一组与原始业务流中其它元件之间的连接，再将该第一组在第一有向图中对应的差异元件(也即替换的新元件)原始业务流中其它元件的建立连接，并控制替换的新元件运行。最后，业务需求调整系统可以将连接的数据输入至替换的新元件中，并在数据全部输入后，停止在第一组的起始位置处对于数据的拦截。

本实施例中，在对原始业务流中第一组中的元件进行更新时，该第一组中的元件所处理的数据(包括正在处理以及缓存的数据)可能会因为与其它元件之间的连接断开而发生数据丢失，因此，业务需求调整系统在断开原始业务流的第一组中的元件与其它元件的连接之前，还可以先等待该第一组中的元件完成对当前数据的处理，具体可以是从第二有向图中第一组的起始位置处开始传输结束事件，当该结束事件传输至与该第一组连接的下一元件时，表明该第一组中元件已经完成对所有数据的处理，从而业务需求调整系统可以断开第一组中的元件与原始业务流中的其它元件之间的连接，并建立新元件与原始业务流中的其它元件之间的连接。这样，在调整业务流的过程中，被第一组中的元件所处理的数据可以不因为元件被替换而发生丢失。

以基于Gstreamer处理框架的业务流为例，业务需求调整系统可以遍历原始业务流与更新业务流分别对应的有向图，并在遍历过程中比较这两个有向图中的节点与节点连接关系之间的差异，也即比较原始业务流与更新业务流中元件与元件连接关系之间的差异，并可以在有向图上对存在差异的节点以及边进行标识，以此得到原始业务流与更新业务流之间的差异部分。然后，业务需求调整系统可以利用探测机制对输入至原始业务流的差异部分的数据进行探测，并在确定存在数据流经该差异部分时，可以对该数据进行拦截。同时，业务需求调整系统可以利用Gstreamer处理框架的事件机制生成结束流(end ofstream，EOS) 事件，并将该EOS事件在原始业务流的差异部分所包含的元件中进行依次传递。其中，当原始业务流的差异部分所包含的元件接收到EOS事件后，可以在处理完当前正在处理以及缓存的数据后，将接收到的EOS事件向后传递至下一元件，这样，当下一元件接收到的 EOS事件时，表征上一元件中已经完成了对所有数据的处理。而当差异部分中的最后一个元件完成数据处理并将EOS事件传递至原始业务流中的其它元件(非差异部分中的元件) 时，业务需求调整系统可以在EOS事件传递至其它元件之前，删除该EOS事件，以避免该EOS事件对其它元件的影响。然后，业务需求调整系统可以断开差异部分中的元件与原始业务流中的其它元件之间的连接，并根据更新业务流的差异部分所包括的元件，删除更新业务流中不再需要的元件、创建更新业物流中新增的元件。接着，业务需求调整系统可以按照更新业务流的有向图将原始业务流中的其它元件与更新业务流的差异部分包含的元件进行连接，并设置该新元件处于正常运行状态，此时，当前串联的元件(包括原始业务流中的其它元件以及替换的新元件)即构成了更新业务流。最后，业务需求调整系统可以将拦截的数据输入至该元件中，以得到该数据在更新业务流下的处理结果，同时，停止对于数据的拦截以及探测过程。如此，实现了将基于Gstreamer处理框架的原始业务流调整为更新业务流，也即完成了对于业务需求的调整。

而且，在调整业务需求的过程中，避免传统技术中通过重启原业务需求的业务流所导致的中断对于媒体数据流的处理，使得业务流可以持续输出经过处理的媒体数据流，这样，可以向用户连续呈现该媒体数据流而不会发生中断，实现对于业务需求的在线调整。当媒体数据流具体为视频流时，在调整业务流的过程中，用户可以看到持续播放的视频，通常不会出现视频播放卡顿或者播放终止的问题。

进一步的，业务需求调整系统在完成业务需求的调整过程后，还可以向用户呈现调整业务需求时所涉及的相关信息。例如，业务需求调整系统可以向用户呈现如图9所示的调整结果显示界面，该调整结果显示界面中可以显示此次业务需求是否调整成功、原始业务流对应的第一有向图、更新业务流对应的第二有向图、原始业务流与更新业务流中存在差异的元件、该差异元件的功能描述等信息。当然，实际应用中，也可以是呈现上述信息中的任意一种或者多种信息，或者是呈现其它信息，本实施例对此并不进行限定。这样，用户可以在调整结果显示界面查看到此次业务需求的调整过程中的详细内容，提高了对于用户的透明度。

为便于理解本申请实施例的技术方案，下面结合图10所示的具体场景示例，对本申请实施例的技术方案进行示例性说明。参见图10，为基于Gstreamer处理框架下的原始业务流以及更新业务流的有向图。其中，业务需求调整系统包括客户端、应用平台和Gstreamer 处理框架。原始业务流用于对监控视频中的车辆进行识别，更新业务流用于对监控视频中的人脸进行识别。业务需求调整系统可以包括应用平台以及Gstreamer处理框架，并向用户呈现客户端。这样，在用户对业务流的编排操作下，业务需求调整系统能够将图10所示的原始业务流调整为更新业务流，具体可以执行如图11所示的业务流调整方法，包括：

S1101：客户端接收用户对原始业务流的编排操作，生成该原始业务流对应的有向图。

本实施例中，用户可以在业务需求调整系统所呈现的客户端上对业务流进行编排，如可以是在图6所示的业务流编排界面上对构成原始业务流的元件以及元件之间的连接关系进行编排。其中，该原始业务流包括的元件为：数据源提供元件、解码元件、目标检测元件、车辆识别元件以及显示元件。

如此，客户端可以根据用户的编排操作，生成原始业务流对应的有向图，该有向图中的节点用于指示原始业务流中的元件，而有向图中的边用于指示原始业务流中元件之间的连接关系，而边的方向即指示了数据流在元件之间传输的方向，如图10所示。

S1102：客户端将生成的有向图发送应用平台。

实际应用中，客户端可以将有向图对应的描述信息发送给应用平台，该描述信息可以描述该有向图中的节点以及节点之间的有向边。进一步的，客户端可以将每个节点所指示的元件信息发送给应用平台。当然，在其它可能的实施方式中，应用平台也可以预先保存有向图中得各个节点所对应的元件信息，而无需由客户端进行发送。

值得注意的是，本实施例中是以客户端以及应用平台为例，在其它实施例中，业务需求调整系统也可以是向用户呈现Web页面或者命令行输入界面等，并且，客户端可以是将有向图发送给应用，如多媒体应用或者AI应用等，本实施例对此并不进行限定。

S1103：应用平台根据接收到的有向图，生成创建并运行原始业务流的指令，并将该命令发送给Gstreamer处理框架。

S1104：Gstreamer处理框架响应接收到的指令，创建相应的元件并将其串联成管道，得到原始业务流，并运行该原始业务流中的各个元件。

实际应用中，原始业务流在运行一段时间后，用户可能需要对原始业务流进行调整，此时，用户可以在客户端上输入新的业务流(即更新业务流)的信息，以便于业务需求调整系统基于该信息调整业务流。

S1105：客户端接收用户对更新业务流的编排操作，生成该更新业务流对应的有向图，如图10所示。

其中，该更新业务流包括的元件为：数据源提供元件、解码元件、数据复制元件(用于对数据进行复制并分发至不同元件)、文件存储元件(用于将数据作为文件存储于本地)、目标检测元件、人脸识别元件以及显示元件。

S1106：客户端将更新业务流对应的有向图发送应用平台。

其中，步骤S1105与步骤S1106的具体实现，与步骤S1101、步骤S1102的具体实现类似，具体可以参见前述相关之处描述，在此不做赘述。

S1107：应用平台将原始业务流以及更新业务流的有向图进行比较，确定原始业务流的有向图与更新业务流的有向图之间存在差异的节点和边，并对其进行标识。

具体实现时，应用平台可以遍历原始业务流的有向图中的节点，并在遍历该节点时，可以将其与更新业务流中的有向图中的节点进行比较，确定两个节点是否指示同一元件，若是，则确定这两个有向图中该处节点相同，否则确定原始有向图中的该处节点与目标有向图中的该处节点存在差异，并进行标识。通过将原始业务流的有向图中的节点逐个与更新业务流的有向图中的节点进行比较，可以在原始业务流的有向图上标识出与目标有向图存在差异的节点以及相应的边。同时，应用平台还可以基于类似方式，在更新业务流的有向图上标识出与原始业务流存在差异的节点以及相应的边，其具体实现与前述类似，在此不做赘述。

S1108：应用平台可以确定原始业务流以及更新业务流之间的差异部分，并在有向图上分别标识出该差异部分对应的边界。

如图10所示，应用平台可以确定原始业务流以及更新业务流之间有两部分元件存在差异，分别为两个有向图上的组1以及组2。应用平台可以将两个有向图中存在差异的连续节点划入一组(也即将存在差异并且相互连接的元件划入一组)，并分别对划分得到的组1以及组2的边界进行标识，分别对应于图10所示的(起始位置₁，终止位置₁)以及 (起始位置₂，终止位置₂)。

S119：针对于每组差异部分，应用平台可以向Gstreamer处理框架发送探测指令。

S1110：Gstreamer处理框架基于探测指令，探测每组差异部分的前边界是否存在新输入数据，以及探测是否存在EOS事件传输至后边界，并实时向应用平台反馈探测结果。

S1111：应用平台当根据Gstreamer处理框架反馈的探测结果确定存在新输入至前边界的数据时，对该数据进行拦截，同时，应用平台生成EOS事件并将其发送给Gstreamer处理框架。

S1112：Gstreamer处理框架控制差异部分中的元件在处理完当前正在处理以及缓存数据时，将接收到的EOS事件向后传输至下一元件。

S1113：应用平台若根据Gstreamer处理框架反馈的探测结果确定在差异部分的后边界探测到EOS事件，则丢弃该EOS事件。

S1114：应用平台生成断开连接指令，该断开连接指令用于指示Gstreamer处理框架断开原始业物流的每组差异部分中的元件与其它部分元件之间的连接，并将其发送给Gstreamer处理框架。

S1115：Gstreamer处理框架执行接收到的断开连接指令，断开相应元件之间的连接。

S1116：应用平台生成元件更新指令，该元件更新指令用于指示Gstreamer处理框架剔除原始业务流的每组差异部分中的元件，并新建更新业务流的差异部分的元件，将该元件更新指令发送给Gstreamer处理框架。

S1117：Gstreamer处理框架执行接收到的元件更新指令，删除原始业务流中的不被需要的元件、创建更新业务流的新元件并连接该新元件。

S1118：应用平台生成连接指令，该连接指令用于指示Gstreamer处理框架将原始业物流中的剩余元件与更新业务流的新元件建立连接，并将其发送给Gstreamer处理框架。

S1119：Gstreamer处理框架执行接收到的连接指令，连接原始业物流中的剩余元件与更新业务流的差异部分中的新元件。

S1120：在Gstreamer处理框架完成元件连接后，应用平台可以设置该新元件处于正常运行状态。

S1121：应用平台取消在差异部分的边界处对于数据以及事件的探测。

具体实现时，应用平台可以向Gstreamer处理框架发送取消探测的指令，以取消数据以及事件的探测过程。

S1122：应用平台将拦截的数据输入至更新业务流的差异部分的新元件中，并取消数据拦截过程。

实际应用中，应用平台可以由业务需求调整系统中的主处理器实现，而Gstreamer处理框架所执行的内容可以由协处理器实现。当然，也可以是基于其它可能的实现方式进行实现，本实施例对此并不进行限定。

如此，实现了将图10所示的原始业务流调整为更新业务流，并且在调整过程中，业务流对于数据的处理可以不发生中断，如此，降低了调整业务流对于播放监控视频以及车辆/人脸识别结果的影响。

值得注意的是，本领域的技术人员根据以上描述的内容，能够想到的其他合理的步骤组合，也属于本申请的保护范围内。其次，本领域技术人员也应该熟悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作并不一定是本申请所必须的。

上文中结合图1至图11，详细描述了本申请所提供的业务需求调整方法，下面将结合图12至图13，描述根据本申请所提供的业务需求调整装置和业务需求调整系统。

图12为本申请提供的一种业务需求调整装置的结构示意图，该业务需求调整装置1200 可以包括：

构建模块1201，用于根据更新业务需求构建第一元件集合，所述第一元件集合包括多媒体处理框架中执行所述更新业务需求所需的所有第一元件的标识和第一时序关系，所述第一时序关系用于标识所述所有第一元件之间的调用关系；

调整模块1202，用于根据所述第一元件集合调整第二元件集合，所述第二元件集合包括所述多媒体处理框架中执行原业务需求的所有第二元件以及所述第二元件之间的调用关系；

处理模块1203，用于按照调整后的所述第二元件集合完成业务需求处理。

在一种可能的实施方式中，所述装置1200还包括:

获取模块1204，用于在所述根据更新业务需求构建第一元件集合之前，获取所述第二元件集合，所述第二元件集合包括所述多媒体处理框架中执行原业务需求所需的所有第二元件和第二时序关系，所述第二时序关系用于标识所述所有第二元件之间的调用关系。

在一种可能的实施方式中，所述构建模块1201，用于：在所述多媒体流处理框架中确定执行所述更新业务需求所需的所有第一元件；按照处理所述更新业务需求的流程确定所述第一时序关系；根据所述第一时序关系以及所述所有第一元件构建所述第一元件集合。

在一种可能的实施方式中，所述第一元件集合包括第一有向图，所述第一有向图用于标识所述所有第一元件和所述第一时序关系；所述第二元件集合包括第二有向图，所述第二有向图用于标识所述所有第二元件和所述第二时序关系。

在一种可能的实施方式中，所述调整模块1202，用于：比较所述第一有向图和所述第二有向图确定差异元件和差异时序关系；根据所述差异元件和所述差异时序关系确定所述第一有向图中的至少一个组，每个组中包括至少一个差异元件；根据所述第一有向图中的至少一个组对所述第二元件集合进行调整。

在一种可能的实施方式中，当所述至少一个组中存在一个组包括两个或两个以上差异元件时，所述两个或两个以上差异元件为所述第一有向图中需要连续调整的元件。

在一种可能的实施方式中，所述调整模块1202，具体用于将所述第二有向图中的至少一个组包括的差异元件，替换成为所述第一有向图中的至少一个组包括的差异元件。

在一种可能的实施方式中，所述第二有向图中的至少一个组包括第一组，所述装置 1200还包括：

探测模块1205，用于探测所述第二有向图中传输至所述第一组的起始位置的数据所述起始位置为所述第二有向图中与所述第一组相邻的前一元件的数据输出位置；

拦截模块1206，用于拦截在所述第二有向图中第一组的起始位置处探测到的数据，并将拦截到的数据输入至所述第一组在所述第一有向图中对应的差异元件。

在一种可能的实施方式中，所述第一组还具有终止位置，所述终止位置为所述第二有向图中与所述第一组相邻的后一元件的数据输入位置，所述装置1200还包括：

传输模块1207，用于从所述第二有向图中第一组的起始位置处开始传输结束事件，所述结束事件用于标识所述第二有向图中第一组包括的元件处理完数据；

删除模块1208，用于删除在所述第二有向图中第一组的终止位置处探测到的结束事件。

根据本申请实施例的业务需求调整装置1200可对应于执行本申请实施例中描述的方法，并且业务需求调整装置1200的各个模块的上述和其它操作和/或功能分别为了实现图 4中的各个方法的相应流程，为了简洁，在此不再赘述。

图13为本申请提供的一种业务需求调整系统1300的示意图，如图所示，所述业务需求调整系统1300包括处理器1301、存储器1302、通信接口1303。其中，处理器1301、存储器1302、通信接口1303通过总线1304进行通信，也可以通过无线传输等其他手段实现通信。该存储器1302用于存储指令，该处理器1301用于执行该存储器1302存储的指令。进一步的，业务需求调整系统1300还可以包括内存单元1305，还内存单元1305可以通过总线1304与处理器1301、存储介质1302以及通信接口1303连接。其中，该存储器 1302存储程序代码，且处理器1301可以调用存储器1302中存储的程序代码执行以下操作：

根据更新业务需求构建第一元件集合，所述第一元件集合包括多媒体处理框架中执行所述更新业务需求所需的所有第一元件的标识和第一时序关系，所述第一时序关系用于标识所述所有第一元件之间的调用关系；

根据所述第一元件集合调整第二元件集合，所述第二元件集合包括所述多媒体处理框架中执行原业务需求的所有第二元件以及所述第二元件之间的调用关系；

按照调整后的所述第二元件集合完成业务需求处理。

应理解，在本申请实施例中，该处理器1301可以是CPU，该处理器1301还可以是其他通用处理器、数字信号处理器(DSP)、专用集成电路(ASIC)、现场可编程门阵列(FPGA) 或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立器件组件等。通用处理器可以是微处理器或者是任何常规的处理器等。

该存储器1302可以包括只读存储器和随机存取存储器，并向处理器1301提供指令和数据。存储器1302还可以包括非易失性随机存取存储器。例如，存储器1302还可以存储设备类型的信息。

该存储器1302可以是易失性存储器或非易失性存储器，或可包括易失性和非易失性存储器两者。其中，非易失性存储器可以是只读存储器(read-only memory，ROM)、可编程只读存储器(programmable ROM，PROM)、可擦除可编程只读存储器(erasable PROM，EPROM)、电可擦除可编程只读存储器(electrically EPROM，EEPROM)或闪存。易失性存储器可以是随机存取存储器(random access memory，RAM)，其用作外部高速缓存。通过示例性但不是限制性说明，许多形式的RAM可用，例如静态随机存取存储器(static RAM，SRAM)、动态随机存取存储器(DRAM)、同步动态随机存取存储器(synchronous DRAM，SDRAM)、双倍数据速率同步动态随机存取存储器(double data date SDRAM,DDR SDRAM)、增强型同步动态随机存取存储器(enhanced SDRAM，ESDRAM)、同步连接动态随机存取存储器(synchlinkDRAM，SLDRAM)和直接内存总线随机存取存储器(direct rambus RAM，DR RAM)。

该通信接口1303用于与业务需求调整系统1300连接的其它设备进行通信。该总线1304除包括数据总线之外，还可以包括电源总线、控制总线和状态信号总线等。但是为了清楚说明起见，在图中将各种总线都标为总线1304。

应理解，根据本申请实施例的业务需求调整系统1300可对应于本申请实施例中的业务需求调整装置1200，并可以对应于执行根据本申请实施例中图4所示方法中的相应主体，并且业务需求调整系统1300所实现的上述和其它操作和/或功能分别为了实现图4中的各个方法的相应流程，为了简洁，在此不再赘述。

作为一种可能的实施例，本申请所提供的业务需求调整系统也可以由多个如图13所示的设备构成，多个设备之间通过网络进行通信，该系统用于实现上述图4中的各个方法的相应流程，为了简洁，在此不再赘述。

作为一种可能的实施例，本申请还提供了一种加速卡，该加速卡可以应用于计算设备，并使得计算设备可以实现图4中的各个方法的相应流程，例如，该加速卡可以是以高速串行计算机扩展总线标准(peripheral component interconnect express，PCIE)卡或其他板卡、插卡的形式接入设备(例如，服务器)中，以使得服务器能够实现上述图4所示的相应流程，其中，计算设备的结构可以参见如图13所示的业务需求调整系统1300。为了简洁，在此不再赘述。

上述实施例，可以全部或部分地通过软件、硬件、固件或其他任意组合来实现。当使用软件实现时，上述实施例可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载或执行所述计算机程序指令时，全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以为通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集合的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质(例如，软盘、硬盘、磁带)、光介质(例如，DVD)、或者半导体介质。半导体介质可以是固态硬盘(solid state drive，SSD)

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

Claims (21)

1.一种业务需求调整方法，其特征在于，所述方法包括：

根据更新业务需求构建第一元件集合，所述第一元件集合包括多媒体处理框架中执行所述更新业务需求所需的所有第一元件的标识和第一时序关系，所述第一时序关系用于标识所述所有第一元件之间的调用关系；

根据所述第一元件集合调整第二元件集合，所述第二元件集合包括所述多媒体处理框架中执行原业务需求的所有第二元件以及所述第二元件之间的调用关系；

按照调整后的所述第二元件集合完成业务需求处理。

2.根据权利要求1所述的方法，其特征在于，在所述根据更新业务需求构建第一元件集合之前，所述方法还包括:

获取所述第二元件集合，所述第二元件集合包括所述多媒体处理框架中执行原业务需求所需的所有第二元件和第二时序关系，所述第二时序关系用于标识所述所有第二元件之间的调用关系。

3.根据权利要求1或2所述的方法，其特征在于，所述根据更新业务需求构建第一元件集合，包括：

在所述多媒体流处理框架中确定执行所述更新业务需求所需的所有第一元件的标识；

按照处理所述更新业务需求的流程确定所述第一时序关系；

根据所述第一时序关系以及所述所有第一元件的标识构建所述第一元件集合。

4.根据权利要求2或3所述的方法，其特征在于，所述第一元件集合包括第一有向图，所述第一有向图用于标识所述所有第一元件和所述第一时序关系；所述第二元件集合包括第二有向图，所述第二有向图用于标识所述所有第二元件和所述第二时序关系。

5.根据权利要求4所述的方法，其特征在于，所述根据所述第一元件指示信息调整第二元件集合，包括：

比较所述第一有向图和所述第二有向图确定差异元件和差异时序关系；

根据所述差异元件和所述差异时序关系确定所述第一有向图中的至少一个组，每个组中包括至少一个差异元件；

根据所述第一有向图中的至少一个组对所述第二元件集合进行调整。

6.根据权利要求5所述的方法，其特征在于，当所述至少一个组中存在一个组包括两个或两个以上差异元件时，所述两个或两个以上差异元件为所述第一有向图中需要连续调整的元件。

7.根据权利要求6所述的方法，其特征在于，所述根据所述第一有向图中的至少一个组对所述第二元件集合进行调整，包括：

将所述第二有向图中的至少一个组包括的差异元件，替换成为所述第一有向图中的至少一个组包括的差异元件。

8.根据权利要求7所述的方法，其特征在于，所述第二有向图中的至少一个组包括第一组，所述方法还包括：

探测所述第二有向图中传输至所述第一组的起始位置的数据，所述起始位置为所述第二有向图中与所述第一组相邻的前一个第二元件的数据输出位置；

拦截在所述第二有向图中第一组的起始位置处探测到的数据，并将拦截到的数据输入至所述第一组在所述第一有向图中关联的差异元件。

9.根据权利要求8所述的方法，其特征在于，所述第一组在所述第二图中还具有终止位置，所述终止位置为所述第二有向图中与所述第一组相邻的后一个第二元件的数据输入位置，所述方法还包括：

从所述第二有向图中第一组的起始位置处开始传输结束事件，所述结束事件用于标识所述第二有向图中第一组包括的元件处理完数据；

删除在所述第二有向图中第一组的终止位置处探测到的结束事件。

10.一种业务需求调整装置，其特征在于，所述装置包括：

构建模块，用于根据更新业务需求构建第一元件集合，所述第一元件集合包括多媒体处理框架中执行所述更新业务需求所需的所有第一元件的标识和第一时序关系，所述第一时序关系用于标识所述所有第一元件之间的调用关系；

调整模块，用于根据所述第一元件集合调整第二元件集合，所述第二元件集合包括所述多媒体处理框架中执行原业务需求的所有第二元件以及所述第二元件之间的调用关系；

处理模块，用于按照调整后的所述第二元件集合完成业务需求处理。

11.根据权利要求10所述的装置，其特征在于，所述装置还包括:

获取模块，用于在所述根据更新业务需求构建第一元件集合之前，获取所述第二元件集合，所述第二元件集合包括所述多媒体处理框架中执行原业务需求所需的所有第二元件和第二时序关系，所述第二时序关系用于标识所述所有第二元件之间的调用关系。

12.根据权利要求10或11所述的装置，其特征在于，所述构建模块，用于：

在所述多媒体流处理框架中确定执行所述更新业务需求所需的所有第一元件；

按照处理所述更新业务需求的流程确定所述第一时序关系；

根据所述第一时序关系以及所述所有第一元件构建所述第一元件集合。

13.根据权利要求11或12所述的装置，其特征在于，所述第一元件集合包括第一有向图，所述第一有向图用于标识所述所有第一元件和所述第一时序关系；所述第二元件集合包括第二有向图，所述第二有向图用于标识所述所有第二元件和所述第二时序关系。

14.根据权利要求13所述的装置，其特征在于，所述调整模块，用于：

比较所述第一有向图和所述第二有向图确定差异元件和差异时序关系；

根据所述差异元件和所述差异时序关系确定所述第一有向图中的至少一个组，每个组中包括至少一个差异元件；

根据所述第一有向图中的至少一个组对所述第二元件集合进行调整。

15.根据权利要求14所述的装置，其特征在于，当所述至少一个组中存在一个组包括两个或两个以上差异元件时，所述两个或两个以上差异元件为所述第一有向图中需要连续调整的元件。

16.根据权利要求15所述的装置，其特征在于，所述调整模块，具体用于将所述第二有向图中的至少一个组包括的差异元件，替换成为所述第一有向图中的至少一个组包括的差异元件。

17.根据权利要求16所述的装置，其特征在于，所述第二有向图中的至少一个组包括第一组，所述装置还包括：

探测模块，用于探测所述第二有向图中传输至所述第一组的起始位置的数据，所述起始位置为所述第二有向图中与所述第一组相邻的前一元件的数据输出位置；

拦截模块，用于拦截在所述第二有向图中第一组的起始位置处探测到的数据，并将拦截到的数据输入至所述第一组在所述第一有向图中关联的差异元件。

18.根据权利要求17所述的装置，其特征在于，所述第一组还具有终止位置，所述终止位置为所述第二有向图中与所述第一组相邻的后一元件的数据输入位置，所述装置还包括：

传输模块，用于从所述第二有向图中第一组的起始位置处开始传输结束事件，所述结束事件用于标识所述第二有向图中第一组包括的元件处理完数据；

删除模块，用于删除在所述第二有向图中第一组的终止位置处探测到的结束事件。

19.一种业务调整系统，其特征在于，包括处理器和存储器；

所述存储器，用于存储计算机指令；

所述处理器，用于根据所述计算机指令执行如权利要求1至9任一项所述方法的操作步骤。

20.一种加速卡，其特征在于，所述加速卡应用于计算设备，使得所述计算设备实现如权利要求1至9任一项所述方法的操作步骤。

21.一种计算机可读存储介质，其特征在于，包括指令，所述指令用于实现如权利要求1至9中任一项所述方法的操作步骤。

Images