CN117793389A - 直播卡顿原因确定方法和装置 - Google Patents

Abstract

本申请实施例提供了一种直播卡顿原因确定方法和装置，应用于直播系统，所述直播系统包含导播台、推流服务器和转发服务器，所述转发服务器支持流转发的功能，所述方法包括：将第一直播流通过所述导播台推流到推流服务器；通过所述转发服务器复制所述第一直播流得到第二直播流，并将所述第二直播流推流到推流服务器，以在所述推流服务器中录制所述第二直播流；在发生直播卡顿的情况下，根据所述第二直播流的录制文件进行流量回放以确定直播卡顿原因。通过转发服务器实现对原始的直播流进行录制，在发生卡顿后，通过利用第二直播流的录制文件进行流量回放来确定直播卡顿原因，在节省了人力的同时，也提高了定位直播卡顿原因的效率。

Description

直播卡顿原因确定方法和装置

技术领域

本申请实施例涉及数据传输技术领域，尤其涉及一种直播卡顿原因确定方法、装置、计算机设备及计算机可读存储介质。

背景技术

现有直播系统中，对于比较重要的直播活动，一般会采用主备两条线路进行推流的方式，通过引入云导播台，导播台会同时拉取主备线路，并根据预设的判断逻辑，判断主备线路的信号是否正常，选择信号最健康的一个线路作为当前输入信号的线路，通过编解码处理后，再利用该线路将数据推流到推流服务器上。流会在推流服务器上进行录制，形成录制文件。当主线路的信号出现问题的时候，导播台会检测到，自动把输入信号的线路切换为备用线路，继续编解码操作，这样对于用户而言就是无感知的了。

然而，这种推流方式存在一个问题：当观众观看卡顿的时候，通过回看录制文件，发现数据在推流到推流服务器上就已经发生出现流异常，但是无法确定，这个流的异常是因为导播台的编解码处理导致的，还是因为主备线路的信号有问题导致的。

发明内容

本申请实施例的目的是提供一种直播卡顿原因确定方法、装置、计算机设备及计算机可读存储介质，用于解决以下问题：如何快速定位到底是什么原因导致的直播卡顿。

本申请实施例的一个方面提供了一种直播卡顿原因确定方法，应用于直播系统，所述直播系统包含导播台、推流服务器和转发服务器，所述转发服务器支持流转发的功能，所述方法包括：

将第一直播流通过所述导播台推流到推流服务器；

通过所述转发服务器复制所述第一直播流得到第二直播流，并将所述第二直播流推流到推流服务器，以在所述推流服务器中录制所述第二直播流；

在发生直播卡顿的情况下，根据所述第二直播流的录制文件进行流量回放以确定直播卡顿原因。

可选地，所述在发生直播卡顿的情况下，根据所述第二直播流的录制文件进行流量回放以确定直播卡顿原因，包括

在发生直播卡顿的情况下，将所述第二直播流的录制文件通过所述导播台推流到所述推流服务器并记录为推流X，及，将所述第二直播流的录制文件推流到所述推流服务器并记录为推流Y；

根据所述推流X和推流Y确定直播卡顿原因。

可选地，所述根据所述推流X和推流Y确定直播卡顿原因，包括：

通过预置的播测装置分别访问所述推流X和推流Y，并确定访问所述推流X和推流Y时的卡顿情况；

根据访问所述推流X和推流Y时的卡顿情况，确定直播卡顿原因。

可选地，所述根据访问所述推流X和推流Y时的卡顿情况，确定直播卡顿原因，包括：

在访问所述推流X和推流Y时都发生卡顿的情况下，确定直播卡顿原因为主备线路发生问题。

可选地，所述根据访问所述推流X和推流Y时的卡顿情况，确定直播卡顿原因，包括：

在访问所述推流X时发生卡顿且访问所述推流Y时不发生卡顿的情况下，确定直播卡顿原因为导播台编解码处理发生问题。

可选地，所述根据访问所述推流X和推流Y时的卡顿情况，确定直播卡顿原因，包括：

