基于车险理赔的媒体混流方法及装置

技术领域

本申请涉及视频混流技术领域，尤其涉及一种基于车险理赔的媒体混流方法及装置。

背景技术

车险视频理赔受限于技术影响，视频的品质好坏不一，导致用户体验不好，而在业务场景中，用户发生车祸后对于时效性的要求极高，必须确保用户以及坐席两者之间的视频通畅。

目前，相关技术中，由于技术不成熟大多不使用视频混流，虽然不使用视频混流的话，程序不需要额外判断，节省了混流的时间，并且可以避免服务器资源的消耗，成本较低，应用在低延迟、用户方以及服务方单纯推拉流的场景下效果较好，但在实际的业务场景中，会受到网路抖动，双方不同步的状况，而在发生事故的场景中，还难以支持多个保险公司坐席、交管等等同时在同一界面直播。

针对上述的问题，目前尚未提出有效的解决方案。

发明内容

本申请提供了一种基于车险理赔的媒体混流方法及装置，以解决车险理赔场景中用户端以及服务端双方画面不一致的技术问题。

根据本申请实施例的一个方面，本申请提供了一种基于车险理赔的媒体混流方法，应用于理赔平台，包括：接收第一视频终端发送的第一媒体流和第二视频终端发送的第二媒体流，第一视频终端用于请求资源补偿，第二视频终端用于在执行资源补偿时使用，第一媒体流用于传输第一视频终端采集到的第一画面，第二媒体流用于传输第二视频终端采集到的第二画面；向第三方平台发送第一媒体流和第二媒体流，并调用第三方平台将第一媒体流和第二媒体流混流，以得到反馈的目标媒体流；将目标媒体流推送至第一视频终端和第二视频终端，以在第一视频终端和第二视频终端上同步展示第一画面和第二画面。

根据本申请实施例的另一方面，本申请提供了一种基于车险理赔的媒体混流方法，应用于第三方平台，包括：接收理赔平台发送的第一媒体流和第二媒体流，第一媒体流用于传输第一视频终端采集到的第一画面，第二媒体流用于传输第二视频终端采集到的第二画面；在接收到在线查勘指令的情况下，将第一媒体流和第二媒体流混流，得到目标媒体流。

根据本申请实施例的另一方面，本申请提供了一种基于车险理赔的媒体混流装置，应用于理赔平台，包括：第一接收模块，用于接收第一视频终端发送的第一媒体流和第二视频终端发送的第二媒体流，第一视频终端用于请求资源补偿，第二视频终端用于在执行资源补偿时使用，第一媒体流用于传输第一视频终端采集到的第一画面，第二媒体流用于传输第二视频终端采集到的第二画面；第三方平台调用模块，用于向第三方平台发送第一媒体流和第二媒体流，并调用第三方平台将第一媒体流和第二媒体流混流，以得到反馈的目标媒体流；混流推送模块，用于将目标媒体流推送至第一视频终端和第二视频终端，以在第一视频终端和第二视频终端上同步展示第一画面和第二画面。

根据本申请实施例的另一方面，本申请提供了一种基于车险理赔的媒体混流装置，应用于第三方平台，包括：第二接收模块，用于接收理赔平台发送的第一媒体流和第二媒体流，第一媒体流用于传输第一视频终端采集到的第一画面，第二媒体流用于传输第二视频终端采集到的第二画面；混流模块，用于在接收到在线查勘指令的情况下，将第一媒体流和第二媒体流混流，得到目标媒体流，并将目标媒体流发送至理赔平台。

根据本申请实施例的另一方面，本申请提供了一种电子设备，包括存储器、处理器、通信接口及通信总线，存储器中存储有可在处理器上运行的计算机程序，存储器、处理器通过通信总线和通信接口进行通信，处理器执行计算机程序时实现上述方法。

根据本申请实施例的另一方面，本申请还提供了一种具有处理器可执行的非易失的程序代码的计算机可读介质，程序代码使处理器执行上述的方法。

本申请实施例提供的上述技术方案与相关技术相比具有如下优点：

