CN114390324A - 视频处理方法、系统以及云转播方法 - Google Patents

Abstract

本申请实施例提供视频处理方法、系统以及云转播方法。该方法包括：获取由不同源端设备提供的携带有与相同视频场景相关的视频内容的第一视频信息和第二视频信息，以为客户端获取所述视频内容的视频帧提供服务；若监测到所述客户端从所述第一视频信息中获取第一视频帧失败，则在所述第二视频信息中查找用于替代所述第一视频帧的目标视频帧；将所述目标视频帧发送至所述客户端。在用户无感知的情况下，完成视频切流，能够有效解决因为源端设备故障、传输链路故障等问题对视频传输效果所造成的不利影响，提高视频直播、转播的稳定性。

Description

视频处理方法、系统以及云转播方法

技术领域

本申请涉及计算机技术领域，尤其涉及视频处理方法、系统以及云转播方法。

背景技术

随着云技术的快速发展，云技术的应用越来越广泛。在视频应用场景中，云技术也充分发挥其高效、便捷的优势。

在云视频技术可以应用于视频直播、视频转播等方案中，涉及到源端视频采集设备、云服务端设备和客户端设备等多端参与。若源端视频采集设备、网络链路中某个环节出现故障，将导致视频无法正常播放，对用户的观看体验造成不好的影响。在一些重要直播、转播视频（比如，大型比赛）场景中，对视频稳定效果要求比较高，然而，由于不同用户所选用的源端视频采集设备的型号和稳定性存在差异，不同用户所选择的用于传输视频的网络链路稳定性存在差异等因素，视频直播、视频转播的稳定性效果更难以保障。因此，需要一种基于云技术确保视频能够被稳定处理的方案。

发明内容

为解决或改善现有技术中存在的问题，本申请各实施例提供了视频处理方法、系统以及云转播方法。

第一方面，在本申请的一个实施例中，提供了一种视频处理方法。该方法包括：

获取由不同源端设备提供的携带有与相同视频场景相关的视频内容的第一视频信息和第二视频信息，以为客户端获取所述视频内容的视频帧提供服务；

若监测到所述客户端从所述第一视频信息中获取第一视频帧失败，则在所述第二视频信息中查找用于替代所述第一视频帧的目标视频帧；

将所述目标视频帧发送至所述客户端。

第二方面，在本申请的一个实施例中，提供了另一种视频处理方法。该方法包括：

对采集到的视频内容进行编码得到第一视频信息；

将所述第一视频信息发送至云服务端；其中，所述云服务端还存储有由另一源端设备采集到的与所述第一视频信息具有与相同视频场景相关的视频内容的第二视频信息，当客户端从云服务端的所述第一视频信息中获取第一视频帧失败时，从所述第二视频信息中查找用于替代所述第一视频帧的目标视频帧。

第三方面，在本申请的一个实施例中，提供了一种视频处理系统，包括：至少一个源端设备、云服务端、客户端；

所述云服务端，用于获取由不同源端设备提供的携带有与相同视频场景相关的视频内容的第一视频信息和第二视频信息；若基于拉流请求从所述第一视频信息中拉取第一视频帧失败，则根据所述拉流请求对应的标准时间戳，从所述第二视频信息中查找用于替代所述第一视频帧的目标视频帧；将所述目标视频帧推送至客户端；

所述至少一个源端设备，用于对采集到的视频内容进行编码得到第一视频信息；将所述第一视频信息发送至云服务端；其中，所述云服务端还存储有由另一源端设备采集到的与所述第一视频信息具有与相同视频场景相关的视频内容的第二视频信息，当客户端从云服务端的所述第一视频信息中获取第一视频帧失败时，从所述第二视频信息中查找用于替代所述第一视频帧的目标视频帧。

第四方面，在本申请的一个实施例中，提供了一种云转播方法，所述方法包括：

获取由不同视频设备提供的携带有与相同视频场景相关的视频内容的第一视频信息和第二视频信息；

将所述第一视频信息转播给客户端；

若监测到所述客户端从被转播的所述第一视频信息中获取第一视频帧失败，则在所述第二视频信息中查找用于替代所述第一视频帧的目标视频帧；

将所述目标视频帧转播至所述客户端。

本申请实施例提供的技术方案，在利用云计算实现视频直播、视频转播的应用当中，为了确保视频传输的可靠性和稳定性，可以同时使用多个源端设备进行与相同视频场景相关的视频内容的采集。为了使得不同源端设备所采集得到的第一视频信息和第二视频信息具有很好的一致性，需要为这两个视频信息中添加相同的标准时间戳。当客户端发送拉流请求后，若从第一视频信息中拉取第一视频帧失败，则根据标准时间戳进行切流，也就是从第二视频信息中查找用于替代第一视频帧的目标视频帧。在用户无感知的情况下，完成视频切流，能够有效解决因为源端设备故障、传输链路故障等问题对视频传输效果所造成的不利影响，提高视频直播、转播的稳定性。

附图说明

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

图1为本申请实施例提供的视频处理方法的流程意图；

图2为本申请实施例提供的视频处理应用场景示意图；

图3为本申请实施例提供的由云服务端统一时间基准的流程示意图；

图4为本申请实施例提供的确定第二标准时间戳方法的流程示意图；

图5为本申请实施例提供的另一种视频处理方法的流程示意图；

图6为本申请实施例举例说明的视频流互备的交互示意图；

图7为本申请实施例说明的视频处理系统的结构示意图；

图8为本申请实施例提供的一种云转播方法的流程示意图；

图9为本申请实施例提供的一种视频处理装置的结构示意图；

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

图11为本申请实施例提供的另一种视频处理装置的结构示意图；

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

图13为本申请实施例提供的一种云转播装置的结构示意图；

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

具体实施方式

为了使本技术领域的人员更好地理解本申请方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述。

在本申请的说明书、权利要求书及上述附图中描述的一些流程中，包含了按照特定顺序出现的多个操作，这些操作可以不按照其在本文中出现的顺序来执行或并行执行。操作的序号如101、102等，仅仅是用于区分各个不同的操作，序号本身不代表任何的执行顺序。另外，这些流程可以包括更多或更少的操作，并且这些操作可以按顺序执行或并行执行。需要说明的是，本文中的“第一”、“第二”等描述，是用于区分不同的消息、设备、模块等，不代表先后顺序，也不限定“第一”和“第二”是不同的类型。此外，下文描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

