CN107690077B - 监测视频直播卡顿的方法和装置 - Google Patents

Abstract

本公开提供一种监测视频直播卡顿的方法和装置，涉及计算机信息处理领域，该方法包括：在具有直播功能的应用程序App中建立模型以设计需要采集的目标数据；设计所述目标数据产生的位置；以及根据所设计的目标数据产生的位置，结合直播节点放置数据采集点。本公开提供的监测视频直播卡顿的方法和装置，能够快速定位卡顿原因，高效解决直播卡顿问题。

Description

监测视频直播卡顿的方法和装置

技术领域

本公开涉及互联网技术领域，特别涉及一种监测视频直播卡顿的方法和装置。

背景技术

当前，直播迎来了爆发式增长，很多应用程序(App)都提供了直播功能。随着来自主播的并发量的不断增高，直播间异常检测成为优化直播体验必要的技术手段。

例如，七牛云直播SDK(软件开发工具包)提出了一种基于单个直播流业务粒度的线路质量智能监控及实时动态的数据统计，其主要是通过监控直播数据流的异常状态来检测直播异常。其优点是直接监控数据流，从源头分析卡顿原因，准确性较高。然而这种统计并没有结合App业务分析，并且没有开放给使用方，导致使用方不能快速监测到自己的App异常状态，从而不能及时定位问题。另外，在监测过程中并没有拆分出每一个可能发生异常的直播节点，不能快速准确地定位问题发生的位置。

另一种监测方案是第三方数据统计，比如友盟统计。其通过采集数据，再将数据上传到友盟服务器，由友盟服务器统计分析上传的数据，然后定位直播异常。然而这种技术必须引入第三方SDK，App包会增大，并且把数据暴露出去，数据安全存在巨大隐患。

基于上述，可以发现当前技术的缺点主要集中在以下三个方面：1)SDK方提供的监控方案不开放，不接入App业务层，无法获取直播卡顿异常记录；2)第三方统计SDK需要在App包中接入SDK包，会增大本身App包的大小，且无法保证数据安全性；3)以上两种方案都不能最大可能地实时监控卡顿状态，对于突发直播异常状态缺乏控制性。

发明内容

鉴于上述问题，本发明实施例结合数据埋点上报技术，提出一种针对App的视频直播卡顿监测方案，该方案通过目标数据建模，采集目标数据并上传到服务器，然后整合分析出可视化卡顿数据分析表，从而可以帮助开发者快速定位问题。

为达到上述目的，根据本公开实施例的第一方面，本公开的实施例提供一种监测视频直播卡顿的方法，包括：在具有直播功能的应用程序App中建立模型以设计需要采集的目标数据；设计所述目标数据产生的位置；以及根据所设计的目标数据产生的位置，结合直播节点放置数据采集点。

根据本公开实的实施例，在App进入直播后，在所述数据采集点采集数据，并将所采集的数据上报给服务器，从而监测视频直播卡顿。

根据本公开实的实施例，其中，所述在具有直播功能的应用程序App中建立模型包括：在App启动前，基于历史视频直播卡顿的原因在App中建立模型。

根据本公开实的实施例，所述目标数据包括首播时间、首播时长分布、异常比例、卡顿时间占比、卡顿用户分布、卡顿时间和次数、以及单次卡顿时间中的至少一个。

根据本公开实的实施例，其中，所述将所采集的数据上报给服务器包括：通过数据埋点上传方式将所采集的数据上报给所述服务器。

根据本公开实的实施例，所述数据埋点上传方式包括批量数据埋点上传方式。

根据本公开实的实施例，所述服务器分析上报的数据，并据此显示监测数据表。

根据本公开实的实施例，所述监测数据表包括平均首播时间图、首播时长分布图、平均每次播放有感知卡顿次数图中的至少一个。

根据本公开实施例的第二方面，本公开的实施例还提供一种监测视频直播卡顿的装置，包括：目标数据设计模块，用于在具有直播功能的应用程序App中建立模型以设计需要采集的目标数据；位置设计模块，用于设计所述目标数据产生的位置；以及采集点放置模块，用于根据所设计的目标数据产生的位置，结合直播节点放置数据采集点。

根据本发明的一方面，提出一种电子设备，该电子设备包括：一个或多个处理器；存储装置，用于存储一个或多个程序；当一个或多个程序被一个或多个处理器执行，使得一个或多个处理器实现如上文的方法。

根据本发明的一方面，提出一种计算机可读介质，其上存储有计算机程序，其特征在于，程序被处理器执行时实现如上文中的方法。

本公开的上述技术方案的有益效果如下：