在访问所述推流X和推流Y时都没有发生卡顿的情况下，确定直播卡顿原因为CDN网络发生问题。

可选地，所述将所述第二直播流的录制文件推流到推流服务器并记录为推流Y，包括：

通过FFmpeg命令将所述第二直播流的录制文件推流到推流服务器并记录为推流Y。

可选地，在所述将第一直播流通过所述导播台推流到推流服务器的步骤之前，还包括：

通过所述转发服务器获取所述第一直播流，并将所述第一直播流转发至所述导播台。

本申请实施例的一个方面又提供了一种直播卡顿原因确定装置，应用于直播系统，所述直播系统包含导播台、推流服务器和转发服务器，所述转发服务器支持流转发的功能，所述装置包括：

第一推流装置，用于将第一直播流通过所述导播台推流到推流服务器；

第二推流装置，用于通过所述转发服务器复制所述第一直播流得到第二直播流，并将所述第二直播流推流到推流服务器，以在所述推流服务器中录制所述第二直播流；

卡顿原因确定装置，用于在发生直播卡顿的情况下，根据所述第二直播流的录制文件进行流量回放以确定直播卡顿原因。

本申请实施例的一个方面又提供了一种计算机设备，所述计算机设备包括存储器、处理器以及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现如上述的直播卡顿原因确定方法的步骤。

本申请实施例的一个方面又提供了一种计算机可读存储介质，所述计算机可读存储介质内存储有计算机程序，所述计算机程序可被至少一个处理器所执行，以使所述至少一个处理器执行所述计算机程序时实现如上述的直播卡顿原因确定方法的步骤。

本申请实施例提供的直播卡顿原因确定方法、装置、设备及计算机可读存储介质，通过引入转发服务器，并利用转发服务器复用第一直播流的方式，以解决拉流次数限制，然后自动将复制的流转推到推流服务器上，以实现对原始的直播流进行录制。在发生卡顿后，通过利用第二直播流的录制文件进行流量回放来确定直播卡顿原因，在节省了人力的同时，也提高了定位直播卡顿原因的效率。

附图说明

图1A示意性示出了现有的一种直播推流过程的模块化框图；

图1B示意性示出了现有的另一种直播推流过程的模块化框图；

图2示意性示出了根据本申请实施例的直播卡顿原因确定方法的应用环境图；

图3示意性示出了根据本申请实施例一的直播卡顿原因确定方法的流程图；

图4示出了根据本申请实施例一的一种直播系统的模块化结构示意图；

图5示出了根据本申请实施例一的一种流量回放过程的模块化结构示意图；

图6示意性示出了根据本申请实施例二的直播卡顿原因确定装置的框图；及

图7示意性示出了根据本申请实施例三的适于实现直播卡顿原因确定方法的计算机设备的硬件架构示意图。

具体实施方式

为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处所描述的具体实施例仅用以解释本申请，并不用于限定本申请。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

需要说明的是，在本申请实施例中涉及“第一”、“第二”等的描述仅用于描述目的，而不能理解为指示或暗示其相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括至少一个该特征。另外，各个实施例之间的技术方案可以相互结合，但是必须是以本领域普通技术人员能够实现为基础，当技术方案的结合出现相互矛盾或无法实现时应当认为这种技术方案的结合不存在，也不在本申请要求的保护范围之内。

现有直播系统中，对于比较重要的直播活动，一般会采用主备两条线路进行推流的方式，具体的直播平台的推流方式有如下2种：

方式1:直接推直播间：推流过程如图1A所示，通过只把一条线路的信号直接推流到直播间，当该线路出问题的时候，切换到另一条线路推流。这种推流方式存在的问题是：观众已经在观看通过有问题的线路推流的数据了，必然会受到影响，只有重新刷新页面，才会获取到最新的线路的播放地址。

方式2：引入云导播台：推流过程如图1B所示，通过导播台会同时拉取主备线路，并根据预设的判断逻辑，判断主备线路的信号是否正常，选择信号最健康的一个线路作为当前输入信号的线路，通过编解码处理后，再利用该线路将数据推流到推流服务器上。流会在推流服务器上进行录制，形成录制文件，。当主线路的信号出现问题的时候，导播台会检测到，自动把输入信号的线路切换为备用线路，继续编解码操作，这样对于用户而言就是无感知的了。