随着云视频技术的快速发展，视频直播、视频转播的稳定性直接影响用户的观看体验。在现有云视频技术中，通常是通过某个源端设备进行图像采集，通过网络链路进行视频传输，发送给各个客户端。由于云视频技术实现过程中，需要多个源端设备、多个网络链路配合工作，若其中任一环节出现故障，都会导致视频发生卡顿或掉线。此外，在一些大型视频直播、转播活动中，可能会有多个用户（不同电视台或自媒体用户）参与到活动当中。这些用户所采用的源端设备格式各样，设备稳定性也参差不齐，可能会出现不可控的视频卡顿或掉线情况出现。若源端设备出现故障导致掉线，将会直接导致视频中断，等待源端设备故障修复后，才能继续为观众提供视频直播、转播服务。因此，需要一种能够提升数据库中数据访问的安全防护效果问题的技术方案。在本申请技术方案中，具体工作过程，将在下述实施例中说明。

如图1为本申请实施例提供的视频处理方法的流程意图。该方法的执行主体可以是云服务器。该视频处理方法具体包括如下步骤：

步骤101：获取由不同源端设备提供的携带有与相同视频场景相关的视频内容的第一视频信息和第二视频信息。在获取到第一视频信息和第二视频信息之后，可以利用第一视频信息和/或第二视频信息为客户端获取所述视频内容的视频帧提供服务，比如，视频直播服务或者视频转播服务。

步骤102：若监测到所述客户端从所述第一视频信息中获取第一视频帧失败，则在所述第二视频信息中查找用于替代所述第一视频帧的目标视频帧。

步骤103：将所述目标视频帧发送至所述客户端。

需要说明的是，这里所说的源端设备可以是摄像机、手机等能够进行视频采集的终端设备。相同视频场景相关的视频内容可以理解为多个源端设备针对同一内容进行视频采集所得到的视频内容，可能具有完全相同的视角的视频内容，也可能因为多个源端设备摆放在同一场地中不同位置所采集到的具有不同视角的视频内容，这些源端设备都在针对相同视频场景进行拍摄（视频图像采集）。如图2为本申请实施例提供的视频处理应用场景示意图。从图2中可以看到，摄像机1和摄像机2位于相同的机位，采集具有相同视角的视频内容，摄像机3则位于不同于摄像机1和摄像机2的机位，用于采集不同视角的视频内容，但是，都是针对相同的田径比赛进行视频直播或视频转播的，这三个摄像机所拍摄的内容可以称为相同视频场景相关的视频内容。因此，图2中所示的摄像机1、摄像机2和摄像机3中选择其中一个作为主视频信息（相当于前文所说的第一视频信息），其他两个均可以作为备视频信息（相当于前文所说的第二视频信息）。在实际应用中，若多个摄像机所在的视角不同，可以进行主备视频切换。比如，虽然摄像机1为主摄像机，用于提供主视频信息，但是在播放的时候，根据播放需要进行不同视角的切换，则可以将摄像机3作为主摄像机，并将对应的视频信息作为主视频信息。也就是说，多个源端设备（摄像机）相互之间互为主备关系，任何时候当前正在支持直播或转播的主摄像机出现故障，都会从多个备摄像机选择一个摄像机及其对应的视频信息作为替代。

这里所说的不同的多个源端设备可以是同一用户相同型号的多个设备，这些源端设备方便统一管理设置。可以根据需要对源端设备进行统一设置，包括：统一时间基准、统一编码参数。其中，统一时间基准是指多个源端设备的编码器之间会以某种方式进行时钟同步，例如统一采用协调世界时（Coordinated Universal Time，UTC），并且对各个源端设备的编码器进行定时校准。或者采用网络时间协议（Network Time Protocol，NTP），校准各个源端设备的编码器的时间基准(time_base)。统一编码参数是指统一设置编码器的编码参数，特别是和时间戳相关的参数，例如相同的图像组（Group of picture，GOP），相同的音频采样率、视频帧率，确保每一帧的时间戳间隔保持一致(delta_pts)。统一源端设备中的编码器类型，常用类型有x264、x265、vpx、nvenc、ngcodec等。通过上述调整方式，可以在具有相同视频内容的不同的视频信息中，找到某一时间戳对应的相同视频帧。

如果多个源端设备分别属于不同用户或源端设备的品牌型号不一致，难以实现统一管理设置，则可以由云服务端实现对时间基准和编码参数的统一工作。具体将在下述图3对应实施例中进行举例说明，这里就不再重复赘述。

在本申请方案中，多个源端设备用于提供同一视频内容。这里假设用于提供第一视频信息的源端设备为主视频设备，用于提供第二视频信息的源端设备为备视频设备。在所有源端设备和网络链路都能够正常工作的情况下，通过主视频设备提供的第一视频信息为客户端提供视频直播或转播服务。当主视频设备或者主视频设备连接的各个网络链路都发生故障，则会切换到备视频设备，也就是通过第二视频信息为客户端继续提供视频服务。

若没有能够通过源端设备实现对时间基准、编码参数等的统一设置，也可以在云服务端实现统一设置。如图3为本申请实施例提供的由云服务端统一时间基准的流程示意图。从图3中可以看到，包括如下步骤：

301：若所述第一视频信息中的第一时间戳与所述第二视频信息中的第二时间戳分别具有不同时间标准，则对所述第一时间戳和所述第二时间戳进行标准化处理，得到第一标准时间戳和第二标准时间戳。

302：将所述第一视频信息中的第一时间戳更新为所述第一标准时间戳，以及将所述第二视频信息中的第二时间戳更新为所述第二标准时间戳。

