CN111601102A - 一种直播卡顿的检测方法及系统 - Google Patents

Abstract

本发明实施例提供一种直播卡顿的检测方法及系统，包括：实时检测并获取在直播卡顿时主播客户端与该直播的相关数据；通过分析主播客户端与该直播的相关数据得到该直播在主播客户端的卡顿原因，根据卡顿原因形成主播客户端卡顿的解决方案；将该解决方案发送给主播客户端。实时分析主播客户端与该直播的相关数据精确定位卡顿原因，极大的缩短了卡顿检测时长。

Description

一种直播卡顿的检测方法及系统

技术领域

本发明涉及在线视频直播终端指标采集技术，具体涉及一种直播卡顿的检测方法及系统。

背景技术

2016年被称为直播元年，各类移动直播平台如雨后春笋冒出，不断满足人们对强交互、高实时性的新媒体载体的要求。整个直播的过程，可简单描述为：主播端生成直播的音视频流，通过网络，将流数据包发送到服务器，同时观众端从服务器上拉取直播流，观看直播。在观众观看直播的过程中，有时会出现声音或画面的滞帧现象，俗称卡顿。在实现本发明过程中，申请人发现现有技术中至少存在如下问题：

通过，直播中的卡顿问题，一般都由用户首先发现，通过APP上的卡顿反馈功能向直播平台反馈，直播平台的管理人员发现卡顿问题会存在一定的滞后性。

在发现直播卡顿后，平台人员需要在直播平台获取第三方内容分发网络CDN流地址，协调第三方人员人工查询流情况，确定流卡顿后，由于不清楚用户端设备和网络状况，因此无法快速具体定位卡顿的原因，也就无法及时解决卡顿的问题，并且在定位出卡顿原因之后，也没有一个快速的通道将卡顿解决方案同步给主播或观众。导致直播平台的用户体验严重下降。

发明内容

本发明实施例提供一种直播卡顿的检测方法及系统，实时分析主播客户端与该直播的相关数据、用户客户端与该直播的相关数据，精确定位卡顿原因，给主播或观众提供改善直播状态的解决方案，极大的缩短了卡顿检测时长。

为达上述目的，一方面，本发明实施例提供一种直播卡顿的检测方法，应用在主播客户端，包括：

实时检测并获取在直播卡顿时主播客户端与该直播的相关数据；

通过分析主播客户端与该直播的相关数据得到该直播在主播客户端的卡顿原因，根据卡顿原因形成主播客户端卡顿的解决方案；

将该解决方案发送给主播客户端。

另一方面，本发明实施例还提供一种直播卡顿的检测方法，应用在用户客户端，包括：

实时检测并获取在直播卡顿时用户客户端与该直播的相关数据；

通过分析用户客户端与该直播的相关数据得到该直播在用户客户端的卡顿原因，根据卡顿原因形成用户客户端卡顿的解决方案；

将该解决方案返回给用户客户端。

以及，本发明实施例还提供一种直播卡顿的检测系统，应用在主播客户端，包括；

第一数据获取单元，用于实时检测并获取在直播卡顿时主播客户端与该直播的相关数据；

第一处理单元，用于通过分析主播客户端与该直播的相关数据得到该直播在主播客户端的卡顿原因，根据卡顿原因形成主播客户端卡顿的解决方案；

第一方案发送单元：用于将该解决方案发送给主播客户端。

以及，本发明实施例还提供一种直播卡顿的检测系统，应用在用户客户端，包括：

第二数据获取单元，用于实时检测并获取在直播卡顿时用户客户端与该直播的相关数据；

第二处理单元，用于通过分析用户客户端与该直播的相关数据得到该直播在用户客户端的卡顿原因，根据卡顿原因形成用户客户端卡顿的解决方案；

第二方案发送单元，用于将该解决方案返回给用户客户端。

上述技术方案具有如下有益效果：实时分析推流或拉流情况，精确定位卡顿原因，给主播提供改善直播状态的提议，极大的缩短了卡顿检测时长，提高了卡顿检测效率，提升了直播平台的用户体验。

附图说明

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

图1是本发明实施例应用在直播客户端的直播卡顿的检测方法的流程图；

图2是本发明实施例应用在用户客户端的直播卡顿的检测方法的流程图；

图3是本发明实施例应用在直播客户端的直播卡顿的检测系统的结构图；

图4是本发明实施例应用在用户客户端的直播卡顿的检测系统的结构图；

图5是直播节目的直播流程；

图6是本发明实施例的直播的日志收集系统框架图。

具体实施方式

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

如图1所示，结合本发明的实施例，一种直播卡顿的检测方法，应用在主播客户端，包括：

S101：实时检测并获取在直播卡顿时主播客户端与该直播的相关数据；