一般对于直播平台而言，会选择方式2，因为这种推流方式更加稳定。但是方式2会带来另外一个问题：当观众观看卡顿的时候，通过回看录制文件(没有经过任何处理的流录制)，发现数据在推流到推流服务器上就已经发生出现流异常。

但是无法确定，这个流的异常是因为导播台的编解码处理导致的，还是因为主备线路的信号有问题导致的。也许有人会认为直接通过单独拉一下主备线路传输的数据进行录制即可检查出线路问题，但是很多信号直播供应商对于提供的主备信号均有拉流次数的限制，不允许多次拉流，而且，当出现卡顿问题的时候，才去拉流录制，时机已经过去了，这时进行录制已经无法录制到出现卡顿问题时的历史现象了。同时，录制之后要想判断线路有无问题，还需要人为的去回查看录像数据，利用人工先判断主备线路的录制有没有问题，如果没有问题，才可以确定是导播台编解码操作的问题，这种检查问题的方式需要人为参与性很大，耗费人力资源。

因此，需要有更为直观便捷的流量回放的方式，以快速定位到底是什么原因导致的直播卡顿。

有鉴于此，本申请旨在提出一种直播卡顿原因确定方法，应用于直播系统，所述直播系统包含导播台、推流服务器和转发服务器，所述转发服务器支持流转发的功能，通过将第一直播流通过所述导播台推流到推流服务器；通过所述转发服务器复制所述第一直播流得到第二直播流，并将所述第二直播流推流到推流服务器，以在所述推流服务器中录制所述第二直播流；在发生直播卡顿的情况下，根据所述第二直播流的录制文件进行流量回放以确定直播卡顿原因。从而通过引入转发服务器，并利用转发服务器复用第一直播流的方式，以解决拉流次数限制，然后自动将复制的流转推到推流服务器上，以实现对原始的直播流进行录制。在发生卡顿后，通过利用第二直播流的录制文件进行流量回放来确定直播卡顿原因，在节省了人力的同时，也提高了定位直播卡顿原因的效率。

本申请提供了多个实施例进一步介绍直播卡顿原因确定方案，具体参照下文。

在本申请的描述中，需要理解的是，步骤前的数字标号并不标识执行步骤的前后顺序，仅用于方便描述本申请及区别每一步骤，因此不能理解为对本申请的限制。

以下为本申请的术语解释：

直播流：直播音视频数据的传输，它能够被作为一个稳定的和连续的流通过网络传输给观众观看。

直播房间：直播服务中，每个主播会有一个唯一标识符，以标识符可以进入该主播的直播观看页面。

CDN：Content Delivery Network,内容分发网络，是为加快网络访问速度而建立在现有网络之上的分布式网络。

导播台：依托云端强大的视频直播能力，在云端实现直播流的切换，多画面的混流播出等。

FFmpeg：是一套可以用来记录、转换数字音频、视频，并能将其转化为流的开源计算机程序。

图2示意性示出了根据本申请实施例的环境应用示意图。如图2所示：

计算机设备10000可以通过网络20000连接客户端30000。

计算机设备10000可以提供服务，如进行网络调试，或返回直播卡顿原因确定结果数据给客户端30000等。

计算机设备10000可以位于诸如单个场所之类的数据中心，或者分布在不同的地理位置(例如，在多个场所)中。计算机设备10000可以经由一个或多个网络20000提供服务。网络20000包括各种网络设备，例如路由器，交换机，多路复用器，集线器，调制解调器，网桥，中继器，防火墙，代理设备和/或类似。网络20000可以包括物理链路，例如同轴电缆链路，双绞线电缆链路，光纤链路，其组合等。网络20000可以包括无线链路，诸如蜂窝链路，卫星链路，Wi-Fi链路等。