本发明实施例基于数据上报的视频直播卡顿监测，提出了一种可定制的视频卡顿监测方案，App在直播中获取到直播过程中每个关键状态的数据，通过埋点上报的方式，把数据传输到服务器，服务器接收到数据并且经过统计分析，将数据整合输出首播时间、首播时长分布、异常比例、卡顿时间占比、卡顿用户分布、卡顿时间和次数等关键数据，结合数据可以快速定位卡顿原因，高效解决直播卡顿问题。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性的，并不能限制本公开。

附图说明

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

图1为根据本公开实施例的监测视频直播卡顿的方法的应用场景的示意图；

图2为根据本公开一实施例的监测视频直播卡顿的方法的流程图；

图3为根据本公开一实施例的监测视频直播卡顿的装置的框图；

图4为根据本公开实施例的用户平均首播时间的曲线图；

图5为根据本公开实施例的用户首播时长分布的曲线图；以及

图6为根据本公开实施例的平均每次播放有感知卡顿次数的曲线图。

具体实施例

为使本公开要解决的技术问题、技术方案和优点更加清楚，下面将结合附图及具体实施例进行详细描述。

在下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本公开相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本公开的一些方面相一致的装置和方法的例子。

图1为根据本公开实施例的监测视频直播卡顿的方法的应用场景的示意图。如图1所示，直播者可以通过摄像机100来拍摄直播视频，并经由网络(例如，因特网)将所拍摄的视频实时地发送给服务器110。服务器110在接收到视频后，对视频进行处理和存储，然后经由网络发布处理后的视频。之后，用户终端(例如手机120、计算机130等)可以经由网络从服务器110接收视频流，从而能够进入直播间观看视频直播。

下面对本公开提供的一种监测视频直播卡顿的方法进行介绍。

图2为根据本公开实施例的监测视频直播卡顿的方法的流程图。如图2所示，根据本公开实施例的监测视频直播卡顿的方法可以包括以下步骤。

在步骤S10中，在具有直播功能的应用程序App中建立模型以设计需要采集的目标数据。

该App可以为任何带有直播功能的App，例如“京东”App。

在应用程序App中建立模型可以包括：在App启动前，基于历史视频直播卡顿的原因在App中建立模型。具体地说，在App启动直播之前，可以对有可能造成直播卡顿的因素做出分析，和/或对之前App直播时曾经出现过直播卡顿的因素进行分析，然后定制出所需采集的数据类型(即，目标数据)。这样使得所采集的目标数据更有针对性，基于通过这种方式采集的目标数据所计算的直播卡顿的因素更为准确有效。

这里，需要根据可能产生卡顿的原因来建立模型，设计好需要采集的目标数据。例如，目标数据可以包括首播时间、首播时长分布、异常比例、卡顿时间占比、卡顿用户分布、卡顿时间和次数、以及单次卡顿时间中的至少一个。其中，首播时间是指从点击播放直播视频到直播视频真正开始播放的时间，即直播视频缓冲时间；首播时长分布是指首播时长在几秒内一共发生的次数的分布情况；异常比例是指直播中出现异常的情况占所有直播情况的比例；卡顿时间占比是指直播过程中出现卡顿的时间占整个直播时间的比例；卡顿用户分布是指出现直播卡顿的用户的分布情况；卡顿时间和次数是指出现直播卡顿的时间以及次数；单次卡顿时间是指一次出现直播卡顿的时间。

例如，在目标数据为首播时间的情况下，因为首播时间＝结束时间-开始时间，故需要获得初始化直播播放器时的开始时间和初始化结束时的结束时间，依据这个数据可以分析出播放器初始化所用的平均时间，从用户感知上来说，即从用户进入直播间到接收到直播信号之间持续的时间。

再例如，在目标数据为卡顿次数的情况下，由于卡顿次数＝缓冲次数，即，在视频直播期间视频进行缓冲即意味着视频出现了卡顿，故需要获得直播播放器在直播期间进行缓冲的次数。

再例如，在目标数据为单次卡顿时间时，由于单次卡顿时间＝单次缓冲时间，即，视频直播单次进行缓冲的时间为这一次的卡顿时间，故需要获得直播播放器在直播期间某一次缓冲的时间。

再例如，在目标数据为卡顿时间时，由于卡顿时间＝缓冲时间*缓冲次数，故需要获得直播播放器在直播期间的缓冲时间以及缓冲的次数。

上述的目标数据仅是为了示例目的，而非用于限制本公开的范围。本领域的技术人员可以在本公开的基础上，根据具体的需求，设计出不同的目标数据。例如，目标数据还可以包括：客户端使用的网络类型、客户端的机型、客户端的位置等等。