S102：通过分析主播客户端与该直播的相关数据得到该直播在主播客户端的卡顿原因，根据卡顿原因形成主播客户端卡顿的解决方案；

S103：将该解决方案发送给主播客户端。

优选地，所述主播客户端与该直播的相关数据，具体包括：

在预设时间段内，该直播各制作步骤的执行帧率，以及，由前一制作步骤向后一制作步骤的发送帧率；

所述步骤102具体包括：

S1021：该直播各制作步骤中，如果至少一个制作步骤在连续N秒内执行帧率小于设定的第一帧率阈值，则判定该直播在主播客户端的卡顿原因是由主播客户端所用设备的性能不满足相应制作步骤的需求造成；

S1022：分析获取到的主播客户端所用设备的性能数据，得到主播客户端所用设备不满足相应制作步骤需求的性能类型，并针对该性能类型形成主播客户端卡顿的解决方案；

和/或，

S1023：如果至少一个发送帧率在连续M秒内小于设定的第二帧率阈值，则判定该直播在主播客户端的卡顿原因是由主播客户端所用网络阻塞造成；

S1024：分析获取的主播客户端所用的网络数据，得到网络阻塞的具体原因，并根据网络阻塞的具体原因形成主播客户端卡顿的解决方案。

优选地，还包括：

S104：实时检测并获取用户客户端关于该直播提供的卡顿原因排名，以及排名前K位的卡顿原因所对应的评论内容；

S105：当通过分析得到的该直播在主播客户端的卡顿原因与排名前K位的卡顿原因均不符时，核对获取到的主播客户端与该直播的相关数据是否正确；

S106：根据核对结果修正主播客户端与该直播的相关数据。

优选地，还包括：

S107：实时检测并获取在直播卡顿时用户客户端与该直播的相关数据；

S108：通过分析用户客户端与该直播的相关数据得到该直播在用户客户端的卡顿原因，根据卡顿原因形成用户客户端卡顿的解决方案；

S109：将该解决方案返回给用户客户端。

如图2所示，结合本发明的实施例，还提供一种直播卡顿的检测方法，应用在用户客户端，包括：

S201：实时检测并获取在直播卡顿时用户客户端与该直播的相关数据；

S202：通过分析用户客户端与该直播的相关数据得到该直播在用户客户端的卡顿原因，根据卡顿原因形成用户客户端卡顿的解决方案；

S203：将该解决方案返回给用户客户端。

优选地，所述用户客户端与该直播的相关数据，具体包括：

在预设时间段内，用户客户端获取该直播数据流的各阶段缓冲区内是否有数据；其中，获取该直播数据流的各阶段包括：对直播数据流的拉取、解码和渲染；

所述步骤202包括：

S2021：当直播数据流的拉取缓冲区无数据时，则判定该直播在用户客户端的卡顿原因是由用户客户端所用网络阻塞造成；

S2022：分析获取到的用户客户端所用的网络数据，得到网络阻塞的具体原因，并根据网络阻塞的具体原因形成用户客户端卡顿的解决方案；

和/或，

S2023：当直播数据流的解码缓冲区和/或渲染缓冲区无数据时，则判定该直播在用户客户端的卡顿原因是由用户客户端所用设备的性能不满足直播数据流的解码和/或渲染需求造成；

S2024：分析获取到的用户客户端所用设备的性能数据，得到用户客户端所用设备不满足直播数据流的解码和/或渲染需求的性能类型，并根据性能类型形成用户客户端卡顿的解决方案。

优选地，还包括：

S204：实时检测并获取用户客户端关于该直播提供的卡顿原因排名，以及排名前K位卡顿原因所对应的评论内容；

S205：当通过分析得到的该直播在用户客户端的卡顿原因与排名前K位的卡顿原因均不符时，核对获取到的用户客户端与该直播的相关数据是否正确；

S206：根据核对结果修正用户客户端与该直播的相关数据。

如图3所示，结合本发明的实施例，提供一种直播卡顿的检测系统，应用在主播客户端，包括：

第一数据获取单元11，用于实时检测并获取在直播卡顿时主播客户端与该直播的相关数据；

第一处理单元12，用于通过分析主播客户端与该直播的相关数据得到该直播在主播客户端的卡顿原因，根据卡顿原因形成主播客户端卡顿的解决方案；

第一方案发送单元13：用于将该解决方案发送给主播客户端。

优选地，所述主播客户端与该直播的相关数据，具体包括：

在预设时间段内，该直播各制作步骤的执行帧率，以及，由前一制作步骤向后一制作步骤的发送帧率；

所述第一处理单元12包括：

第一确认子单元121，用于该直播各制作步骤中，如果至少一个制作步骤在连续N秒内执行帧率小于设定的第一帧率阈值，则判定该直播在主播客户端的卡顿原因是由主播客户端所用设备的性能不满足相应制作步骤的需求造成；