本申请技术方案为接收第一视频终端发送的第一媒体流和第二视频终端发送的第二媒体流，第一视频终端用于请求资源补偿，第二视频终端用于在执行资源补偿时使用，第一媒体流用于传输第一视频终端采集到的第一画面，第二媒体流用于传输第二视频终端采集到的第二画面；向第三方平台发送第一媒体流和第二媒体流，并调用第三方平台将第一媒体流和第二媒体流混流，以得到反馈的目标媒体流；将目标媒体流推送至第一视频终端和第二视频终端，以在第一视频终端和第二视频终端上同步展示第一画面和第二画面。本申请解决了车险理赔场景中用户端以及服务端双方画面不一致的技术问题，为多方视频理赔提供了稳定的技术方案，并通过混流多路流进行画面对齐和音画同步，同时通过缓冲对抗网络抖动。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本申请的实施例，并与说明书一起用于解释本申请的原理。

为了更清楚地说明本申请实施例或相关技术中的技术方案，下面将对实施例或相关技术描述中所需要使用的附图作简单地介绍，显而易见地，对于本领域普通技术人员而言，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为根据本申请实施例提供的一种可选的基于车险理赔的媒体混流方法硬件环境示意图；

图2为根据本申请实施例提供的一种可选的理赔平台侧基于车险理赔的媒体混流方法流程图；

图3为根据本申请实施例提供的一种可选的多方事故联合线上查勘示意图；

图4为根据本申请实施例提供的一种可选的单车事故线上查勘示意图；

图5为根据本申请实施例提供的一种可选的视频会话创建流程图；

图6为根据本申请实施例提供的一种可选的基于车险理赔的业务节点确定流程图；

图7为根据本申请实施例提供的一种可选的基于车险理赔的媒体混流终止流程图；

图8为根据本申请实施例提供的一种可选的保险公司坐席端视频理赔界面示意图；

图9为根据本申请实施例提供的一种可选的第三方平台侧基于车险理赔的媒体混流方法流程图；

图10为根据本申请实施例提供的一种可选的基于车险理赔的媒体混流方法流程图；

图11为根据本申请实施例提供的一种可选的基于车险理赔的媒体混流方法时序图；

图12为根据本申请实施例提供的一种可选的理赔平台侧基于车险理赔的媒体混流装置框图；

图13为根据本申请实施例提供的一种可选的第三方平台侧基于车险理赔的媒体混流装置框图；

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

具体实施方式

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

在后续的描述中，使用用于表示元件的诸如“模块”、“部件”或“单元”的后缀仅为了有利于本申请的说明，其本身并没有特定的意义。因此，“模块”与“部件”可以混合地使用。

首先，在对本申请实施例进行描述的过程中出现的部分名词或者术语适用于如下解释：

车险：指根据法律规定实行的中国大陆地区市场销售的“机动车交通事故责任强制保险”和“机动车商业保险”两款保险产品。

车险理赔：被保人发生车险保障范围内的事故，保险人依据保单合同对被保险人去赔偿损失的过程。

相关技术中，由于技术不成熟大多不使用视频混流，虽然不使用视频混流的话，程序不需要额外判断，节省了混流的时间，并且可以避免服务器资源的消耗，成本较低，应用在低延迟、用户方以及服务方单纯推拉流的场景下效果较好，但在实际的业务场景中，会受到网路抖动，双方不同步的状况，而在发生事故的场景中，还难以支持多个保险公司坐席、交管等等同时在同一界面直播，不能提供记录有各方画面的视频记录，不利于监管。

为了解决背景技术中提及的问题，根据本申请实施例的一方面，提供了一种基于车险理赔的媒体混流方法的实施例。

可选地，在本申请实施例中，上述基于车险理赔的媒体混流方法可以应用于如图1所示的由终端101和服务器103所构成的硬件环境中，上述终端可以是请求车险理赔的用户终端，可以是保险公司坐席平台的终端，还可以是事故处理的交管的终端设备，上述服务器可以是车险理赔平台的服务器，还可以是音视频处理平台的服务器。如图1所示，服务器103通过网络与终端101进行连接，可用于为终端或终端上安装的客户端提供服务，可在服务器上或独立于服务器设置数据库105，用于为服务器103提供数据存储服务，上述网络包括但不限于：广域网、城域网或局域网，终端101包括但不限于PC、手机、平板电脑等。

本申请实施例中的一种基于车险理赔的媒体混流方法可以由服务器103来执行，还可以是由服务器103和终端101共同执行，如图2所示，该方法可以包括以下步骤：