在接收到第一视频信息和第二视频信息后，若检查发现第一视频信息中的第一时间戳与第二视频信息中的第二时间戳分别具有不同的时间标准（比如，具有不同的时间基或者不同的时间戳间隔）。将视频中的时间基准设置为相同的时间基（time_base），以及对各个视频信息中的每一帧的时间戳间隔（delta_pts）也进行统一。根据time_base和delta_pts，生成帧级别标准时间戳frame_pts（本申请实施例中标准时间戳为显示时间戳，在有的情况下也可以将解码时间戳作为标准时间戳），frame_pts = time_base + delta_pts 。云服务端在对视频数据进行压缩编码的时候，对各个视频信息中的时间戳进行更新，比如，若有两个视频信息，则将所述第一视频信息中的第一时间戳更新为所述第一标准时间戳，以及将所述第二视频信息中的第二时间戳更新为所述第二标准时间戳。

云服务端不仅要对时间标准进行统一，还要对编码参数进行统一。可以先对接收到的各个视频信息进行解码，然后按照统一的编码参数（如前文所述比如，采用相同的音频采样率、视频帧率以及时间戳间隔）进行编码。

通过上述云服务端进行时间标准和编码参数的统一化操作，能够实现针对各种不同源端设备所采集到的视频信息的统一管理，满足更多不同类型用户的直播转播稳定性需求。

比如，媒体用户1，同时派出3组摄像人员对一场展会进行直播，3组摄像人员携带的3台用于进行图像采集的摄像机为3种不同型号的摄像机，从不同的位置对展会情况进行全方位报道。媒体用户2，同时派出4组摄像人员也对该展会进行直播，并且携带的4台用于进行图像采集的摄像机为相同型号的摄像机。各个摄像机对采集到的视频信息进行编码后，发送给云服务端。

云服务端在接收到媒体用户1提供的3组视频信息后，会对这3组视频信息进行解码，然后对这3组视频的时间标准和编码参数。云服务端将完成统一标准的3组视频信息进行关联，若当前正在进行直播的摄像机出现故障，则云服务端会自动切流到另外一台摄像机对应的视频信息对应的视频帧。在故障未解除的情况下，用户无法手动切回到故障摄像机对应的视频信息。

云服务端在接收到媒体用户2提供的4组视频信息后，由于各个视频信息已经在编码器侧进行了统一化处理，因此，需要对这4组视频信息进行关联，若当前正在进行直播的摄像机出现故障，则云服务端会自动切流到另外一台摄像机对应的视频信息对应的视频帧。在故障未解除的情况下，用户无法手动切回到故障摄像机对应的视频信息。

在本申请的一个或者多个实施例中，监测到所述客户端从所述第一视频信息中获取第一视频帧失败，包括：接收客户端的拉流请求。根据所述拉流请求的顺序，从所述第一视频信息的存储空间中拉取第一视频帧。若监测到所述存储空间中未存储所述第一视频帧，则确定拉取失败。

在实际应用中，可以由云服务端向客户端主动进行推流的方式进行视频传输，也可以由客户端发送拉流请求，进而由云服务端向客户端提供视频服务。云服务端在为客户端提供视频服务的时候，先将从源端设备接收到达视频信息存储到云服务端的存储空间中，再根据推流或者拉流需求将存储空间中已经存储的视频信息发送给对应的客户端。具体来说，源端设备采集视频，并根据既定的编码参数和时间标准进行压缩编码，将编码后的视频信息通过网络链路发送给云服务端进行缓存。然后，云服务端将存储空间中的视频信息发送给客户端，若各个源端设备和对应的网络链路都正常稳定工作，则存储空间中的视频信息则会处于动态平衡状态，也就是每发送一视频帧（或图像组）的同时都会接收到新的视频帧（或图像组）做补充。若源端设备或者网络链路发生故障，则会导致存储空间中的视频信息不断被发送出去，而没有新的视频帧（或图像组）补充到存储空间，则会导致拉取第一视频帧的时候拉取失败。

判断从存储空间中拉取第一视频帧是否成功，可以检测存储空间是否为空，也可也设定一定的阈值（比如，存储空间中剩余视频帧数量小于百分之五十）则认为拉取失败。

从图2中可以看到，源端采集到图像信息之后，需要通过网络链路发送给云服务端存储，若源端设备或网络链路出现故障，都会导致拉取失败。在本方案中，不需要分析问题是出现在源端设备还是网络链路，都可以采用切流的方式解决。能够有效提高应急解决效率。

此外，有一些故障也可以通过其他方式确定。比如，有的源端设备发生故障，源端设备会主动发送报警信息给云服务端，则云服务端在得知源端设备故障后，会采取切流措施。

在本申请的一个或者多个实施例中，所述在所述第二视频信息中查找用于替代所述第一视频帧的目标视频帧，包括：确定获取第一视频帧失败时对应的第一标准时间戳。确定所述第二视频信息中各个视频帧对应的所述第二标准时间戳。根据所述第一标准时间戳和所述第二标准时间戳的匹配结果，确定所述目标视频帧。

通过上述实施例，对第一视频信息和第二视频信息的时间基准进行了调整，得到统一的时间标准。实现对不同视频信息中各视频帧的统一标准管理，根据标准时间戳能够准确找到各个视频信息中对应的视频帧，从而使得进行切流的时候能够准确找到对应的视频帧。

在实际应用中，对第一标准时间戳和第二标准时间戳进行匹配的时候，可以是查找完全相同的标准时间戳，也可以是查找相邻的标准时间戳。由于这里所说的标准时间戳是帧级别的时间戳，即便寻找到相邻的标准时间戳对应的视频帧用于进行切流，也可以使得用户无法察觉到明显的视频内容的跳跃。

例如，第一视频帧对应的第一标准时间戳为frame_pts-1，接下来将从第二视频信息中查找frame_pts-1对应的视频帧，若未能查找到完全相同标准时间戳对应的视频帧，则查找与frame_pts-1相邻的时间戳frame_pts-2对应的视频帧。根据查找结果快速完成切流，从第一视频信息切换到第二视频信息，将第二视频信息对应的源端设备作为主视频设备，通过源端设备连接的各网络链路将第二视频信息发送给各个客户端，满足用户通过客户端观看视频内容的需求。

在本申请的一个或者多个实施例中，所述确定获取第一视频帧失败时对应的第一标准时间戳，包括：获取拉流请求携带的时间戳，将所述时间戳作为所述第一标准时间戳；或者，获取本地存储的已推流视频帧的时间戳，确定与所述已推流视频帧的时间戳相邻的第一标准时间戳。