第一分析子单元122，用于分析获取到的主播客户端所用设备的性能数据，得到主播客户端所用设备不满足相应制作步骤需求的性能类型，并针对该性能类型形成主播客户端卡顿的解决方案；

和/或，

第二确认子单元123，用于如果至少一个发送帧率在连续M秒内小于设定的第二帧率阈值，则判定该直播在主播客户端的卡顿原因是由主播客户端所用网络阻塞造成；

第二分析子单元124，用于分析获取的主播客户端所用的网络数据，得到网络阻塞的具体原因，并根据网络阻塞的具体原因形成主播客户端卡顿的解决方案。

优选地，还包括：

第一评论获取单元14，用于实时检测并获取用户客户端关于该直播提供的卡顿原因排名，以及排名前K位的卡顿原因所对应的评论内容；

第一修正单元15，用于当通过分析得到的该直播在主播客户端的卡顿原因与排名前K位的卡顿原因均不符时，核对获取到的主播客户端与该直播的相关数据是否正确；

第一修正方案发送单元16，用于根据核对结果修正主播客户端与该直播的相关数据。

如图4所示，结合本发明的实施例，还一种直播卡顿的检测系统，应用在用户客户端，，包括：

第二数据获取单元21，用于实时检测并获取在直播卡顿时用户客户端与该直播的相关数据；

第二处理单元22，用于通过分析用户客户端与该直播的相关数据得到该直播在用户客户端的卡顿原因，根据卡顿原因形成用户客户端卡顿的解决方案；

第二方案发送单元23，用于将该解决方案返回给用户客户端。

优选地，所述用户客户端与该直播的相关数据，具体包括：

在预设时间段内，用户客户端获取该直播数据流的各阶段缓冲区内是否有数据；其中，获取该直播数据流的各阶段包括：对直播数据流的拉取、解码和渲染；

所述第二处理单元22包括：

第三确认子单元221，用于当直播数据流的拉取缓冲区无数据时，则判定该直播在用户客户端的卡顿原因是由用户客户端所用网络阻塞造成；

第三分析子单元221，用于分析获取到的用户客户端所用的网络数据，得到网络阻塞的具体原因，并根据网络阻塞的具体原因形成用户客户端卡顿的解决方案；

和/或，

第四确认子单元223，用于当直播数据流的解码缓冲区和/或渲染缓冲区无数据时，则判定该直播在用户客户端的卡顿原因是由用户客户端所用设备的性能不满足直播数据流的解码和/或渲染需求造成；

第四分析子单元224，用于分析获取到的用户客户端所用设备的性能数据，得到用户客户端所用设备不满足直播数据流的解码和/或渲染需求的性能类型，并根据性能类型形成用户客户端卡顿的解决方案。

优选地，还包括：

第二评论获取单元24，用于实时检测并获取用户客户端关于该直播提供的卡顿原因排名，以及排名前K位卡顿原因所对应的评论内容；

第二修正单元25，用于当通过分析得到的该直播在用户客户端的卡顿原因与排名前K位的卡顿原因均不符时，核对获取到的用户客户端与该直播的相关数据是否正确；

第二修正方案发送单元26，用于根据核对结果修正用户客户端与该直播的相关数据。

本发明实施例所取得的有益效果为：

与原有的直播卡顿检测方法相比，本发明提供给直播平台管理人员一个系统的检测方法，通过将直播客户端或者用户客户端所在设备性能数据、网络情况、客户端流媒体数据、即时评论系统数据结合，从数据分析和用户感官体验两个维度，实时分析推流、拉流情况，精确定位直播卡顿原因，给主播或者用户提供改善直播状态的提议，极大的缩短了卡顿检测时长，提高了卡顿检测效率，提升了直播平台的用户体验。

下面结合具体的应用实例对本发明实施例上述技术方案进行详细说明，实施过程中没有介绍到的技术细节，可以参考前文的相关描述。

一种直播流卡顿检测、原因分析展示及自动化反馈，具体涉及对流媒体数据上报，流数据分析。

本发明旨在通过客户端埋点上报流媒体数据，服务端建立收点网关(如图6所示，日志收集，日志处理，日志存储三个部分统称为收点网关)，搭建实时数据分析服务，结合即时评论系统从数据分析和用户感官两个维度实现直播卡顿自动检测，卡顿原因及直播流数据情况的可视化展示，提供给直播平台的管理员一个系统的途径用于卡顿原因定位，并能在定位出卡顿原因之后自动将解决方案通知到终端用户，引导用户解决卡顿问题，提高直播平台的用户体验。其中，上报的流媒体数据包括来自主播客户端端、观众端(用户直播端)或者直播视频流。对于每个来源还会包括多个具体的因素，例如：主播端设备的性能、主播端网络质量、观众端设备性能、观众端网络质量、直播视频流的编解码方案等。