在步骤S20中，设计目标数据产生的位置。

根据步骤S10中设计的需要采集的目标数据，进一步设计该目标数据产生的位置。

在步骤S30中，根据所设计的目标数据产生的位置，结合直播节点放置数据采集点。

也就是说，依据数据设计阶段输出的直播节点数据，设计每个数据产生的位置，并结合直播节点放置数据采集点。

比如，在目标数据为首播时间的情况下，根据首播时间＝结束时间-开始时间，需要在直播播放器初始化开始和结束的时候分别放置数据采集点，这样在直播开始时，记录下开始时间和结束时间，然后等待上传到服务器。

再比如，根据卡顿次数＝缓冲次数，App需要采集缓冲次数，这结合播放器的状态回调。App监测其播放器在播放过程中的缓冲开始和缓冲结束，当缓冲开始时，缓冲次数加1，等到缓冲结束后再一次新的缓冲开始时缓冲次数再加1，这样不断重复，最终可以得到缓冲次数，然后等待将数据上传给服务器。

根据目标数据，在直播的各个状态点上放置数据采集点，然后采集数据。当前的目标数据可以为首播时间、首播时长分布、异常比例、卡顿时间占比、卡顿用户分布、卡顿时间和次数、单次卡顿时间等。采集点可以分布在直播中的各个状态中(即，各个直播节点)，比如播放器初始化结束的状态、获取到第一帧图片的状态、开始缓冲的状态、结束缓冲的状态、直播开始的状态、直播结束的状态等。

根据本公开的实施例，可定制视频卡顿监测方案，从而App在直播中可以获取到直播过程中每个关键状态的数据，由此可以有针对性、高效地且准确地获得直播卡顿的原因，进而解决直播卡顿。

在一个实施例中，在App进入直播后，在数据采集点采集数据，并将所采集的数据上报给服务器，从而监测视频直播卡顿。App进入直播后在对应的采集点采集数据。此功能是App在前台运行直播时完成。

将所采集的数据上报给服务器包括：通过数据埋点上传方式将所采集的数据上报给服务器。数据埋点上传方式包括批量数据埋点上传方式。

本公开中使用的数据上报技术是埋点上报技术，即，将本地App采集的数据准确、高效地上报到服务器。应用埋点上报技术为视频直播卡顿监测创造了条件。在一个实施例中，不实时按条上报数据，因为这样需要一直发起上报数据请求，能耗较高，而是累计一定数量的数据或者在切换到后台再切回App的过程中发起传输数据请求，尽可能节省资源使用。

使用按需批量上传数据可以保证在尽量少的上传次数的前提下上传全部数据，减少过多的上传请求，达到尽可能节省资源的目的。

对于数据埋点上传，可以有不同的埋点上传方式，即根据具体业务或者功能在最优化性能和不影响用户的情况下上传数据都可以完成本公开中所涉及的功能。

在一个实施例中，按需批量上报包括：预先设置上传数据量阈值，当在本地(即，客户端)采集的数据达到预设的上传数据量阈值时，统一将采集的数据上传给服务器。

在另一个实施例中，按需批量上报包括：用户在前台的时候采集到一部分数据，此时用户切换到后台，然后在用户再次切回前台的时候上报数据给服务器。

这样避免了根据数据采集按条上传数据，减少了客户端请求服务器的次数，同时数据能够准确、完整地传输到服务器。

在本公开的一个实施例中，服务器分析上报的数据，并据此显示监测数据表。监测数据表包括平均首播时间图、首播时长分布图、平均每次播放有感知卡顿次数图中的至少一个。

具体地说，服务器对已接收到的数据进行整合汇总，根据采集的数据分析出直播卡顿状态，输出包括首播时间、首播时长分布、异常比例、卡顿时间占比、卡顿用户分布、卡顿时间和次数、单次卡顿时间等关键数据，并进行列表比较，使得卡顿数据分析可视化。

服务器依据需求的目标数据，根据所有客户端采集到的数据进行汇总、分析、列表，最后输出监测数据表，通过对比该数据表，可以快速定位卡顿发生的位置，从而解决引起卡顿的问题。

该数据监测图例如如图4、图5、图6所示。图4为根据本公开实施例的用户平均首播时间的曲线图。图5为根据本公开实施例的用户首播时长分布的曲线图。图6为根据本公开实施例的平均每次播放有感知卡顿次数的曲线图。

如图4所示，其示出了用户平均首播时间在不同时间点的变化曲线，其中横轴t表示具体的时间，纵轴p表示平均首播时间。在2016年12月13日的不同时间点，用户平均首播时间不同，例如，在2016年12月13日00点，用户平均首播时间大约为1400ms。