步骤S202，接收第一视频终端发送的第一媒体流和第二视频终端发送的第二媒体流，第一视频终端用于请求资源补偿，第二视频终端用于在执行资源补偿时使用，第一媒体流用于传输第一视频终端采集到的第一画面，第二媒体流用于传输第二视频终端采集到的第二画面。

本申请实施例中，资源补偿即进行车险理赔，上述第一视频终端为用户使用的终端设备，该用户为发生了交通事故或其他事故从而请求进行车险理赔，即该用户为保单干系人，上述第二视频终端为各个保险公司坐席平台使用的终端设备，各个保险公司坐席平台为处理车险理赔相关事项的工作人员，需要说明的是，本申请实施例中第二终端设备可以不仅仅是一台终端设备，可以是多台，即参与车险理赔的保险公司执行人员，可以是一个保险公司的多个工作人员对应的终端设备，还可以是相关各方的多家保险公司的多个工作人员对应的终端设备。

可选地，上述第二视频终端设备还可以是保险公司查勘员及处理事故的交管人员所使用的设备。

本申请实施例中，可以接收用户视频和各个保险公司坐席的视频，从而将多方视频流进行混流，以使多方视频能够在同一画面中进行展示。

步骤S204，向第三方平台发送第一媒体流和第二媒体流，并调用第三方平台将第一媒体流和第二媒体流混流，以得到反馈的目标媒体流。

本申请实施例中，视频混流的开始时间点由具体的业务场景决定，可以通过各方确认的方式，找到车险理赔相关各方都认知的时间点作为视频混流的开始时间点，确保了多方视频的情况下能够有效保证各方的画面一致性。找到车险理赔相关各方都认知的时间点后，通过调用第三方平台如音视频处理平台、云端或通过DirectX等多媒体处理引擎来进行音视频混流。

步骤S206，将目标媒体流推送至第一视频终端和第二视频终端，以在第一视频终端和第二视频终端上同步展示第一画面和第二画面。

如图3所示，采用本申请技术方案，作为一个实施例，可以实现多方事故联合线上查勘，即在事故相关方的视频显示界面同时显示各方设备采集的图像。其中视频参与方不仅可以包括保险理赔人、保险公司坐席，还可以包括处理事故的交管、事故当事人。例如，事故肇事方、肇事方保险公司坐席、保险理赔方、理赔方保险公司坐席、交管等。理赔平台接收上述各方发送的视频流，并将所有视频流整合发送至第三方平台。理赔平台向参与各方发出在线查勘请求，各方确定可以进行在线查勘后，生成在线查勘指令，利用该指令调用第三方平台开始进行视频混流，得到第三方平台反馈的混流视频，最后理赔平台向各方推送混流视频，从而使各方画面保持一致。

如图4所示，作为另一个实施例，本申请技术方案还可以进行单车事故线上查勘，即显示界面的主画面由保险理赔方拍摄事故车辆，副画面显示保险公司坐席，以在同一个画面中表示保险公司坐席进行事故查勘的过程。单车事故线上查勘的参与方只涉及一方事故车辆及该事故车辆对应的一家保险公司。首先理赔平台接收保险理赔方和保险公司坐席发送的视频流，并将两个视频流整合发送至第三方平台。理赔平台向参与双方发出在线查勘请求，双方确定可以进行在线查勘后，生成在线查勘指令，利用该指令调用第三方平台开始进行视频混流，得到第三方平台反馈的混流视频，最后理赔平台向双方推送混流视频，从而使双方画面保持一致。

保险业是属于高度监管行业，需要录制用户报案相关细节，必须保存视频，而保存视频必须通过混流才可以记录下多方理赔的画面，否则仅能记录单一视频流，不利于监管。

相较于传统的一个用户发生车险保单承保范围内的事件，例如车碰车等情况，此时用户会报案联络保险公司，保险公司知道用户出险后，会安排工作人员前往事发地进行查勘，了解用户出险的情况，是否有造成人伤，车辆是否涉及多辆车碰撞等，而了解事故相关的信息后，根据查勘中了解的损失，例如车辆损失的部位以及状况等，确认赔偿金额，而后将确定损失金额赔偿给用户，所有相关责任均结束后，则一笔理赔案件结束的车险理赔流程，工作人员往往到达事发地需要较长时间，若事发地发生交通阻塞则会更加耗费时间，给用户带来非常不好的体验。本申请实施例将用户报案、保险公司查勘的环节通过线上视频的方式进行车险理赔，能够极大提升车险理赔的处理效率，并且还可以节省下大量查勘成本。