结合图5所示的直播节目的直播流程，参考图6，本发明包括以下步骤：

步骤1：客户端直播流卡顿检测及原因定位

卡顿的原因有如下几点：

1)推流帧率太低：如果主播端设备性能较差，或者开播时CPU利用率很高，可能导致生成的视频流帧率过低。正常情况下帧率FPS达到10帧/秒以上的视频流才能保证观看的流畅度，如果画帧率FPS低于10帧/秒，可以判定为帧率过低，这会导致所有观众端看到的直播都是卡顿的。

2)上传阻塞：主播端设备在推流时会源源不断地产生音视频数据包，但如果上传网速太低，那么产生的音视频数据包都会被堆积在主播端传不出去，上传阻塞会导致全部观众端都感觉卡顿。

3)下行不佳：观众的下载带宽不足或者存在网络波动，例如直播流的码率是2Mbps的，也就是每秒钟有2Mbit的数据流要下载下来，但如果观众端的带宽不够，就会导致观众端感觉卡顿，下行不佳只会影响当前网络环境下的观众。

直播卡顿检测及原因定位：

1)推流(需要经历四个阶段：采集、美颜、编码、发送)阶段的卡顿检测：

客户端程序统计采集、美颜、编码过程中的帧率数据，每个阶段自身操作过程中，如果连续3s内有任何一个帧率小于10帧/秒，则认为存在卡顿。

卡顿原因为主播端设备性能，需要分析终端设备的CPU使用率(已使用CPU>80％则判定为设备性能不足)、设备电量(设备电量小于20或者处于低电量模式，则判定为电量不足)、电池温度(电池温度大于60就认为设备温度过高)等指标来定位卡顿原因。

客户端程序统计推流过程中由上一阶段向下一阶段的发送帧率，如果连续3s内发送帧率都小于10帧/秒，则认为直播存在卡顿，卡顿原因为网络上行阻塞。

2)拉流(需要经历三个阶段：数据拉取、解码、渲染)阶段的卡顿检测：

目前，通常采用判断某个阶段中的帧数是否为空，为空就是卡顿，不为空就是不卡顿。

客户端程序监控数据拉取缓冲区数据，如为空，则认为直播存在卡顿，卡顿原因为直播流下行不佳；。

客户端程序分别监控解码缓冲区和渲染缓冲区数据，如为空，则认为直播存在卡顿，按照拉流过程的顺序由解码到渲染，可只看拉取缓冲区是否为空，为空则认为直播卡顿，不空则认为直播不卡顿。此种情况下，卡顿的原因为观众端设备性能不能满足要求，需要检测终端设备CPU使用率(已使用CPU>80％则判定为设备性能不足)、设备电量(设备电量小于20或者处于低电量模式，则判定为电量不足)、电池温度(电池温度大于60就认为设备温度过高)等指标来定位卡顿原因。

也就是同一个直播间，推流主播端会做推流卡顿判断，拉流观看端会做拉流卡顿判断。

步骤2:客户端日志采集

客户端日志采集整体架构如图6所示，日志生产及上报规则如下：

1)推流数据、拉流数据、设备性能数据、上行网络数据、下行网络数据：主播客户端和用户客户端每2s采集一次数据缓存在各自设备中，每5分钟调用主播客户端和用户客户端各自的Restful API应用程序接口将数据上报给服务端。即：RESTFUL是一种网络应用程序的设计风格和开发方式，基于HTTP，客户端通过HTTP接口上报数据到服务端，服务端将上述数据写入kafka缓存队列，再由logstash解析日志、并将数据格式化后存储到ES集群。其中，网络数据主播和用户各使用的是什么网络，如果是4G网络，网络数据则包括4G网络的提供商数据。

2)卡顿相关数据：当客户端判定推流或者拉流卡顿时，则会实时调用Restful API上报数据。

步骤3：卡顿自动化反馈

服务端(直播的服务端)汇总了由客户端收集到的各项数据，进行分析，确定卡顿问题原因。根据卡顿原因，将对应的解决方案，通过长链接(长链接，指在一个连接上可以连续发送多个数据包，在连接保持期间，如果没有数据包发送，需要双方发链路检测包)的方式自动推送到主播端/观众端设备的直播界面中，以帮助用户使用对应的方案解决当前卡顿问题。

步骤4:流数据监控可视化、直播间卡顿原因查询工具化

推流卡顿数据实时监控和直播间卡顿原因查询工具化：

1)推流卡顿重点数据提取以展示：提取5分钟内的推流数据(采集、美颜、编码、发送)，按照直播间维度叠加卡顿时长，取前10个直播间数据作为推流卡顿直播间重点数据展示。目的在于展示给用户当前全平台最卡顿的直播间的都是哪些直播间，从而使数据可视化。