计算机设备10000可以由一个或多个计算节点实现。一个或多个计算节点可以包括虚拟化的计算实例。虚拟化的计算实例可以包括虚拟机，例如计算机系统，操作系统，服务器等的仿真。计算节点可以基于虚拟映像和/或定义用于仿真的特定软件(例如，操作系统，专用应用程序，服务器)的其他数据，由计算节点加载虚拟机。随着对不同类型的处理服务的需求改变，可以在一个或多个计算节点上加载和/或终止不同的虚拟机。可以实现管理程序来管理同一计算节点上不同虚拟机的使用。

客户端30000可以被配置为访问计算机设备10000的内容和服务。客户端30000可以包括任何类型的电子设备，诸如移动设备、平板设备、膝上型计算机、工作站、虚拟现实设备，游戏设备、机顶盒、数字流媒体设备、车辆终端、智能电视、机顶盒等。

客户端30000可以将直播卡顿原因确定结果数据等输出(例如，显示、渲染、呈现)给用户。

以下将通过多个实施例介绍网络调试方案。该方案可以通过计算机设备10000实施。

实施例一

图3示意性示出了根据本申请实施例一的直播卡顿原因确定方法的流程图。应用于直播系统，所述直播系统包含导播台、推流服务器和转发服务器，所述转发服务器支持流转发的功能，所述方法包括步骤S302-S306，其中，

步骤S302，将第一直播流通过所述导播台推流到推流服务器；

其中，第一直播流可以指原始的直播数据流。

在本实施例中，为了方便确定直播卡顿原因，提供了两条推流路径。其中一是将第一直播流通过导播台推流到推流服务器，另一个是通过转发服务器直接推流到推流服务器。具体的，导播台在对第一直播流进行推流时，首先需要对第一直播流进行编解码处理，然后再将编解码处理后的第一直播流推送到推流服务器中，以供观众端拉取第一直播流来观看直播。

在本申请的一种优选实施例中，在所述步骤S302之前还可以包括如下步骤：

通过所述转发服务器获取所述第一直播流，并将所述第一直播流转发至所述导播台。

在本实施例中，需要先经过转发服务器来获取第一直播流，并转发至导播台，以便于在转发服务器中复用第一直播流。

步骤S304，通过所述转发服务器复制所述第一直播流得到第二直播流，并将所述第二直播流推流到推流服务器，以在所述推流服务器中录制所述第二直播流；

在本实施例中，在直播系统中引入转发服务器，该转发服务器支持流转发的功能，通过转发服务器复制第一直播流得到第二直播流，并将第二直播流推流到推流服务器，以在推流服务器中录制第二直播流。

由于第二直播流通过完全复制COPY第一直播流得到，而且此时第一直播流还没有传输到导播台进行编解码处理，因此，第二直播流可以作为导播台推流到推流服务器的原始数据，通过转发服务器将复制得到的第二直播流推流到推流服务器，以在推流服务器中录制第二直播流，从而可以实现录制对未经过导播台编解码处理的原始数据的录制。

步骤S306，在发生直播卡顿的情况下，根据所述第二直播流的录制文件进行流量回放以确定直播卡顿原因。

具体的，可以通过部署一个相同的推流装置，利用第二直播流的录制文件作为输入数据，模拟直播过程的两条推流路径，其中一个路径为推流路径为通过导播台进行推流，另一个路径为直接将输入数据推流至推流服务器，然后通过播测系统分别访问两个路径的推流数据，并判断这两个路径的推流数据卡顿情况，以根据卡顿情况确定直播卡顿原因。其中，若是两个路径的推流数据都发生卡顿，则说明是主备线路出了问题；若通过导播台推流的数据发生卡顿，而另一条路径不发生卡顿，则说明是导播台的编解码处理过程存在问题；若两个路径的推流数据都没有发生卡顿，则说明数据的生产环节没有问题，可能是当时播放的CDN出现了问题。从而可以通过利用第二直播流的录制文件进行流量回放来确定直播卡顿原因，在节省了人力的同时，也提高了定位直播卡顿原因的效率。

以下提供几个可选地实施例，以进行优化所述直播卡顿原因确定方法，具体如下：

在本申请的一种优选实施例中，所述步骤S306可以包括如下步骤：