在实际应用中，第一视频帧对应的第一标准时间戳的确定方式有多种。比如，若客户端主动向云服务端发送拉流请求，则云服务端对接收到的拉流请求进行解析，从而获得该请求中所携带的时间戳，将该时间戳作为拉取第一视频帧的第一标准时间戳。

当然，云服务端还可以对已推流视频相关信息进行记录，记录若第一视频帧推流失败，则可以根据已推流视频相关信息中查找对应的时间戳，由于该时间戳对应的视频帧为已推流视频帧，则该时间戳之后的视频帧为待发送给客户端的第一视频帧，对应的第一标准时间戳为与已推流视频对应时间戳相邻的标准时间戳。

在本申请的一个或者多个实施例中，所述确定所述第二视频信息中各个视频帧对应的所述第二标准时间戳，包括：确定所述第二视频信息的时间基和各个视频帧对应的时间戳间隔；基于所述时间基和所述时间戳间隔，确定所述各个视频帧对应的所述第二标准时间戳。

在接收到第二视频信息之后，将对第二视频信息进行解码处理，得到对应的时间基（time_base），以及每一帧的时间戳间隔（delta_pts）。根据时间基time_base和时间戳间隔delta_pts，生成帧级别的第二标准时间戳frame_pts，也就是frame_pts = time_base +delta_pts。

例如，第二视频信息被推流到云服务端之后，云服务端会解析源端设备填充在rtmp metadata（流传输协议元数据）里的time_base时间基准，并与每一帧的时间戳delta_pts相加，得到帧同步显示时间戳frame_ pts。

在本申请的一个或者多个实施例中，所述根据所述第一标准时间戳和所述第二标准时间戳的匹配结果，确定所述目标视频帧，包括：根据所述第一标准时间戳对应视频帧的帧类型，确定与所述第一标准时间戳相同或相邻的所述第二标准时间戳。确定所述第二标准时间戳对应的视频帧为所述目标视频帧。

这里所说的视频帧的帧类型包括：I帧，B帧，P帧。其中，

I帧是关键帧，它采用帧内压缩技术。B帧是前后参考帧，它属由帧间压缩技术。也就是说在压缩成 B帧前，它会参考它前面的非压缩视频帧，和后面的非压缩的视频帧，记录下前后两帧都不存放的“残差值”，这样可以达到更好的压缩率。P帧是向前参考帧，也就是它参考的是前一个关键帧的数据。P帧也属于帧间压缩技术，相对于 B帧来说，P帧的压缩率要比B帧低。

如前文所述，由于不同帧类型的编码、解码规则不同。在进行解码时，所选择的用于切流的某一视频帧的方式也不同，因为有的视频帧的解码需要依赖于前面视频帧，或者依赖于前后视频帧，而仅仅获取某一视频帧是无法实现解码的。因此，在确定第一标准时间戳对应视频帧的帧类型之后，进一步可以知道接下来需要获取的视频帧是与第一标准时间戳相同还是相邻的第二标准时间戳。能够精准的获取切流所需的视频帧，以便实现用户无感知情况下的视频流的切换。

下面将结合具体实施例针对基于帧类型确定第二标准时间戳相关方案进行说明。如图4为本申请实施例提供的确定第二标准时间戳方法的流程示意图。如图4所示，具体包括如下步骤：401：获取所述第二视频信息。402：对所述第二视频信息进行解码处理，得到各个视频帧分别对应的第二标准时间戳。403：根据所述第一标准时间戳对应视频帧的帧类型，确定与所述第一标准时间戳相同或相邻的所述第二标准时间戳。

在实际应用中，云服务端可以对第一视频信息和第二视频信息同时进行解码处理。也可以是在发现拉取第一视频帧失败之后，才开始对第二视频信息进行解码处理。通过对第二视频信息进行解码处理之后，可以得到流传输协议中携带的时间戳以及各个视频帧，进而，可以确定各个视频帧分别对应的第二标准时间戳。

当客户端获取第一视频帧失败之后，可以知道第一视频帧对应的第一标准时间戳以及对应的帧类型。

这里，假设一个图像组（GOP）包括：I帧、B帧、B帧、P帧。

若第一视频帧（也就是第一标准时间戳对应的）帧类型为P帧，与第一标准时间戳相邻时间戳对应的帧类型为I帧，是能够直接解码，不需要进行前后帧参考解码，因此，第二标准时间戳可以是与第一标准时间戳相邻的标准时间戳，以及将第二标准时间戳对应的视频帧作为目标视频帧。

若第一视频帧（也就是第一标准时间戳对应的）帧类型为I帧，与第一标准时间戳相邻时间戳对应的帧类型为B帧，B帧是不能直接解码得到的，需要进行前后帧参考解码，因此，第二标准时间戳可以是与第一标准时间戳相同的标准时间戳，以及将第二标准时间戳对应的视频帧作为目标视频帧。

若第一视频帧（也就是第一标准时间戳对应的）帧类型为B帧，与第一标准时间戳相邻时间戳对应的帧类型为B帧，B帧是不能直接解码得到的，需要进行前后帧参考解码，因此，第二标准时间戳可以是与第一标准时间戳相临的标准时间戳（比如，第一标准时间戳之前一个I帧对应的标准时间戳），以及将第二标准时间戳对应的视频帧作为目标视频帧（也就是B帧之前的I帧）。

这种方式切流准确度高，云服务端对视频信息进行解码后完全按照pts 进行逐帧查找，误差为视频帧级别误差。

在本申请的一个或者多个实施例中，所述根据所述第一标准时间戳和所述第二标准时间戳的匹配结果，确定所述目标视频帧，包括：获取所述第二视频信息各个图像组分别对应的起始时间戳。从所述第二视频信息中确定与所述第一标准时间戳相邻的所述起始时间戳对应的图像组；所述图像组中包含有所述目标视频帧。

这里所说的图像组（Group of picture，GOP），指两个I帧之间的距离。比如，一个GOP中所包含的帧可以是I帧、B帧、B帧、P帧。