如图5所示，其示出了首播时长分布的曲线，其中横坐标t表示时间，纵坐标n表示首播时长在几秒内一共发生的次数。例如，在2016年12月13日00点，小于1秒的首播时长发生了400次，大于1秒小于2秒的首播时长发生了200次。

如图6所示，其示出了平均每次播放有感知卡顿的次数在不同时间点的变化曲线，其中横轴t表示时间，纵轴n表示卡顿的次数。例如，在2016年12月13日00点，平均每次播放有感知卡顿的次数为0.008次。

下面将以目标数据为直播时间为例，描述监测视频直播卡顿的方法。

首先，在App中建立模型以设计直播时间为目标数据。

其次，由于该直播时间产生的位置为直播播放器初始化开始的节点和结束的节点，所以在直播播放器初始化开始的节点和结束的节点处分别放置数据采集点。

之后，在App进入直播后，App会在直播播放器初始化开始的节点和结束的节点处的数据采集点采集数据，并将所采集的数据上报给服务器。

然后，服务器对接收的数据进行分析，并以可视化的方式显示分析结果。

本公开的基于数据上报的视频卡顿监控是一种客户端通过采集直播节点状态数据，从而实时监控用户在直播间卡顿状态的一种技术。当用户进入直播观看直播时，会采集当前直播间状态节点数据，通过埋点上传技术上传到服务器，进而统计分析出包括用户首播时间、首播时长分布、异常比例、卡顿时间占比、卡顿用户分布、卡顿时间和次数等关键数据，依此来分析直播卡顿产生的原因并且快速定位问题所在，高效的解决卡顿问题。

例如，当用户进入直播间到正常加载直播流观看直播过程中，App会采集进入直播间时间点和播放刚开始时间点，对比得到用户首播时间，据此可以分析到播放器初始化耗时，类似这样的关键点遍布整个直播过程中，从而快速定位故障产生点。从技术上，基于数据上报的视频卡顿监控只需要在App正常直播的状态下采集数据上报服务器，并没有额外消耗资源，有很好的能耗性。从效果分析来看，采集到的详细数据能更好的分析定位直播状态，可以更有效率的发现或者预判故障产生点，从而使解决问题更加有效。

由于如上所述本公开有目的性地定制监测数据并使数据可视化，所以能够高效且有针对性地监测直播卡顿，快速定位卡顿点，为优化直播质量提供强有力的支撑。

此外，由于本公开可以持续且较为实时地监控直播间每个节点的异常状态，所以为将来直播优化方案提供了数据基础。

而且，本公开为解决突发异常提供了可视化数据，当突发直播异常时，能马上监测到，然后立刻采取措施解决问题，最小化突发情况带来的不可控性。

本发明结合了数据埋点上传和数据采集技术，实现了一种可在直播间精准监测卡顿的方案，增加了获取直播卡顿的实时性、准确性以及全面性，同时提供服务的过程不会干扰用户。需要说明的是，本发明所涉及的技术以及针对本方案进行的改造，都属于本发明的保护范围。

如图3所示，本公开的实施例还提供了一种监测视频直播卡顿的装置，包括：目标数据设计模块601用于在具有直播功能的应用程序App中建立模型以设计需要采集的目标数据；位置设计模块602用于设计所述目标数据产生的位置；以及采集点放置模块603用于根据所设计的目标数据产生的位置，结合直播节点放置数据采集点。

需要说明的是，该装置是应用了上述监测视频直播卡顿的方法的装置，上述监测视频直播卡顿的方法的实施例的实现方式适用于该装置，也能达到相同的技术效果。

本公开实施例还提供了一种终端，包括如上所述的监测视频直播卡顿的装置。

需要说明的是，该终端是应用了上述监测视频直播卡顿的方法的终端，上述监测视频直播卡顿的方法的实施例的实现方式适用于该终端，也能达到相同的技术效果。

进一步需要说明的是，此说明书中所描述的许多功能部件都被称为模块，以便更加特别地强调其实现方式的独立性。

本公开实施例中，模块可以用软件实现，以便由各种类型的处理器执行。举例来说，一个标识的可执行代码模块可以包括计算机指令的一个或多个物理或者逻辑块，举例来说，其可以被构建为对象、过程或函数。尽管如此，所标识模块的可执行代码无需物理地位于一起，而是可以包括存储在不同位置上的不同的指令，当这些指令逻辑上结合在一起时，其构成模块并且实现该模块的规定目的。