可选地，如图5所示，接收第一视频终端发送的第一媒体流和第二视频终端发送的第二媒体流之前，该方法还包括按照如下方式创建视频会话：

步骤S502，在接收到第一视频终端发送的第一视频发起请求的情况下，建立第一会话，第一会话携带有第一标识，第一视频发起请求携带有请求资源补偿的对象的信息；

步骤S504，将第一标识发送至第二视频终端，以供第二视频终端通过第一标识连接第一会话，并在第二视频终端上展示请求资源补偿的对象的信息。

本申请实施例中，用户可以通过第一视频终端上的小程序等应用来发送第一视频发起请求，首先用户在小程序上完成授权验证，以将第一视频终端和车险理赔平台服务器建立websocket连接，websocket连接建立完成后，用户即可以点击发起视频理赔，车险理赔平台接收到第一视频发起请求时，创建第一会话，以提供用户和保险公司等各方进行信息交互，此时第一视频终端已经位于该第一会话中。上述第一会话为一个通信的进程，用户及保险公司各方在该进程中完成信息交互。第一会话携带有第一标识，车险理赔平台将第一标识发送至保险公司坐席平台，各个保险公司的坐席人员即可以通过第一标识加入第一会话。同时，车险理赔平台还同时将对象的信息(用户的信息、交通事故信息)等发送至保险公司坐席平台，以供各个保险公司的坐席人员进行信息确认。

可选地，将第一标识发送至第二视频终端之后，该方法还包括：在第二视频终端通过第一标识连接至第一会话的情况下，创建第一视频房间，第一视频房间携带有第二标识；将第一标识和第二标识发送至第一视频终端和第二视频终端，以使第一视频终端通过第一标识和第二标识在第一会话的第一视频房间中进行第一媒体流的传输，并使第二视频终端通过第一标识和第二标识在第一会话的第一视频房间中进行第二媒体流的传输；在第二视频终端在第一时间阈值内未连接至第一会话的情况下，将第一会话推送至等待队列，以在第二视频终端连接至第一会话时重新唤起第一会话的进程，或者，在第二视频终端在第二时间阈值内仍未连接至第一会话的情况下，结束第一会话。

本申请实施例中，第一会话还可以随着功能的不断扩展完成更多任务，为了保证视频理赔任务不受其他功能干扰，可以在第一会话中创建第一视频房间，以为视频理赔创建单独的子进程，第一视频房间携带有第二标识，用户及保险公司坐席各方可以通过第一标识和第二标识从而准确地加入到第一会话中的第一视频房间。

保险公司坐席平台在一段时间内没有加入到第一会话的情况下，车险理赔平台将第一会话的进程推送至等待队列，以在保险公司坐席平台连接至第一会话时重新唤起第一会话的进程。而保险公司坐席平台在更长的一段时间后仍未加入第一会话的情况下，车险理赔平台结束第一会话，当前车险理赔任务结束。

可选地，如图6所示，将第一媒体流和第二媒体流混流之前，该方法还包括按照如下方式生成在线查勘指令：

步骤S602，检测第一视频终端和第二视频终端的网络时延；

步骤S604，在第一视频终端和第二视频终端的网络时延均小于目标阈值的情况下，向第一视频终端和第二视频终端发送在线查勘请求，以由请求资源补偿的对象和执行资源补偿的对象确认是否开始在线查勘；

步骤S606，在接收到第一视频终端和第二视频终端响应在线查勘请求的确认信息的情况下，生成在线查勘指令。

本申请实施例中，车险理赔平台可以通过TCP/IP网络体系结构中应用层的服务命令来对第一视频终端和第二视频终端进行网络时延检测，如PING方法等。PING方法用于确定本地主机是否能与另一台主机成功交换(发送与接收)数据包，再根据返回的信息，就可以推断TCP/IP参数是否设置正确，以及运行是否正常、网络是否通畅等。一般情况下，为了保证可以进行正常的实时数据传输，可以设置一个网络时延的目标阈值，低于该目标阈值表示网络时延可以被用户接受，同时也不影响数据实时传输，高于该目标阈值，表示当前网络时延已经影响到了数据实时传输，需调整网络参数，或等待网络时延降低。作为优选，目标阈值可以是50ms，还可以根据实际需要进行设置。