2)依据主播搜索直播间列表：在一直播APP，一个用户直播时，每开一次直播就是一个直播间，可以根据输入的开播主播用户id查询该用户开播过的所有直播间，即：输入主播用户id，可以查询该主播开发的所有直播间，方便定位推流卡顿问题。

3)推流卡顿直播间数据展示：

3.1直播间基本信息展示：其中包括主播信息，主播端设备系统信息，主播app版本，DNS等数据，方便客户端开发人员针对不同版本的APP和设备系统差异进行具体判断。

3.2实时卡顿状态及原因展示：获取1分钟内的直播间推流数据，以判断当前是否卡顿，判断直播间推流状态，如果发生卡顿，同时获取卡顿原因及当前设备性能数据，属于准实时监控。此部分数据为了保证实时性，每分钟刷新一次数据。

3.3卡顿记录数据展示：以直播间为单位进行展示，具体为展示直播客户端某一直播期间所有的推流上报数据，当然包括历史卡顿数据，方便查询历史某个时刻该主播的推流状态。

3.4推流数据准实时展示：获取从直播间开播到直播间结束或者到当前时间内，客户端上报的所有推流数据(视频流数据，音频流数据)，设备性能数据(电池电量、电池温度、系统CPU数据)，并按照时间轴以折线图的形式展示，以方便准确判断音视频推流数据的动态变化，设备性能状态的动态变化。

3.5当前直播间“卡”评论的折线图及详细评论数据展示：获取从直播间开播到直播间结束或者到当前时间内的所有“卡”评论的数据，并按照时间轴以折线图形式展示卡评论数据，以方便对比用户感官数据和客户端上报数据，实现数据分析和用户感官的双维度的卡顿分析。

拉流卡顿数据实时监控和直播卡顿原因工具化：

1)拉流卡顿重点数据提取以展示：提取5分钟内的用户观看直播拉流卡顿数据，按照直播间维度叠加卡顿时长，取5分钟内累计卡顿时间位于前10个的直播间数据作为观看直播拉流卡顿直播间重点数据，展示给服务端，以实现数据的可视化。

2)依据观看用户搜索直播间列表功能：输入观看直播的用户，展示该用户24小时内观看过的所有的直播间数据，包括：直播间唯一标识、主播用户id、观看用户id、观看卡顿原因，方便定位该用户观看的直播间卡顿问题。

3)拉流卡顿直播间数据展示

3.1直播间基本信息展示：其中包括主播信息，主播设备系统信息，主播app版本，DNS等数据，主播微博UID用户账号、用户微博UID，用户一直播ID等，以方便定位不同设备系统，不同app版本，不同直播间类型的观看卡顿问题。

3.2当前用户观看直播实时拉流状态信息：获取1分钟内的当前用户观看直播的拉流数据，以确认当前拉流是否卡顿，判断直播间拉流状态，如果发生卡顿，同时获取卡顿原因。此部分数据为了保证实时性，每分钟刷新一次数据。

3.3当前用户观看直播卡顿时长数据展示：获取从直播间开播到直播间结束或者到当前时间内，当前用户观看直播上报的拉流卡顿时长数据(视频卡顿时长、音频卡顿时长)，并按照时间轴以折线图的形式展示，以方便客户端开发准确判断拉流卡顿时长变化趋势。

3.4当前直播间“卡”评论的折线图及详细评论数据展示：获取从直播间开播到直播间结束或者到当前时间内的所有“卡”评论的数据，并按照时间轴以折线图形式展示卡评论数据，以方便开发者对比用户感官数据和客户端上报数据，实现数据分析和用户感官的双维度的卡顿分析。

3.5“卡”评论直播间重点数据提取以展示：针对全直播平台，拉取全平台所有开播中直播间，获取5分钟内“卡”评论条数最多的直播间的列表，并取前10个直播间作为“卡”评论直播间的重点数据。

本发明实施例所取得的有益效果如下：

与原有的直播卡顿检测方法相比，本发明提供给直播平台管理人员一个系统的检测方法，通过将直播客户端或者用户客户端所在设备性能数据、网络情况、客户端流媒体数据、即时评论系统数据结合，从数据分析和用户感官体验两个维度，实时分析推流、拉流情况，精确定位直播卡顿原因，给主播或者用户提供改善直播状态的提议，极大的缩短了卡顿检测时长，提高了卡顿检测效率，提升了直播平台的用户体验。

通过客户端数据埋点上报，服务端存储服务搭建，数据分析服务搭建，并结合即时评论系统，从数据分析和用户感官两个维度，分析推拉流情况，获取卡顿原因，给主播提供改善直播状态的提议，从而实现推拉流准实时情况和历史数据可视化，卡顿原因的精确定位，提高卡顿问题检测效率，提高直播平台用户体验。