在发生直播卡顿的情况下，将所述第二直播流的录制文件通过所述导播台推流到所述推流服务器并记录为推流X，及，将所述第二直播流的录制文件推流到所述推流服务器并记录为推流Y；根据所述推流X和推流Y确定直播卡顿原因。

在本实施例中，在发生直播卡顿的情况下，利用第二直播流的录制文件作为输入数据，模拟直播时的推流过程，将第二直播流的录制文件通过导播台推流到所述推流服务器并记录为推流X，及，将第二直播流的录制文件推流到推流服务器并记录为推流Y，进而可以根据推流X和推流Y确定直播卡顿原因。

在本申请的一种优选实施例中，所述根据所述推流X和推流Y确定直播卡顿原因，包括：

通过预置的播测装置分别访问所述推流X和推流Y，并确定访问所述推流X和推流Y时的卡顿情况；根据访问所述推流X和推流Y时的卡顿情况，确定直播卡顿原因。

在本实施例中，预置的播测装置是预先部署的用于回放直播流的装置，在需要根据推流X和推流Y确定直播卡顿原因时，通过预置的播测装置分别访问推流X和推流Y，并确定访问推流X和推流Y时的卡顿情况，从而可以根据访问推流X和推流Y时的卡顿情况，确定直播卡顿原因。

在本申请的一种优选实施例中，所述根据访问所述推流X和推流Y时的卡顿情况，确定直播卡顿原因，包括：

在访问所述推流X和推流Y时都发生卡顿的情况下，确定直播卡顿原因为主备线路发生问题。

在本实施例中，在访问推流X和推流Y时都发生卡顿的情况下，则说明通过主备线路数据的数据源有问题，可以确定直播卡顿原因为主备线路发生问题。

在本申请的一种优选实施例中，所述根据访问所述推流X和推流Y时的卡顿情况，确定直播卡顿原因，包括：

在访问所述推流X时发生卡顿且访问所述推流Y时不发生卡顿的情况下，确定直播卡顿原因为导播台编解码处理发生问题。

在本实施例中，在访问推流X时发生卡顿且访问推流Y时不发生卡顿的情况下，则说明导播台推流的数据有问题，可以确定直播卡顿原因为导播台编解码处理发生问题。

在本申请的一种优选实施例中，所述根据访问所述推流X和推流Y时的卡顿情况，确定直播卡顿原因，包括：

在访问所述推流X和推流Y时都没有发生卡顿的情况下，确定直播卡顿原因为CDN网络发生问题。

在本实施例中，在访问推流X和推流Y时都没有发生卡顿的情况下，则说明数据的生产环节没有问题，可以确定直播卡顿原因为CDN网络发生问题。

在本申请的一种优选实施例中，所述将所述第二直播流的录制文件推流到推流服务器并记录为推流Y，包括：

通过FFmpeg命令将所述第二直播流的录制文件推流到推流服务器并记录为推流Y。

在本实施例中，可以通过FFmpeg命令将第二直播流的录制文件推流到推流服务器并记录为推流Y。

如图4示出了一种直播系统的模块化结构示意图，包含转发服务器，导播台，推理服务器和CDN。经研究发现，要想解决拉流次数限制的问题，就要能复用输入线路的链接。通过新增转发服务器，该转发服务器支持流转发的功能，即收到线路信号A和B的直播流之后，进行原始数据的COPY，并输出信号a和b。因为是完全COPY流数据，所以数据并没有改动，只是多了一层转发。当有两个观众C，D来拉信号a和b的时候，因为在同一个机器上，所以链接可以复用，只会拉取一次线路信号A和B的直播流。而转发服务发现有人正在拉取a信号的时候，会自动将信号转发到推流服务器上，进行录制，复用正常直播的推流录制功能。

如图5示出了一种流量回放过程的模块化结构示意图，包含导播台，推理服务器和CDN，同时，录制文件作为流量回放过程的输入数据，当发生卡顿的时候，只需要发起流量回放即可，具体包含如下过程：

1.输入发生卡顿的时间段和录制的信号a和b的名称，查询到其录制文件。