实际上，可执行代码模块可以是单条指令或者是许多条指令，并且甚至可以分布在多个不同的代码段上，分布在不同程序当中，以及跨越多个存储器设备分布。同样地，操作数据可以在模块内被识别，并且可以依照任何适当的形式实现并且被组织在任何适当类型的数据结构内。所述操作数据可以作为单个数据集被收集，或者可以分布在不同位置上(包括在不同存储设备上)，并且至少部分地可以仅作为电子信号存在于系统或网络上。

在模块可以利用软件实现时，考虑到现有硬件工艺的水平，所以可以以软件实现的模块，在不考虑成本的情况下，本领域技术人员都可以搭建对应的硬件电路来实现对应的功能，所述硬件电路包括常规的超大规模集成(VLSI)电路或者门阵列以及诸如逻辑芯片、晶体管之类的现有半导体或者是其它分立的元件。模块还可以用可编程硬件设备，诸如现场可编程门阵列、可编程阵列逻辑、可编程逻辑设备等实现。

上述范例性实施例是参考该些附图来描述的，许多不同的形式和实施例是可行而不偏离本公开精神及教示，因此，本公开不应被建构成为在此所提出范例性实施例的限制。更确切地说，这些范例性实施例被提供以使得本公开会是完善又完整，且会将本公开范围传达给那些熟知此项技术的人士。在该些图式中，组件尺寸及相对尺寸也许基于清晰起见而被夸大。在此所使用的术语只是基于描述特定范例性实施例目的，并无意成为限制用。如在此所使用地，除非该内文清楚地另有所指，否则该单数形式“一”、“一个”和“该”是意欲将该些多个形式也纳入。会进一步了解到该些术语“包含”及/或“包括”在使用于本说明书时，表示所述特征、整数、步骤、操作、构件及/或组件的存在，但不排除一或更多其它特征、整数、步骤、操作、构件、组件及/或其族群的存在或增加。除非另有所示，陈述时，一值范围包含该范围的上下限及其间的任何子范围。

以上所述是本公开的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本公开所述原理的前提下，还可以作出若干改进和润饰，这些改进和润饰也应视为本公开的保护范围。

工业实用性

本公开适用于视频直播领域，用以快速定位卡顿原因，从而高效解决直播卡顿问题。

Claims (9)

1.一种监测视频直播卡顿的方法，应用于终端，包括：

在具有直播功能的应用程序App中建立模型以设计需要采集的目标数据；

设计所述目标数据产生的位置；以及

根据所设计的目标数据产生的位置，结合直播节点放置数据采集点，所述直播节点为直播的状态点；

其中，所述在具有直播功能的应用程序App中建立模型包括：在App启动前，基于历史视频直播卡顿的原因在App中建立模型；

所述方法还包括：

在App进入直播后，在所述数据采集点采集数据，并将所采集的数据上报给服务器，从而监测视频直播卡顿。

2.根据权利要求1所述的监测视频直播卡顿的方法，其中，所述目标数据包括首播时间、首播时长分布、异常比例、卡顿时间占比、卡顿用户分布、卡顿时间和次数、以及单次卡顿时间中的至少一个。

3.根据权利要求1所述的监测视频直播卡顿的方法，其中，所述将所采集的数据上报给服务器包括：通过数据埋点上传方式将所采集的数据上报给所述服务器。

4.根据权利要求3所述的监测视频直播卡顿的方法，其中，所述数据埋点上传方式包括批量数据埋点上传方式。

5.根据权利要求1所述的监测视频直播卡顿的方法，其中，所述服务器分析上报的数据，并据此显示监测数据表。

6.根据权利要求5所述的监测视频直播卡顿的方法，其中，所述监测数据表包括平均首播时间图、首播时长分布图、平均每次播放有感知卡顿次数图中的至少一个。

7.一种监测视频直播卡顿的装置，应用于终端，包括：

目标数据设计模块，用于在具有直播功能的应用程序App中建立模型以设计需要采集的目标数据；

位置设计模块，用于设计所述目标数据产生的位置；以及

采集点放置模块，用于根据所设计的目标数据产生的位置，结合直播节点放置数据采集点所述直播节点为直播的状态点；

其中，所述在具有直播功能的应用程序App中建立模型包括：在App启动前，基于历史视频直播卡顿的原因在App中建立模型；

所述装置还用于：

在App进入直播后，在所述数据采集点采集数据，并将所采集的数据上报给服务器，从而监测视频直播卡顿。

8.一种电子设备，其特征在于，包括：

一个或多个处理器；

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

当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现如权利要求1-6中任一所述的方法。

9.一种计算机可读介质，其上存储有计算机程序，其特征在于，所述程序被处理器执行时实现如权利要求1-6中任一所述的方法。

Images