应该明白，公开的过程中的步骤的特定顺序或层次是示例性方法的实例。基于设计偏好，应该理解，过程中的步骤的特定顺序或层次可以在不脱离本公开的保护范围的情况下得到重新安排。所附的方法权利要求以示例性的顺序给出了各种步骤的要素，并且不是要限于所述的特定顺序或层次。

在上述的详细描述中，各种特征一起组合在单个的实施方案中，以简化本公开。不应该将这种公开方法解释为反映了这样的意图，即，所要求保护的主题的实施方案需要比清楚地在每个权利要求中所陈述的特征更多的特征。相反，如所附的权利要求书所反映的那样，本发明处于比所公开的单个实施方案的全部特征少的状态。因此，所附的权利要求书特此清楚地被并入详细描述中，其中每项权利要求独自作为本发明单独的优选实施方案。

为使本领域内的任何技术人员能够实现或者使用本发明，上面对所公开实施例进行了描述。对于本领域技术人员来说；这些实施例的各种修改方式都是显而易见的，并且本文定义的一般原理也可以在不脱离本公开的精神和保护范围的基础上适用于其它实施例。因此，本公开并不限于本文给出的实施例，而是与本申请公开的原理和新颖性特征的最广范围相一致。

上文的描述包括一个或多个实施例的举例。当然，为了描述上述实施例而描述部件或方法的所有可能的结合是不可能的，但是本领域普通技术人员应该认识到，各个实施例可以做进一步的组合和排列。因此，本文中描述的实施例旨在涵盖落入所附权利要求书的保护范围内的所有这样的改变、修改和变型。此外，就说明书或权利要求书中使用的术语“包含”，该词的涵盖方式类似于术语“包括”，就如同“包括，”在权利要求中用作衔接词所解释的那样。此外，使用在权利要求书的说明书中的任何一个术语“或者”是要表示“非排它性的或者”。

本领域技术人员还可以了解到本发明实施例列出的各种说明性逻辑块(illustrative logical block)，单元，和步骤可以通过电子硬件、电脑软件，或两者的结合进行实现。为清楚展示硬件和软件的可替换性(interchangeability)，上述的各种说明性部件(illustrative components)，单元和步骤已经通用地描述了它们的功能。这样的功能是通过硬件还是软件来实现取决于特定的应用和整个系统的设计要求。本领域技术人员可以对于每种特定的应用，可以使用各种方法实现所述的功能，但这种实现不应被理解为超出本发明实施例保护的范围。

本发明实施例中所描述的各种说明性的逻辑块，或单元都可以通过通用处理器，数字信号处理器，专用集成电路(ASIC)，现场可编程门阵列或其它可编程逻辑装置，离散门或晶体管逻辑，离散硬件部件，或上述任何组合的设计来实现或操作所描述的功能。通用处理器可以为微处理器，可选地，该通用处理器也可以为任何传统的处理器、控制器、微控制器或状态机。处理器也可以通过计算装置的组合来实现，例如数字信号处理器和微处理器，多个微处理器，一个或多个微处理器联合一个数字信号处理器核，或任何其它类似的配置来实现。

本发明实施例中所描述的方法或算法的步骤可以直接嵌入硬件、处理器执行的软件模块、或者这两者的结合。软件模块可以存储于RAM存储器、闪存、ROM存储器、EPROM存储器、EEPROM存储器、寄存器、硬盘、可移动磁盘、CD-ROM或本领域中其它任意形式的存储媒介中。示例性地，存储媒介可以与处理器连接，以使得处理器可以从存储媒介中读取信息，并可以向存储媒介存写信息。可选地，存储媒介还可以集成到处理器中。处理器和存储媒介可以设置于ASIC中，ASIC可以设置于用户终端中。可选地，处理器和存储媒介也可以设置于用户终端中的不同的部件中。

在一个或多个示例性的设计中，本发明实施例所描述的上述功能可以在硬件、软件、固件或这三者的任意组合来实现。如果在软件中实现，这些功能可以存储与电脑可读的媒介上，或以一个或多个指令或代码形式传输于电脑可读的媒介上。电脑可读媒介包括电脑存储媒介和便于使得让电脑程序从一个地方转移到其它地方的通信媒介。存储媒介可以是任何通用或特殊电脑可以接入访问的可用媒体。例如，这样的电脑可读媒体可以包括但不限于RAM、ROM、EEPROM、CD-ROM或其它光盘存储、磁盘存储或其它磁性存储装置，或其它任何可以用于承载或存储以指令或数据结构和其它可被通用或特殊电脑、或通用或特殊处理器读取形式的程序代码的媒介。此外，任何连接都可以被适当地定义为电脑可读媒介，例如，如果软件是从一个网站站点、服务器或其它远程资源通过一个同轴电缆、光纤电缆、双绞线、数字用户线(DSL)或以例如红外、无线和微波等无线方式传输的也被包含在所定义的电脑可读媒介中。所述的碟片(disk)和磁盘(disc)包括压缩磁盘、镭射盘、光盘、DVD、软盘和蓝光光盘，磁盘通常以磁性复制数据，而碟片通常以激光进行光学复制数据。上述的组合也可以包含在电脑可读媒介中。