在实际应用中，B帧的数量是可变的。Reference（参考周期）指两个P帧之间的距离。一个I帧所占用的字节数大于一个P帧，一个P帧所占用的字节数大于一个B帧。所以在码率不变的前提下，GOP值越大，P、B帧的数量会越多，平均每个I、P、B帧所占用的字节数就越多，也就更容易获取较好的图像质量；Reference越大，B帧的数量越多，同理也更容易获得较好的图像质量。

也就是，在一个GOP中，以I帧为开始帧。在一些不需要精准到帧级别的视频切流的场景中，可以不需要解码得到图像组中各个视频帧，而是以图像组为基本单位进行切流。

例如，当确定第一标准时间戳为GOP1中的任一一帧的时间戳，那么可以进一步确定该第一标准时间戳所在GOP1中的起始时间戳（也就是I帧时间戳），进而基于GOP1的起始时间戳查找与之相邻图像组的起始时间戳。

需要说明的是，这里所说的时间戳也是经过标准化处理后得到的标准时间戳。通过上述方案，不需要云服务端再进行繁琐的解码、编码操作，直接根据pts进行同步，同时利用二分查找，定位最近的GOP I帧位置进行切流，就能够快速确定用于切流的图像组，误差在0或1个 GOP。

在本申请的一个或者多个实施例中，还包括：若用于提供所述第一视频信息的源端设备故障和/或链路故障被解除，则将所述第一视频信息存储作为备视频信息。

如前文所述，第一视频信息和第二视频信息为主备关系，也就是，可以将第一视频信息作为主视频信息，而将第二视频信息作为在第一视频信息不可用的情况下进行替补作用的备视频信息。

因此，若采用前文所述方案，完成第一视频信息与第二视频信息的切换工作后，会对发生故障的第一视频信息对应的源端设备和对应的网络链路进行故障排查维修，在维修完成后，可以将第一视频信息作为被视频信息，而第二视频信息作为主视频信息。当第二视频信息出现故障的时候，可以进行再次切换。切换的方式与前文所述技术方案相似，这里就不再重复赘述。

基于同样的思路，本申请实施例还提供另一种视频处理方法。如图5为本申请实施例提供的另一种视频处理方法的流程示意图，该方法可以应用于视频采集的源端设备，与此同时，还有另外一个或多个源端设备参与视频采集，进而将采集到的视频信息分别通过对应的网络链路发送给云服务端，以便云服务端为各个客户端提供视频服务。所述方法具体包括如下步骤：

501：对采集到的视频内容进行编码得到第一视频信息。

502：将所述第一视频信息发送至云服务端；其中，所述云服务端还存储有由另一源端设备采集到的与所述第一视频信息具有与相同视频场景相关的视频内容的第二视频信息，当客户端从云服务端的所述第一视频信息中获取第一视频帧失败时，从所述第二视频信息中查找用于替代所述第一视频帧的目标视频帧。

在本申请实施例中，源端设备为用于采集视频的设备。可以在同一个视频采集场景中同时布置多台源端设备，这些多个源端设备采集同一视频内容（该视频内容可以具有完全相同视角，也可以具有不同视角）。选择其中一个源端设备作为主视频设备，用于通过网络链路为用户提供视频服务。当该主视频设备出现故障之后，从主视频设备切换到其他源端设备。在进行切换的时候，根据标准时间戳找到对应目标视频帧，实现视频帧级别的切换，具体技术方案可参见图1至图4对应的各个实施例。这里就不再重复赘述。

为了便于理解，将结合具体实施例说明多视频流互备方案。如图6为本申请实施例举例说明的视频流互备的交互示意图。由主视频设备master pusher发送主视频信息（视频流）master stream给云服务端的缓存空间master cache进行存储，备视频设备slavepusher发送备视频信息（视频流）slave stream给云服务端的缓存空间master cache进行存储。具体互备容灾的流程如下：

a. 主源端设备提供的主视频流到达云服务端后，云服务端会解析源端填充在rtmp metadata（流传输协议）里的时间基time_base，并与每一帧的时间戳间隔pts相加，得到帧同步解码时间frame_pts。

b. 拉流请求触发switch模块，优先选择master cache中的数据，并且记录下已发送数据的frame_pts。

c. 当master pusher对应的源端视频采集设备、编码器或链路发生故障，切流模块switch会根据已发送视频帧的标准时间戳frame_pts到缓存空间slave cache中进行查找对应的视频帧，并且结合帧类型找出最合适的邻近视频帧作为目标视频帧。在这一步中，switch会对视频设备进行角色切换，将备视频设备slave变成主视频设备master，并把找到的帧数据发送给CDN进行分发。如果原来的master pusher恢复正常推流，则把收到的新数据置为slave状态，以便在其他设备故障后作为备视频切流。

为了便于理解，下面将举例说明。如图7为本申请实施例说明的视频处理系统的结构示意图。从图7中可以看到，述系统包括：至少一个源端设备、云服务端、客户端；

所述云服务端，用于获取由不同源端设备提供的携带有相同视频内容的第一视频信息和第二视频信息；若基于拉流请求从所述第一视频信息中拉取第一视频帧失败，则根据所述拉流请求对应的标准时间戳，从所述第二视频信息中查找用于替代所述第一视频帧的目标视频帧；将所述目标视频帧推送至客户端；

所述至少一个源端设备，用于对采集到的视频内容进行编码得到第一视频信息；将所述第一视频信息发送至云服务端；其中，所述云服务端还存储有由另一源端设备采集到的与所述第一视频信息具有同一视频内容的第二视频信息，当客户端从云服务端的所述第一视频信息中获取第一视频帧失败时，从所述第二视频信息中查找用于替代所述第一视频帧的目标视频帧。

有多个源端设备同时参与视频直播服务，其中，有的源端设备还同时通过多个网络链路进行视频直播。源端设备将采集到的视频信息发送给云服务端，进而，由云服务端将视频信息发送给各个客户端。作为一可选方案，云服务端可以将视频帧发送而给各个CDN，进而由CDN进行数据分发。通过上述系统，能够有效解决因为源端设备故障导致视频无法直播或转播的问题，以及还能够解决网络链路故障导致的无法进行视频的直播或转播的问题。在出现故障的时候，进行视频流切换的具体技术方案，可以参见图1至4所述的相关实施例，这里就不再重复赘述。