本申请实施例中，视频混流的开始时间点由具体的业务场景决定，可以通过各方确认的方式，找到车险理赔相关各方都认知的时间点作为视频混流的开始时间点，确保了多方视频的情况下能够有效保证各方的画面一致性。上述视频混流的开始时间点即可由在线查勘指令来确定，车险理赔平台在确认相关各方都已准备完毕的情况下，生成在线查勘指令，由在线查勘指令调用第三方平台进行音视频混流。

可选地，如图7所示，将目标媒体流推送至第一视频终端和第二视频终端之后，该方法还包括：

步骤S702，在接收到第二视频终端发送的第一视频终止请求的情况下，将第一视频终止请求发送至第一视频终端，并终止将第一媒体流和第二媒体流混流为目标媒体流，由开始混流至终止混流的目标媒体流得到资源补偿视频记录；

步骤S704，在第一视频终端和第二视频终端断开连接的情况下，结束第一会话，并保存资源补偿视频记录。

本申请实施例中，如图8所示的坐席端视频理赔画面，视频混流结束的时间点，由坐席人员发起案件结束后，才会终止案件，此动作需由坐席人员操作，而不是用户端，因为只有坐席人员才能决定车险理赔是否完成。车险理赔平台在收到会话结束的通知时，会通知小程序端可以中断视频，并同时请求视频混流结束，而收到小程序端通知视频中断以及用户离线后，此时视频混流开始至视频混流结束的视频理赔记录可以保存至服务器及本地存储器，于未来质检以及监管要求时作为后续业务运用。

可选地，将目标媒体流推送至第一视频终端和第二视频终端之后，该方法还包括：在未接收到第二视频终端发送的所述第一视频终止请求的情况下，检测第一视频终端和第二视频终端的网络状态；在第一视频终端和第二视频终端中至少一个网络状态处于离线状态的情况下，暂停目标媒体流的推送，并在网络状态由离线状态转换为在线状态时继续进行视频混流。

本申请实施例中，还可以在进行视频理赔的过程中通过TCP/IP网络体系结构中应用层的服务命令来实时检测各方的网络状态，在有至少一方网络离线的情况下，暂停混流视频的推送，在重新恢复网络连接时再从当前时刻的时间戳继续视频混流及推送，以保证各方观看体验。

本申请还提供一种基于车险理赔的媒体混流方法，应用于第三方平台，如图9所示，可以包括以下步骤：

步骤S902，接收理赔平台发送的第一媒体流和第二媒体流，第一媒体流用于传输第一视频终端采集到的第一画面，第二媒体流用于传输第二视频终端采集到的第二画面；

步骤S904，在接收到在线查勘指令的情况下，将第一媒体流和第二媒体流混流，得到目标媒体流，并将目标媒体流发送至理赔平台。

本申请实施例中，第三方平台可以是音视频服务提供商，还可以是云端服务器及音视频处理引擎等。第三方平台可以将理赔平台发送的第一媒体流和第二媒体流进行混流，混流开始的时间点由在线查勘指令决定，该指令为理赔平台根据实时视频的多方对象达成共识后确定的业务时间点。

可选地，如图10所示，将第一媒体流和第二媒体流混流，得到目标媒体流包括：

步骤S1002，确定背景图层，背景图层用于确定视频混流的画面范围；

步骤S1004，对第一媒体流进行解码，以在背景图层中确定与第一媒体流对应的第一叠加层，对第二媒体流进行解码，以在背景图层中确定与第二媒体流对应的第二叠加层，第一叠加层为第一画面的显示区域，第二叠加层为第二画面的显示区域；

步骤S1006，按照时间戳对齐第一画面和第二画面的画面帧，得到目标视频流，目标媒体流包括所述目标视频流。

本申请实施例中，可以指定一块画面区域，即背景图层，在此区域内，按画面的位置布局，即上述第一画面显示的第一叠加层和第二画面显示的第二叠加层，将区域中的每个视频画面的像素混合计算成一个像素，从而通过解码、混流、编码的方式完成视频混流。像素混合可以采用Porter-Duff模型，在此不再赘述。