以上所述的具体实施方式，对本发明的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上所述仅为本发明的具体实施方式而已，并不用于限定本发明的保护范围，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (13)

1.一种直播卡顿的检测方法，应用在主播客户端，其特征在于，包括：

实时检测并获取在直播卡顿时主播客户端与该直播的相关数据；

通过分析主播客户端与该直播的相关数据得到该直播在主播客户端的卡顿原因，根据卡顿原因形成主播客户端卡顿的解决方案；

将该解决方案发送给主播客户端。

2.根据权利要求1所述的直播卡顿的检测方法，其特征在于，所述主播客户端与该直播的相关数据，具体包括：

在预设时间段内，该直播各制作步骤的执行帧率，以及，由前一制作步骤向后一制作步骤的发送帧率；

所述通过分析主播客户端与该直播的相关数据得到该直播在主播客户端的卡顿原因，根据卡顿原因形成主播客户端卡顿的解决方案，具体包括：

该直播各制作步骤中，如果至少一个制作步骤在连续N秒内执行帧率小于设定的第一帧率阈值，则判定该直播在主播客户端的卡顿原因是由主播客户端所用设备的性能不满足相应制作步骤的需求造成；相应的，分析获取到的主播客户端所用设备的性能数据，得到主播客户端所用设备不满足相应制作步骤需求的性能类型，并针对该性能类型形成主播客户端卡顿的解决方案；

和/或，

如果至少一个发送帧率在连续M秒内小于设定的第二帧率阈值，则判定该直播在主播客户端的卡顿原因是由主播客户端所用网络阻塞造成；相应的，分析获取的主播客户端所用的网络数据，得到网络阻塞的具体原因，并根据网络阻塞的具体原因形成主播客户端卡顿的解决方案。

3.根据权利要求1所述的直播卡顿的检测方法，其特征在于，还包括：实时检测并获取用户客户端关于该直播提供的卡顿原因排名，以及排名前K位的卡顿原因所对应的评论内容；

当通过分析得到的该直播在主播客户端的卡顿原因与排名前K位的卡顿原因均不符时，核对获取到的主播客户端与该直播的相关数据是否正确；

根据核对结果修正主播客户端与该直播的相关数据。

4.根据权利要求1所述的直播卡顿的检测方法，其特征在于，还包括：

实时检测并获取在直播卡顿时用户客户端与该直播的相关数据；

通过分析用户客户端与该直播的相关数据得到该直播在用户客户端的卡顿原因，根据卡顿原因形成用户客户端卡顿的解决方案；

将该解决方案返回给用户客户端。

5.一种直播卡顿的检测方法，应用在用户客户端，其特征在于，包括：

实时检测并获取在直播卡顿时用户客户端与该直播的相关数据；

通过分析用户客户端与该直播的相关数据得到该直播在用户客户端的卡顿原因，根据卡顿原因形成用户客户端卡顿的解决方案；

将该解决方案返回给用户客户端。

6.根据权利要求5所述的直播卡顿的检测方法，其特征在于，所述用户客户端与该直播的相关数据，具体包括：

在预设时间段内，用户客户端获取该直播数据流的各阶段缓冲区内是否有数据；其中，获取该直播数据流的各阶段包括：对直播数据流的拉取、解码和渲染；

所述通过分析用户客户端与该直播的相关数据得到该直播在用户客户端的卡顿原因，根据卡顿原因形成用户客户端卡顿的解决方案，具体包括：

当直播数据流的拉取缓冲区无数据时，则判定该直播在用户客户端的卡顿原因是由用户客户端所用网络阻塞造成；相应的，分析获取到的用户客户端所用的网络数据，得到网络阻塞的具体原因，并根据网络阻塞的具体原因形成用户客户端卡顿的解决方案；

和/或，

当直播数据流的解码缓冲区和/或渲染缓冲区无数据时，则判定该直播在用户客户端的卡顿原因是由用户客户端所用设备的性能不满足直播数据流的解码和/或渲染需求造成；相应的，分析获取到的用户客户端所用设备的性能数据，得到用户客户端所用设备不满足直播数据流的解码和/或渲染需求的性能类型，并根据性能类型形成用户客户端卡顿的解决方案。