基于同样的思路，本申请实施例还提供一种云转播方法。如图8为本申请实施例提供的一种云转播方法的流程示意图。所述方法包括：

801：获取由不同视频设备提供的携带有与相同视频场景相关的视频内容的第一视频信息和第二视频信息。

802：将所述第一视频信息转播给客户端。

803：若监测到的所述第一视频信息中第一视频帧被转播失败，则在所述第二视频信息中查找用于替代所述第一视频帧的目标视频帧。

804：将所述目标视频帧转播至所述客户端。

“云上转播”由于其高效性、便捷性、经济性等特点，得到越来越多的普及，越来越多的重大直播活动通过云服务端进行转播。比如，重大体育比赛、展览、会议等。必须要有一套高可用的云端灾备方案，确保重大转播过程的稳定可靠。但是由于不同源端编码设备的差异性、以及网络链路的不可控，导致“云上转播”面临着诸多稳定性方面的挑战。因此，本申请提出一种能够提升云转播稳定效果的方案。概况来说，本申请方案中，通过设置多个视频设备（也就是源端设备）同时针对相同的视频场景进行视频图像的拍摄采集，如果条件允许则这些源端设备采用相同的编码参数进行编码处理（当然，若无法对所有编码参数进行统一，也可以由云服务端来完成编码统一工作。）对第一视频信息和第二视频信息的编码参数进行统一的相关技术方案具体可参考图1至图7所述各个实施例，这里就不再重复赘述。

在云服务端进行视频转播过程中，如果用于拍摄第一视频信息的视频设备故障，或者用于传输第一视频信息的网络链路故障，进而导致当前正在转播的作为主视频信息的第一视频信息中断，则可以进行视频切换。将当前转播的视频内容切换为第二视频信息。为了使得用户获得更加稳定的观看体验，在切换的时候，可以进行视频帧级别切换，换言之，当第一视频信息中的第一视频帧被转播失败，则会切换到第二视频信息中与第一视频帧具有相同或者相近时间戳的目标视频帧继续为客户端提供视频转播服务。

因此，通过上述方案，在视频设备或者网络链路出现故障的时候，实现在用户无感知的情况下，完成视频切流，能够有效解决因为源端设备故障、传输链路故障等问题对视频传输效果所造成的不利影响，提高视频直播、转播的稳定性。

基于同样的思路，本申请实施例提供一种视频处理装置。如图9为本申请实施例提供的一种视频处理装置的结构示意图。该视频处理装置包括：

获取模块91，用于获取由不同源端设备提供的携带有与相同视频场景相关的视频内容的第一视频信息和第二视频信息，以为客户端获取所述视频内容的视频帧提供服务。

查找模块92，用于若监测到所述客户端从所述第一视频信息中获取第一视频帧失败，则在所述第二视频信息中查找用于替代所述第一视频帧的目标视频帧。

发送模块93，用于将所述目标视频帧发送至所述客户端。

可选地，获取模块91，用于若所述第一视频信息中的第一时间戳与所述第二视频信息中的第二时间戳分别具有不同时间标准，则对所述第一时间戳和所述第二时间戳进行标准化处理，得到第一标准时间戳和第二标准时间戳；

将所述第一视频信息中的第一时间戳更新为所述第一标准时间戳，以及将所述第二视频信息中的第二时间戳更新为所述第二标准时间戳。

可选地，查找模块92，用于接收客户端的拉流请求；

根据所述拉流请求的顺序，从所述第一视频信息的存储空间中拉取第一视频帧；

若监测到所述存储空间中未存储所述第一视频帧，则确定拉取失败。

可选地，查找模块92，用于确定获取第一视频帧失败时对应的第一标准时间戳；

确定所述第二视频信息中各个视频帧对应的所述第二标准时间戳；

根据所述第一标准时间戳和所述第二标准时间戳的匹配结果，确定所述目标视频帧。

可选地，还包括确定模块94，用于获取拉流请求携带的时间戳，将所述时间戳作为所述第一标准时间戳；或者，

获取本地存储的已推流视频帧的时间戳，确定与所述已推流视频帧的时间戳相邻的第一标准时间戳。

可选地，确定模块94还用于确定所述第二视频信息的时间基和各个视频帧对应的时间戳间隔；

基于所述时间基和所述时间戳间隔，确定所述各个视频帧对应的所述第二标准时间戳。

可选地，确定模块94还用于根据所述第一标准时间戳对应视频帧的帧类型，确定与所述第一标准时间戳相同或相邻的所述第二标准时间戳；

确定所述第二标准时间戳对应的视频帧为所述目标视频帧。

可选地，确定模块94还用于获取所述第二视频信息；

对所述第二视频信息进行解码处理，得到各个视频帧分别对应的第二标准时间戳；

根据所述第一标准时间戳对应视频帧的帧类型，确定与所述第一标准时间戳相同或相邻的所述第二标准时间戳。

可选地，确定模块94还用于获取所述第二视频信息各个图像组分别对应的起始时间戳；

从所述第二视频信息中确定与所述第一标准时间戳相邻的所述起始时间戳对应的图像组；所述图像组中包含有所述目标视频帧。

可选地，确定模块94还用于若用于提供所述第一视频信息的源端设备故障和/或链路故障被解除，确定所述第一视频信息存储作为备视频信息。

本申请一个实施例还提供一种电子设备。该电子设备为计算单元中主节点电子设备。如图10为本申请实施例提供的一种电子设备的结构示意图。该电子设备包括存储器1001、处理器1002及通信组件1003；其中，

所述存储器1001，用于存储程序；

所述处理器1002，与所述存储器耦合，用于执行所述存储器中存储的所述程序，以用于：

获取由不同源端设备提供的携带有同一视频内容的第一视频信息和第二视频信息，以为客户端获取所述视频内容的视频帧提供服务；

若监测到所述客户端从所述第一视频信息中获取第一视频帧失败，则在所述第二视频信息中查找用于替代所述第一视频帧的目标视频帧；

将所述目标视频帧发送至所述客户端。

上述存储器1001可被配置为存储其它各种数据以支持在电子设备上的操作。这些数据的示例包括用于在电子设备上操作的任何应用程序或方法的指令。存储器可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器（SRAM），电可擦除可编程只读存储器（EEPROM），可擦除可编程只读存储器（EPROM），可编程只读存储器（PROM），只读存储器（ROM），磁存储器，快闪存储器，磁盘或光盘。