本申请实施例中，第一画面和第二画面的画面帧均是还未播放的某个画面帧。按照时间戳对齐第一画面和第二画面的画面帧可以按照以下步骤：

步骤1，确定第一画面的画面帧为第一对齐帧；

步骤2，获取第一对齐帧的获取时间，并在第二画面的多个画面帧中确定具有相同的获取时间的第二对齐帧；

步骤3，将第一对齐帧与第二对齐帧的显示时间设为同时显示。

可选地，将第一媒体流和第二媒体流混流，得到目标媒体流还可以包括：

对第一音频流和第二音频流进行叠加计算，得到目标音频流。将目标视频流和目标音频流进行编码，得到目标媒体流，并将目标媒体流发送至理赔平台。

本申请实施例中，第一音频流用于传输第一视频终端采集到的第一音频数据，第二音频流用于传输第二视频终端采集到的第二音频数据，第一媒体流包括第一音频流，第二媒体流包括第二音频流。

在进行音频混流时，可以提取第一音频流中的第一波形和第二音频流中的第二波形，按照线性叠加后求平均、自适应加权求平均及多通道混音中至少一中方式将第一波形和第二波形进行叠加计算，混合成一路音频波形，即目标音频流。

进一步地，将目标视频流的显示时间对齐目标音频流的播放时间，进行音视频混流，得到目标媒体流。

采用本申请技术方案，可以解决车险理赔场景中用户端以及服务端双方画面不一致的技术问题，为多方视频理赔提供了稳定的技术方案，并通过混流多路流进行画面对齐和音画同步，同时通过缓冲对抗网络抖动。

下面结合图11所示，对本申请技术方案的整体流程进行说明。

步骤1，理赔用户通过小程序等工具向理赔平台发送第一视频发起请求；

步骤2，理赔平台收到第一视频发起请求后建立第一会话，此时理赔用户已处在第一会话中；

步骤3，理赔平台将第一会话的第一标识发送给保险公司坐席；

步骤4，保险公司坐席根据第一标识加入第一会话；

步骤5，理赔平台在第一会话中建立第一视频房间；

步骤6，理赔平台将第一视频房间的第二标识发送给理赔用户和保险公司坐席；

步骤7，理赔用户和保险公司坐席根据第二标识加入第一视频房间，并向理赔平台发送各自的视频流；

步骤8，理赔平台将收到的所有视频流发送给第三方平台，并检测理赔用户和保险公司坐席的网络时延；

步骤9，在二者的网络时延均小于目标阈值的情况下理赔平台向理赔用户和保险公司坐席发送在线查勘请求；

步骤10，理赔用户和保险公司坐席在确认可以进行在线查勘的情况下，向理赔平台发送确认信息；

步骤11，理赔平台收到二者的确认信息，生成在线查勘指令，并向第三方平台发送该指令；

步骤12，第三方平台在接收到在线查勘指令的情况下，开始进行音视频混流，并向理赔平台发送混流得到的目标媒体流；

步骤13，理赔平台向理赔用户和保险公司坐席推流该目标媒体流，开始进行线上查勘；

步骤14，保险公司坐席在向理赔平台发出结束视频理赔的信息后，理赔平台通知第三方平台终止混流，并通知理赔用户和保险公司坐席本次在线查勘结束。

根据本申请实施例的又一方面，如图12所示，提供了一种基于车险理赔的媒体混流装置，应用于理赔平台，包括：第一接收模块1201，用于接收第一视频终端发送的第一媒体流和第二视频终端发送的第二媒体流，第一视频终端用于请求资源补偿，第二视频终端用于在执行资源补偿时使用，第一媒体流用于传输第一视频终端采集到的第一画面，第二媒体流用于传输第二视频终端采集到的第二画面；第三方平台调用模块1203，用于向第三方平台发送第一媒体流和第二媒体流，并调用第三方平台将第一媒体流和第二媒体流混流，以得到反馈的目标媒体流；混流推送模块1205，用于将目标媒体流推送至第一视频终端和第二视频终端，以在第一视频终端和第二视频终端上同步展示第一画面和第二画面。

需要说明的是，该实施例中的第一接收模块1201可以用于执行本申请实施例中的步骤S202，该实施例中的第三方平台调用模块1203可以用于执行本申请实施例中的步骤S204，该实施例中的混流推送模块1205可以用于执行本申请实施例中的步骤S206。