2.重新部署一个一样的导播台，将录制文件作为输入，按照直播过程的推流配置，将输入数据推流到推流服务器上并记录为推流X。

3.直接将录制文件作为输入，利用FFmpeg命令，按照直播过程的推流配置，将输入数据推流到推流服务器上并记录为推流Y。

4.启动预置的播测装置，利用预置的播测装置同时访问推流X和推流Y，判断访问推流X和推流Y时的卡顿情况。若访问推流X和推流Y时都发生卡顿，则说明是主备线路AB出了问题；若访问推理X时发生卡顿，访问推理Y时不发生卡顿，则说明是导播台的编解码处理过程存在问题；若访问推理X和推理Y时都没有发生卡顿，则说明生产环节没有问题，是当时播放的CDN出现了问题。

实施例二

图6示意性示出了根据本申请实施例二的直播卡顿原因确定装置的框图，该直播卡顿原因确定装置可以被分割成一个或多个程序模块，一个或者多个程序模块被存储于存储介质中，并由一个或多个处理器所执行，以完成本申请实施例。本申请实施例所称的程序模块是指能够完成特定功能的一系列计算机程序指令段，以下描述将具体介绍本申请实施例中各程序模块的功能。

应用于直播系统，所述直播系统包含导播台、推流服务器和转发服务器，所述转发服务器支持流转发的功能，如图6所示，该直播卡顿原因确定装置600可以包括如下模块：

第一推流装置610，用于将第一直播流通过所述导播台推流到推流服务器；

第二推流装置620，用于通过所述转发服务器复制所述第一直播流得到第二直播流，并将所述第二直播流推流到推流服务器，以在所述推流服务器中录制所述第二直播流；

卡顿原因确定装置630，用于在发生直播卡顿的情况下，根据所述第二直播流的录制文件进行流量回放以确定直播卡顿原因。

在本申请的一种优选实施例中，所述卡顿原因确定装置630，包括

重新推理子模块，用于在发生直播卡顿的情况下，将所述第二直播流的录制文件通过所述导播台推流到所述推流服务器并记录为推流X，及，将所述第二直播流的录制文件推流到所述推流服务器并记录为推流Y；

卡顿原因确定子模块，用于根据所述推流X和推流Y确定直播卡顿原因。

在本申请的一种优选实施例中，所述卡顿原因确定子模块，包括：

流量回放单元，用于通过预置的播测装置分别访问所述推流X和推流Y，并确定访问所述推流X和推流Y时的卡顿情况；

卡顿原因确定单元，用于根据访问所述推流X和推流Y时的卡顿情况，确定直播卡顿原因。

在本申请的一种优选实施例中，所述卡顿原因确定单元，包括：

第一原因确定子单元，用于在访问所述推流X和推流Y时都发生卡顿的情况下，确定直播卡顿原因为主备线路发生问题。

在本申请的一种优选实施例中，所述卡顿原因确定单元，包括：

第二原因确定子单元，用于在访问所述推流X时发生卡顿且访问所述推流Y时不发生卡顿的情况下，确定直播卡顿原因为导播台编解码处理发生问题。

在本申请的一种优选实施例中，所述卡顿原因确定单元，包括：

第三原因确定子单元，用于在访问所述推流X和推流Y时都没有发生卡顿的情况下，确定直播卡顿原因为CDN网络发生问题。

在本申请的一种优选实施例中，所述重新推理子模块，包括：

推理单元，用于通过FFmpeg命令将所述第二直播流的录制文件推流到推流服务器并记录为推流Y。

在本申请的一种优选实施例中，所述装置还包括：

第一直播流转发模块，用于通过所述转发服务器获取所述第一直播流，并将所述第一直播流转发至所述导播台。

实施例三

图7示意性示出了根据本申请实施例三的适于实现直播卡顿原因确定方法的计算机设备10000的硬件架构示意图。本实施例中，计算机设备10000是一种能够按照事先设定或者存储的指令，自动进行数值计算和/或信息处理的设备。例如，可以是智能手机、平板电脑、笔记本电脑、台式计算机、机架式服务器、刀片式服务器、塔式服务器或机柜式服务器(包括FEN独立的服务器，或者多个服务器所组成的服务器集群)等。如图7所示，计算机设备10000至少包括但不限于：可通过系统总线相互通信链接存储器10010、处理器10020、网络接口10030。其中：