进一步地，本实施例中的所述处理器1002可以具体是：可编程交换处理芯片，该可编程交换处理芯片中配置有数据复制引擎，能对接收到的数据进行复制。

上述处理器1002在执行存储器中的程序时，除了上面的功能之外，还可实现其它功能，具体可参见前面各实施例的描述。进一步，如图10所示，电子设备还包括：电源组件1004等其它组件。

本申请实施例还提供一种非暂时性机器可读存储介质，所述非暂时性机器可读存储介质上存储有可执行代码，当所述可执行代码被电子设备的处理器执行时，使所述处理器执行图1对应实施例所述的方法。

基于同样的思路，本申请实施例还提供另一种视频处理装置。如图11为本申请实施例提供的另一种视频处理装置的结构示意图。该视频处理装置包括：

编码模块111，用于对采集到的视频内容进行编码得到第一视频信息。

发送模块112，用于将所述第一视频信息发送至云服务端；其中，所述云服务端还存储有由另一源端设备采集到的与所述第一视频信息具有同一视频内容的第二视频信息，当客户端从云服务端的所述第一视频信息中获取第一视频帧失败时，从所述第二视频信息中查找用于替代所述第一视频帧的目标视频帧。

本申请实施例还提供一种计算机程序产品，包括计算机程序/指令，当所述计算机程序/指令被处理器执行时，致使所述处理器能够实现图5对应实施例所述的方法。

本申请一个实施例还提供一种电子设备。该电子设备为计算单元中备节点电子设备。如图12为本申请实施例提供的另一种电子设备的结构示意图。该电子设备包括存储器1201、处理器1202及通信组件1203；其中，

所述存储器1201，用于存储程序；

所述处理器1202，与所述存储器耦合，用于执行所述存储器中存储的所述程序，以用于：

对采集到的视频内容进行编码得到第一视频信息；

将所述第一视频信息发送至云服务端；其中，所述云服务端还存储有由另一源端设备采集到的与所述第一视频信息具有同一视频内容的第二视频信息，当客户端从云服务端的所述第一视频信息中获取第一视频帧失败时，从所述第二视频信息中查找用于替代所述第一视频帧的目标视频帧。

上述存储器1201可被配置为存储其它各种数据以支持在电子设备上的操作。这些数据的示例包括用于在电子设备上操作的任何应用程序或方法的指令。存储器可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器（SRAM），电可擦除可编程只读存储器（EEPROM），可擦除可编程只读存储器（EPROM），可编程只读存储器（PROM），只读存储器（ROM），磁存储器，快闪存储器，磁盘或光盘。

进一步地，本实施例中的所述处理器1202可以具体是：可编程交换处理芯片，该可编程交换处理芯片中配置有数据复制引擎，能对接收到的数据进行复制。

上述处理器1202在执行存储器中的程序时，除了上面的功能之外，还可实现其它功能，具体可参见前面各实施例的描述。进一步，如图12所示，电子设备还包括：电源组件1204等其它组件。

本申请实施例还提供一种非暂时性机器可读存储介质，所述非暂时性机器可读存储介质上存储有可执行代码，当所述可执行代码被电子设备的处理器执行时，使所述处理器执行图5对应实施例所述的方法。

基于同样的思路，本申请实施例提供一种云转播装置。如图13为本申请实施例提供的一种云转播装置的结构示意图。该云转播装置包括：

获取模块1301，用于获取由不同视频设备提供的携带有与相同视频场景相关的视频内容的第一视频信息和第二视频信息。

转播模块1302，用于将所述第一视频信息转播给客户端。

查找模块1303，用于若监测到的所述第一视频信息中第一视频帧被转播失败，则在所述第二视频信息中查找用于替代所述第一视频帧的目标视频帧。

转播模块1302，还用于将所述目标视频帧转播至所述客户端。

本申请一个实施例还提供一种电子设备。该电子设备为计算单元中主节点电子设备。如图14为本申请实施例提供的再一种电子设备的结构示意图。该电子设备包括存储器1401、处理器1402及通信组件1403；其中，

所述存储器1401，用于存储程序；

所述处理器1402，与所述存储器耦合，用于执行所述存储器中存储的所述程序，以用于：

获取由不同视频设备提供的携带有与相同视频场景相关的视频内容的第一视频信息和第二视频信息。

将所述第一视频信息转播给客户端。

若监测到的所述第一视频信息中第一视频帧被转播失败，则在所述第二视频信息中查找用于替代所述第一视频帧的目标视频帧。

将所述目标视频帧转播至所述客户端。

上述存储器1401可被配置为存储其它各种数据以支持在电子设备上的操作。这些数据的示例包括用于在电子设备上操作的任何应用程序或方法的指令。存储器可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器（SRAM），电可擦除可编程只读存储器（EEPROM），可擦除可编程只读存储器（EPROM），可编程只读存储器（PROM），只读存储器（ROM），磁存储器，快闪存储器，磁盘或光盘。

进一步地，本实施例中的所述处理器1402可以具体是：可编程交换处理芯片，该可编程交换处理芯片中配置有数据复制引擎，能对接收到的数据进行复制。

上述处理器1402在执行存储器中的程序时，除了上面的功能之外，还可实现其它功能，具体可参见前面各实施例的描述。进一步，如图14所示，电子设备还包括：电源组件1404等其它组件。

本申请实施例还提供一种非暂时性机器可读存储介质，所述非暂时性机器可读存储介质上存储有可执行代码，当所述可执行代码被电子设备的处理器执行时，使所述处理器执行图8对应实施例所述的方法。

基于上述实施例，在利用云计算实现视频直播、视频转播的应用当中，为了确保视频传输的可靠性和稳定性，可以同时使用多个源端设备进行同一视频内容的采集。为了使得不同源端设备所采集得到的第一视频信息和第二视频信息具有很好的一致性，需要为这两个视频信息中添加相同的标准时间戳。当客户端发送拉流请求后，若从第一视频信息中拉取第一视频帧失败，则根据标准时间戳进行切流，也就是从第二视频信息中查找用于替代第一视频帧的目标视频帧。在用户无感知的情况下，完成视频切流，能够有效解决因为源端设备故障、传输链路故障等问题对视频传输效果所造成的不利影响，提高视频直播、转播的稳定性。