此处需要说明的是，上述模块与对应的步骤所实现的示例和应用场景相同，但不限于上述实施例所公开的内容。需要说明的是，上述模块作为装置的一部分可以运行在如图1所示的硬件环境中，可以通过软件实现，也可以通过硬件实现。

可选地，该基于车险理赔的媒体混流装置，还包括视频会话创建模块，用于：在接收到第一视频终端发送的第一视频发起请求的情况下，建立第一会话，第一会话携带有第一标识，第一视频发起请求携带有请求资源补偿的对象的信息；将第一标识发送至第二视频终端，以供第二视频终端通过第一标识连接第一会话，并在第二视频终端上展示请求资源补偿的对象的信息。

可选地，该视频会话创建模块，还用于：在第二视频终端通过第一标识连接至第一会话的情况下，创建第一视频房间，第一视频房间携带有第二标识；将第一标识和第二标识发送至第一视频终端和第二视频终端，以使第一视频终端通过第一标识和第二标识，在第一会话的第一视频房间中进行第一媒体流的传输，并使第二视频终端通过第一标识和第二标识，在第一会话的第一视频房间中进行第二媒体流的传输；在第二视频终端在第一时间阈值内未连接至第一会话的情况下，将第一会话推送至等待队列，以在第二视频终端连接至第一会话时重新唤起第一会话的进程，或者，在第二视频终端在第二时间阈值内仍未连接至第一会话的情况下，结束第一会话。

可选地，该基于车险理赔的媒体混流装置，还包括指令生成模块，用于：检测第一视频终端和第二视频终端的网络时延；在第一视频终端和第二视频终端的网络时延均小于目标阈值的情况下，向第一视频终端和第二视频终端发送在线查勘请求，以由请求资源补偿的对象和执行资源补偿的对象确认是否开始在线查勘；在接收到第一视频终端和第二视频终端响应在线查勘请求的确认信息的情况下，生成在线查勘指令。

可选地，该基于车险理赔的媒体混流装置，还包括终止混流模块，用于：在接收到第二视频终端发送的第一视频终止请求的情况下，将第一视频终止请求发送至第一视频终端，并终止将第一媒体流和第二媒体流混流为目标媒体流，由开始混流至终止混流的目标媒体流得到资源补偿视频记录；在第一视频终端和第二视频终端断开连接的情况下，结束第一会话，并保存资源补偿视频记录。

可选地，该基于车险理赔的媒体混流装置，还包括网络检测模块，用于：在未接收到第二视频终端发送的所述第一视频终止请求的情况下，检测第一视频终端和第二视频终端的网络状态；在第一视频终端和第二视频终端中至少一个网络状态处于离线状态的情况下，暂停目标媒体流的推送，并在网络状态由离线状态转换为在线状态时继续进行媒体混流。

根据本申请实施例的又一方面，如图13所示，提供了一种基于车险理赔的媒体混流装置，应用于第三方平台，包括：第二接收模块1301，用于接收理赔平台发送的第一媒体流和第二媒体流，第一媒体流用于传输第一视频终端采集到的第一画面，第二媒体流用于传输第二视频终端采集到的第二画面；混流模块1303，用于在接收到在线查勘指令的情况下，将第一媒体流和第二媒体流混流，得到目标媒体流，并将目标媒体流发送至理赔平台。

需要说明的是，该实施例中的第二接收模块1301可以用于执行本申请实施例中的步骤S902，该实施例中的混流模块1303可以用于执行本申请实施例中的步骤S904。

可选地，该混流模块，具体用于：确定背景图层，背景图层用于确定视频混流的画面范围；对第一媒体流进行解码，以在背景图层中确定与第一媒体流对应的第一叠加层，对第二媒体流进行解码，以在背景图层中确定与第二媒体流对应的第二叠加层，第一叠加层为第一画面的显示区域，第二叠加层为第二画面的显示区域；按照时间戳对齐第一画面和第二画面的画面帧，得到目标视频流，目标媒体流包括所述目标视频流。

可选地，该混流模块，还用于：对第一音频流和第二音频流进行叠加计算，得到目标音频流，第一音频流用于传输第一视频终端采集到的第一音频数据，第二音频流用于传输第二视频终端采集到的第二音频数据，第一媒体流包括第一音频流，第二媒体流包括第二音频流；将目标视频流和目标音频流进行编码，得到目标媒体流，并将目标媒体流发送至理赔平台。