存储器10010至少包括一种类型的计算机可读存储介质，可读存储介质包括闪存、硬盘、多媒体卡、卡型存储器(例如，SD或DX存储器等)、随机访问存储器(RAM)、静态随机访问存储器(SRAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、可编程只读存储器(PROM)、磁性存储器、磁盘、光盘等。在一些实施例中，存储器10010可以是计算机设备10000的内部存储模块，例如该计算机设备10000的硬盘或内存。在另一些实施例中，存储器10010也可以是计算机设备10000的外部存储设备，例如该计算机设备10000上配备的插接式硬盘，智能存储卡(Smart Media Card，简称为SMC)，安全数字(Secure Digital，简称为SD)卡，闪存卡(Flash Card)等。当然，存储器10010还可以既包括计算机设备10000的内部存储模块也包括其外部存储设备。本实施例中，存储器10010通常用于存储安装于计算机设备10000的操作系统和各类应用软件，例如直播卡顿原因确定方法的程序代码等。此外，存储器10010还可以用于暂时地存储已经输出或者将要输出的各类数据。

处理器10020在一些实施例中可以是中央处理器(Central Processing Unit，简称为CPU)、控制器、微控制器、微处理器、或其他数据处理芯片。该处理器10020通常用于控制计算机设备10000的总体操作，例如执行与计算机设备10000进行数据交互或者通信相关的控制和处理等。本实施例中，处理器10020用于运行存储器10010中存储的程序代码或者处理数据。

网络接口10030可包括无线网络接口或有线网络接口，该网络接口10030通常用于在计算机设备10000与其他计算机设备之间建立通信链接。例如，网络接口10030用于通过网络将计算机设备10000与外部终端相连，在计算机设备10000与外部终端之间的建立数据传输通道和通信链接等。网络可以是企业内部网(Intranet)、互联网(Internet)、全球移动通讯系统(Global System of Mobile communication，简称为GSM)、宽带码分多址(Wideband Code Division Multiple Access，简称为WCDMA)、4G网络、5G网络、蓝牙(Bluetooth)、Wi-Fi等无线或有线网络。

需要指出的是，图7仅示出了具有部件10010-10030的计算机设备，但是应理解的是，并不要求实施所有示出的部件，可以替代的实施更多或者更少的部件。

在本实施例中，存储于存储器10010中的直播卡顿原因确定方法还可以被分割为一个或者多个程序模块，并由一个或多个处理器(本实施例为处理器10020)所执行，以完成本申请实施例。

实施例四

本申请实施例还提供一种计算机可读存储介质，计算机可读存储介质其上存储有计算机程序，计算机程序被处理器执行时实现实施例中的直播卡顿原因确定方法的步骤。

本实施例中，计算机可读存储介质包括闪存、硬盘、多媒体卡、卡型存储器(例如，SD或DX存储器等)、随机访问存储器(RAM)、静态随机访问存储器(SRAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、可编程只读存储器(PROM)、磁性存储器、磁盘、光盘等。在一些实施例中，计算机可读存储介质可以是计算机设备的内部存储单元，例如该计算机设备的硬盘或内存。在另一些实施例中，计算机可读存储介质也可以是计算机设备的外部存储设备，例如该计算机设备上配备的插接式硬盘，智能存储卡(Smart Media Card，简称为SMC)，安全数字(Secure Digital，简称为SD)卡，闪存卡(Flash Card)等。当然，计算机可读存储介质还可以既包括计算机设备的内部存储单元也包括其外部存储设备。本实施例中，计算机可读存储介质通常用于存储安装于计算机设备的操作系统和各类应用软件，例如实施例中直播卡顿原因确定方法的程序代码等。此外，计算机可读存储介质还可以用于暂时地存储已经输出或者将要输出的各类数据。

显然，本领域的技术人员应该明白，上述的本申请实施例的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，并且在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本申请实施例不限制于任何特定的硬件和软件结合。

以上仅为本申请的优选实施例，并非因此限制本申请的专利范围，凡是利用本申请说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本申请的专利保护范围内。

Claims (11)

1.一种直播卡顿原因确定方法，其特征在于，应用于直播系统，所述直播系统包含导播台、推流服务器和转发服务器，所述转发服务器支持流转发的功能，所述方法包括：

将第一直播流通过所述导播台推流到推流服务器；

通过所述转发服务器复制所述第一直播流得到第二直播流，并将所述第二直播流推流到推流服务器，以在所述推流服务器中录制所述第二直播流；

在发生直播卡顿的情况下，根据所述第二直播流的录制文件进行流量回放以确定直播卡顿原因。

2.根据权利要求1所述的直播卡顿原因确定方法，其特征在于，所述在发生直播卡顿的情况下，根据所述第二直播流的录制文件进行流量回放以确定直播卡顿原因，包括

在发生直播卡顿的情况下，将所述第二直播流的录制文件通过所述导播台推流到所述推流服务器并记录为推流X，及，将所述第二直播流的录制文件推流到所述推流服务器并记录为推流Y；

根据所述推流X和推流Y确定直播卡顿原因。

3.根据权利要求2所述的直播卡顿原因确定方法，其特征在于，所述根据所述推流X和推流Y确定直播卡顿原因，包括：

通过预置的播测装置分别访问所述推流X和推流Y，并确定访问所述推流X和推流Y时的卡顿情况；

根据访问所述推流X和推流Y时的卡顿情况，确定直播卡顿原因。

4.根据权利要求3所述的直播卡顿原因确定方法，其特征在于，所述根据访问所述推流X和推流Y时的卡顿情况，确定直播卡顿原因，包括：

在访问所述推流X和推流Y时都发生卡顿的情况下，确定直播卡顿原因为主备线路发生问题。

5.根据权利要求3所述的直播卡顿原因确定方法，其特征在于，所述根据访问所述推流X和推流Y时的卡顿情况，确定直播卡顿原因，包括：

在访问所述推流X时发生卡顿且访问所述推流Y时不发生卡顿的情况下，确定直播卡顿原因为导播台编解码处理发生问题。

6.根据权利要求3所述的直播卡顿原因确定方法，其特征在于，所述根据访问所述推流X和推流Y时的卡顿情况，确定直播卡顿原因，包括：

在访问所述推流X和推流Y时都没有发生卡顿的情况下，确定直播卡顿原因为CDN网络发生问题。

7.根据权利要求2所述的直播卡顿原因确定方法，其特征在于，所述将所述第二直播流的录制文件推流到推流服务器并记录为推流Y，包括：

通过FFmpeg命令将所述第二直播流的录制文件推流到推流服务器并记录为推流Y。

8.根据权利要求1所述的直播卡顿原因确定方法，其特征在于，在所述将第一直播流通过所述导播台推流到推流服务器的步骤之前，还包括：

通过所述转发服务器获取所述第一直播流，并将所述第一直播流转发至所述导播台。

9.一种直播卡顿原因确定装置，其特征在于，应用于直播系统，所述直播系统包含导播台、推流服务器和转发服务器，所述转发服务器支持流转发的功能，所述装置包括：

第一推流装置，用于将第一直播流通过所述导播台推流到推流服务器；

第二推流装置，用于通过所述转发服务器复制所述第一直播流得到第二直播流，并将所述第二直播流推流到推流服务器，以在所述推流服务器中录制所述第二直播流；

卡顿原因确定装置，用于在发生直播卡顿的情况下，根据所述第二直播流的录制文件进行流量回放以确定直播卡顿原因。

10.一种计算机设备，所述计算机设备包括存储器、处理器以及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时用于实现权利要求1至8中任意一项所述的直播卡顿原因确定方法的步骤。

11.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质内存储有计算机程序，所述计算机程序可被至少一个处理器所执行，以使所述至少一个处理器执行权利要求1至8中任意一项所述的直播卡顿原因确定方法的步骤。