以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性的劳动的情况下，即可以理解并实施。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到各实施方式可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件。基于这样的理解，上述技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在计算机可读存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备（可以是个人计算机，服务器，或者网络设备等）执行各个实施例或者实施例的某些部分所述的方法。

最后应说明的是：以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围。

Claims (13)

1.一种视频处理方法，其特征在于，所述方法包括：

获取由不同源端设备提供的携带有与相同视频场景相关的视频内容的第一视频信息和第二视频信息；

若监测到客户端从所述第一视频信息中获取第一视频帧失败，则在所述第二视频信息中查找用于替代所述第一视频帧的目标视频帧；

将所述目标视频帧发送至所述客户端。

2.根据权利要求1所述的方法，其特征在于，获取由不同源端设备提供的携带有与相同视频场景相关的视频内容的第一视频信息和第二视频信息之后，还包括：

若所述第一视频信息中的第一时间戳与所述第二视频信息中的第二时间戳分别具有不同时间标准，则对所述第一时间戳和所述第二时间戳进行标准化处理，得到第一标准时间戳和第二标准时间戳；

将所述第一视频信息中的第一时间戳更新为所述第一标准时间戳，以及将所述第二视频信息中的第二时间戳更新为所述第二标准时间戳。

3.根据权利要求2所述的方法，其特征在于，监测到所述客户端从所述第一视频信息中获取第一视频帧失败，包括：

接收客户端的拉流请求；

根据所述拉流请求的顺序，从所述第一视频信息的存储空间中拉取第一视频帧；

若监测到所述存储空间中未存储所述第一视频帧，则确定拉取失败。

4.根据权利要求2所述的方法，其特征在于，所述在所述第二视频信息中查找用于替代所述第一视频帧的目标视频帧，包括：

确定获取第一视频帧失败时对应的第一标准时间戳；

确定所述第二视频信息中各个视频帧对应的所述第二标准时间戳；

根据所述第一标准时间戳和所述第二标准时间戳的匹配结果，确定所述目标视频帧。

5.根据权利要求4所述的方法，其特征在于，所述确定获取第一视频帧失败时对应的第一标准时间戳，包括：

获取拉流请求携带的时间戳，将所述时间戳作为所述第一标准时间戳；或者，

获取本地存储的已推流视频帧的时间戳，确定与所述已推流视频帧的时间戳相邻的第一标准时间戳。

6.根据权利要求4所述的方法，其特征在于，所述确定所述第二视频信息中各个视频帧对应的所述第二标准时间戳，包括：

确定所述第二视频信息的时间基和各个视频帧对应的时间戳间隔；

基于所述时间基和所述时间戳间隔，确定所述各个视频帧对应的所述第二标准时间戳。

7.根据权利要求4所述的方法，其特征在于，所述根据所述第一标准时间戳和所述第二标准时间戳的匹配结果，确定所述目标视频帧，包括：

根据所述第一标准时间戳对应视频帧的帧类型，确定与所述第一标准时间戳相同或相邻的所述第二标准时间戳；

确定所述第二标准时间戳对应的视频帧为所述目标视频帧。

8.根据权利要求7所述的方法，其特征在于，所述根据所述第一标准时间戳对应视频帧的帧类型，确定与所述第一标准时间戳相同或相邻的所述第二标准时间戳，包括：

获取所述第二视频信息；

对所述第二视频信息进行解码处理，得到各个视频帧分别对应的第二标准时间戳；

根据所述第一标准时间戳对应视频帧的帧类型，确定与所述第一标准时间戳相同或相邻的所述第二标准时间戳。

9.根据权利要求4所述的方法，其特征在于，所述根据所述第一标准时间戳和所述第二标准时间戳的匹配结果，确定所述目标视频帧，包括：

获取所述第二视频信息各个图像组分别对应的起始时间戳；

从所述第二视频信息中确定与所述第一标准时间戳相邻的所述起始时间戳对应的图像组；所述图像组中包含有所述目标视频帧。

10.根据权利要求2所述的方法，其特征在于，还包括：

若用于提供所述第一视频信息的源端设备故障和/或链路故障被解除，则将所述第一视频信息存储作为备视频信息。

11.一种视频处理方法，其特征在于，所述方法包括：

对采集到的视频内容进行编码得到第一视频信息；

将所述第一视频信息发送至云服务端；其中，所述云服务端还存储有由另一源端设备采集到的与所述第一视频信息具有与相同视频场景相关的视频内容的第二视频信息，当客户端从云服务端的所述第一视频信息中获取第一视频帧失败时，从所述第二视频信息中查找用于替代所述第一视频帧的目标视频帧。

12.一种视频处理系统，其特征在于，所述系统包括：至少一个源端设备、云服务端、客户端；

所述云服务端，用于获取由不同源端设备提供的携带有与相同视频场景相关的视频内容的第一视频信息和第二视频信息；若基于拉流请求从所述第一视频信息中拉取第一视频帧失败，则根据所述拉流请求对应的标准时间戳，从所述第二视频信息中查找用于替代所述第一视频帧的目标视频帧；将所述目标视频帧推送至客户端；

所述至少一个源端设备，用于对采集到的视频内容进行编码得到第一视频信息；将所述第一视频信息发送至云服务端；其中，所述云服务端还存储有由另一源端设备采集到的与所述第一视频信息具有与相同视频场景相关的视频内容的第二视频信息，当客户端从云服务端的所述第一视频信息中获取第一视频帧失败时，从所述第二视频信息中查找用于替代所述第一视频帧的目标视频帧。

13.一种云转播方法，其特征在于，所述方法包括：

获取由不同视频设备提供的携带有与相同视频场景相关的视频内容的第一视频信息和第二视频信息；

将所述第一视频信息转播给客户端；

若监测到的所述第一视频信息中第一视频帧被转播失败，则在所述第二视频信息中查找用于替代所述第一视频帧的目标视频帧；

将所述目标视频帧转播至所述客户端。

Images