根据本申请实施例的另一方面，本申请提供了一种电子设备，如图14所示，包括存储器1401、处理器1403、通信接口1405及通信总线1407，存储器1401中存储有可在处理器1403上运行的计算机程序，存储器1401、处理器1403通过通信接口1405和通信总线1407进行通信，处理器1403执行计算机程序时实现上述方法。

上述电子设备中的存储器、处理器通过通信总线和通信接口进行通信。所述通信总线可以是外设部件互连标准(Peripheral Component Interconnect，简称PCI)总线或扩展工业标准结构(Extended Industry Standard Architecture，简称EISA)总线等。该通信总线可以分为地址总线、数据总线、控制总线等。

存储器可以包括随机存取存储器(Random Access Memory，简称RAM)，也可以包括非易失性存储器(non-volatile memory)，例如至少一个磁盘存储器。可选的，存储器还可以是至少一个位于远离前述处理器的存储装置。

上述的处理器可以是通用处理器，包括中央处理器(Central Processing Unit，简称CPU)、网络处理器(Network Processor，简称NP)等；还可以是数字信号处理器(Digital Signal Processing，简称DSP)、专用集成电路(Application SpecificIntegrated Circuit，简称ASIC)、现场可编程门阵列(Field-Programmable Gate Array，简称FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。

根据本申请实施例的又一方面还提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行上述任一实施例的步骤。

可选地，在本申请实施例中，计算机可读介质被设置为存储用于所述处理器执行以下步骤的程序代码：

接收第一视频终端发送的第一媒体流和第二视频终端发送的第二媒体流，第一视频终端用于请求资源补偿，第二视频终端用于在执行资源补偿时使用，第一媒体流用于传输第一视频终端采集到的第一画面，第二媒体流用于传输第二视频终端采集到的第二画面；

将第一媒体流和第二媒体流混流，得到目标媒体流；

将目标媒体流推送至第一视频终端和第二视频终端，以在第一视频终端和第二视频终端上同步展示第一画面和第二画面。

可选地，本实施例中的具体示例可以参考上述实施例中所描述的示例，本实施例在此不再赘述。

可选地，在本申请实施例中，计算机可读介质还被设置为存储用于所述处理器执行以下步骤的程序代码：

接收理赔平台发送的第一媒体流和第二媒体流，第一媒体流用于传输第一视频终端采集到的第一画面，第二媒体流用于传输第二视频终端采集到的第二画面；

在接收到在线查勘指令的情况下，将第一媒体流和第二媒体流混流，得到目标媒体流，并将目标媒体流发送至理赔平台。

可选地，本实施例中的具体示例可以参考上述实施例中所描述的示例，本实施例在此不再赘述。

本申请实施例在具体实现时，可以参阅上述各个实施例，具有相应的技术效果。

可以理解的是，本文描述的这些实施例可以用硬件、软件、固件、中间件、微码或其组合来实现。对于硬件实现，处理单元可以实现在一个或多个专用集成电路(ApplicationSpecific Integrated Circuits，ASIC)、数字信号处理器(Digital Signal Processing，DSP)、数字信号处理设备(DSP Device，DSPD)、可编程逻辑设备(Programmable LogicDevice，PLD)、现场可编程门阵列(Field-Programmable Gate Array，FPGA)、通用处理器、控制器、微控制器、微处理器、用于执行本申请所述功能的其它电子单元或其组合中。

对于软件实现，可通过执行本文所述功能的单元来实现本文所述的技术。软件代码可存储在存储器中并通过处理器执行。存储器可以在处理器中或在处理器外部实现。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在本申请所提供的实施例中，应该理解到，所揭露的装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述模块的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个模块或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。

所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请实施例的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。需要说明的是，在本文中，诸如“第一”和“第二”等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

以上所述仅是本申请的具体实施方式，使本领域技术人员能够理解或实现本申请。对这些实施例的多种修改对本领域的技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本申请的精神或范围的情况下，在其它实施例中实现。因此，本申请将不会被限制于本文所示的这些实施例，而是要符合与本文所申请的原理和新颖特点相一致的最宽的范围。