7.根据权利要求5所述的直播卡顿的检测方法，其特征在于，还包括：实时检测并获取用户客户端关于该直播提供的卡顿原因排名，以及排名前K位卡顿原因所对应的评论内容；

当通过分析得到的该直播在用户客户端的卡顿原因与排名前K位的卡顿原因均不符时，核对获取到的用户客户端与该直播的相关数据是否正确；

根据核对结果修正用户客户端与该直播的相关数据。

8.一种直播卡顿的检测系统，应用在主播客户端，其特征在于，包括：

第一数据获取单元，用于实时检测并获取在直播卡顿时主播客户端与该直播的相关数据；

第一处理单元，用于通过分析主播客户端与该直播的相关数据得到该直播在主播客户端的卡顿原因，根据卡顿原因形成主播客户端卡顿的解决方案；

第一方案发送单元，用于将该解决方案发送给主播客户端。

9.根据权利要求8所述的直播卡顿的检测系统，其特征在于，所述主播客户端与该直播的相关数据，具体包括：

在预设时间段内，该直播各制作步骤的执行帧率，以及，由前一制作步骤向后一制作步骤的发送帧率；

所述第一处理单元包括：

第一确认子单元，用于该直播各制作步骤中，如果至少一个制作步骤在连续N秒内执行帧率小于设定的第一帧率阈值，则判定该直播在主播客户端的卡顿原因是由主播客户端所用设备的性能不满足相应制作步骤的需求造成；

第一分析子单元，用于分析获取到的主播客户端所用设备的性能数据，得到主播客户端所用设备不满足相应制作步骤需求的性能类型，并针对该性能类型形成主播客户端卡顿的解决方案；

和/或，

第二确认子单元，用于如果至少一个发送帧率在连续M秒内小于设定的第二帧率阈值，则判定该直播在主播客户端的卡顿原因是由主播客户端所用网络阻塞造成；

第二分析子单元，用于分析获取的主播客户端所用的网络数据，得到网络阻塞的具体原因，并根据网络阻塞的具体原因形成主播客户端卡顿的解决方案。

10.根据权利要求8所述的直播卡顿的检测系统，其特征在于，还包括：

第一评论获取单元，用于实时检测并获取用户客户端关于该直播提供的卡顿原因排名，以及排名前K位的卡顿原因所对应的评论内容；

第一修正单元，用于当通过分析得到的该直播在主播客户端的卡顿原因与排名前K位的卡顿原因均不符时，核对获取到的主播客户端与该直播的相关数据是否正确；

第一修正方案发送单元，用于根据核对结果修正主播客户端与该直播的相关数据。

11.一种直播卡顿的检测系统，应用在用户客户端，其特征在于，包括：

第二数据获取单元，用于实时检测并获取在直播卡顿时用户客户端与该直播的相关数据；

第二处理单元，用于通过分析用户客户端与该直播的相关数据得到该直播在用户客户端的卡顿原因，根据卡顿原因形成用户客户端卡顿的解决方案；

第二方案发送单元，用于将该解决方案返回给用户客户端。

12.根据权利要求11所述的直播卡顿的检测系统，其特征在于，所述用户客户端与该直播的相关数据，具体包括：

在预设时间段内，用户客户端获取该直播数据流的各阶段缓冲区内是否有数据；其中，获取该直播数据流的各阶段包括：对直播数据流的拉取、解码和渲染；

所述第二处理单元包括：

第三确认子单元，用于当直播数据流的拉取缓冲区无数据时，则判定该直播在用户客户端的卡顿原因是由用户客户端所用网络阻塞造成；

第三分析子单元，用于分析获取到的用户客户端所用的网络数据，得到网络阻塞的具体原因，并根据网络阻塞的具体原因形成用户客户端卡顿的解决方案；

和/或，

第四确认子单元，用于当直播数据流的解码缓冲区和/或渲染缓冲区无数据时，则判定该直播在用户客户端的卡顿原因是由用户客户端所用设备的性能不满足直播数据流的解码和/或渲染需求造成；

第四分析子单元，用于分析获取到的用户客户端所用设备的性能数据，得到用户客户端所用设备不满足直播数据流的解码和/或渲染需求的性能类型，并根据性能类型形成用户客户端卡顿的解决方案。

13.根据权利要求11所述的直播卡顿的检测系统，其特征在于，还包括：

第二评论获取单元，用于实时检测并获取用户客户端关于该直播提供的卡顿原因排名，以及排名前K位卡顿原因所对应的评论内容；

第二修正单元，用于当通过分析得到的该直播在用户客户端的卡顿原因与排名前K位的卡顿原因均不符时，核对获取到的用户客户端与该直播的相关数据是否正确；

第二修正方案发送单元，用于根据核对结果修正用户客户端与该直播的相关数据。

Images