网络直播卡顿的处理方法及装置与流程

本发明涉及多媒体通信测试技术领域，尤其涉及一种网络直播卡顿的处理方法及装置。

背景技术：

随着以PC为主导的固定互联网和以智能手机为主导的移动互联网的快速发展，基于OTT视频技术的互联网电视、移动视频和多屏互动业务正以惊人速度发展。OTT是“Over The Top”的缩写，其意指在网络之上提供服务，强调服务与物理网络的无关性。OTT视频是指基于HTTP协议和开放互联网的视频服务，其终端可以是智能电视机、电脑、机顶盒、PAD、智能手机等。OTT视频主要有两种实现方式：HTTP渐进下载(HTTP Progressive Download，简称HPD)和HTTP自适应流媒体(HTTP Adaptive Streaming，简称HAS)。

传统的OTT视频一般采用HPD技术。基于HPD的客户端在开始播放之前仅需等待一段较短的时间用于下载和缓冲媒体文件最前面的一部分数据，之后便可以一边下载一边播放。HPD OTT视频存在诸多的局限性，例如：不适合对实时性要求较高的直播节目的传输；初始播放的等待时延一般较长；当网络带宽不稳定时比较容易出现卡片现象；由于客户端会持续下载视频文件，当用户中途放弃节目观看，会造成己下载文件(消耗带宽)的浪费。

为了克服HPD OTT视频技术的局限性，近年来基于HAS的OTT视频技术逐渐被业界广泛采用和推广。HAS OTT采用视频分片和自适应码率(ABR)技术。在HAS系统中，媒体流分割器将编码器输出的视频流分割为一系列连续的、长度均等的小分片文件，并将它们存储在Web内容分发服务器。HAS客户端设备可在可用的带宽的基础上，自动向Web服务器请求合适的视频质量(即不同的分辨率和码率)的分片文件，从而给用户最好的视觉体验。

为了便于HAS客户端实现不同码率分片之间的快速、实时切换，HAS视频一般采用较短的分片长度(例如10秒)。由于HAS系统可向不同屏幕大小的终端提供适合分辨率的视频分片文件，并可在不同网络带宽情况下实现流畅的视频播放，因此HAS被业内认为是未来无所不在的多屏互动视频的核心技术。

在实现现有技术过程中，发明人发现现有技术中至少存在如下问题：

当客户端的视频播放卡顿时，用户不清楚究竟是网络与客户端之间的通信连接发生故障，还有网络与服务器之间的通信连接发生故障，无法满足用户的知情权，以便用户可以采取适当的措施处理该故障，用户体验差。

技术实现要素：

本发明提供了一种网络直播卡顿的处理方法，具体技术方案如下：

将媒体流按照推流级别上传至网络；

接收客户端反馈的网络直播卡顿信息和客户端播放所述媒体流的播放帧率；

根据所述媒体流的采集帧率、所述播放帧率和所述推流级别，确定网络直播卡顿原因。

本发明还提供了另一种网络直播卡顿的处理方法：

加载来自网络的媒体流，以播放帧率播放所述媒体流；

解析所述媒体流，获得所述媒体流的采集帧率以及服务器上传所述媒体流至网络的推流级别；

根据所述采集帧率、所述播放帧率和所述推流级别，确定网络直播卡顿原因。

本发明还提供了一种网络直播卡顿的处理装置，具体如下：

推送模块，用于将媒体流按照推流级别上传至网络；

接收模块，用于接收客户端反馈的网络直播卡顿信息和客户端播放所述媒体流的播放帧率；

计算模块，用于根据所述媒体流的采集帧率、所述播放帧率和所述推流级别，确定网络直播卡顿原因。

本发明还提供了另一种网络直播卡顿的处理装置，包括：

加载模块，用于加载来自网络的媒体流，以播放帧率播放所述媒体流；

解析模块，用于解析所述媒体流，获得所述媒体流的采集帧率以及服务器上传所述媒体流至网络的推流级别；

运算模块，用于根据所述采集帧率、所述播放帧率和所述推流级别，确定网络直播卡顿原因。

由以上技术方案可以看出，本申请提供的实施方案至少具有如下技术效果：

当网络直播卡顿时，根据所述采集帧率、所述播放帧率和所述推流级别，确定网络直播卡顿原因以便后续处理，从而提高用户体验。

【附图说明】

图1本申请揭示的一种网络直播卡顿的处理方法的流程图。

图2本申请揭示的另一种网络直播卡顿的处理方法的流程图。

图3本申请揭示的一种网络直播卡顿的处理装置的结构示意图。

图4本申请揭示的一种网络直播卡顿的处理装置的结构示意图。

【具体实施方式】

为了使本申请的目的、技术方案和优点更加清楚，下面结合附图和具体实施例对本申请进行详细描述。

如图1所示，本申请揭示一种网络直播卡顿的处理方法，包括：

S100：将媒体流按照推流级别上传至网络。

媒体流可以由音频信号、视频信号或音频与视频的混合信号构成。活动场景可以通过存储于介质中的上述音视频信号来记录和传播。记录和传播的活动场景，具体体现为存储于介质中的音频信号、视频信号描述的一系列静态场景的动态更新。这些介质可以包括磁带、硬盘和闪存等多种载体。静态场景的更新频率通过帧率来表示。活动场景记录过程中的帧率可以以采集帧率表示，对应的，活动场景的播放过程中的帧率可以以播放帧率表示。考虑到适合于网络直播，这里的一段媒体流的大小，通常可以认为是毫秒级别的长短。帧率通常可以认为在6帧/秒-120帧/秒。

现有技术的直播过程中，通常会对存储于介质中的上述各种信号进行编码和解码的处理。通用的编码格式有CCIR 601、M-JPEG、MPEG-1、MPEG-2、MPEG-4、H.261、H.263、H.264/MPEG-4AVC、VC-1等。编码的原理主要是通过将图像网格化为若干像素。对这些像素可以使用RGB值进行描述，从而实现图像的数字化，对于声音则可以使用声压、分贝、频率等数值，实现音频的数字化。

在活动场景的直播过程中，摄像机、录音机等各种音视频设备采集设备音视频信号。服务器将采集到的音视频信号经过编码处理，形成数据资源。客户端可以通过网络，请求访问服务器的数据资源。服务器也可以主动推送数据资源的信息。一段媒体流的大小，可以通过数据资源的容量来表示。活动场景的网络直播过程，反映为数据传输的过程，以码率(单位为字节/秒)来表示数据传输的快慢。若干段媒体流可以形成上传至网络的缓冲队列。缓冲队列中的每段媒体流可以被依次上传至网络。结合媒体流的帧率、编码格式、数据资源的清晰度，可以定义若干推流级别，用以反映数据资源上传至网络时的流畅程度。推流级别的等级越高，数据资源传输越顺畅。

本申请提供一种服务器上传媒体流的实施方式，具体的：

可以设定若干推流级别，例如，设置5个推流级别，分别为1-5级，1级为最高级，相应的，5级为最低级。由于服务器网络带宽的限制，当缓冲队列的数量容量达到网络带宽允许的峰值时，可以调低推流级别，例如，从1级降为2级。服务器发出降低采集帧率的指令，在该指令下，音视频信号采集设备降低采集频率，从而可以降低网络直播一段时间内的活动场景所占用的数据容量。另外，服务器还可以发出改变编码方式以降低网格数量的指令，在该指令下，图像被稀疏地划分，从而同样可以降低网络直播一段时间内的活动场景所占用的数据容量。相反的，当缓冲队列的数量容量达到网络直播对音视频要求的谷值时，可以调高推流级别，用以改善网络直播的音视频质量。服务器发出提高采集帧率的指令，在该指令下，音视频信号采集设备提高采集频率，从而可以将活动场景表现地更加生动细腻。另外，服务器还可以发出改变编码方式以提高网格数量的指令，在该指令下，图像被稠密地划分，从而可以将活动场景表现地更加生动细腻。服务器上传媒体流的推流级别，可以通过软件实现自适应调整，在设定的若干推流级别中自动地进行切换。

进一步的，在本申请提供的一种实施方式中，媒体流包括用于表达内容的内容帧，和用于表达所述采集帧率、所述推流级别的增强信息帧。内容帧和增强信息帧集合于媒体流中，便于及时校检。这里增强信息帧中的信息包括但不限于采集帧率、推流级别，还可以包括上传时的码率等即时信息。

S200：接收客户端反馈的网络直播卡顿信息和客户端播放所述媒体流的播放帧率。

这里的客户端可以是智能电视、机顶盒、视频播放软件等各种应用提供的接口。客户端下载来自网络的媒体流，以播放帧率进行播放，并显示于各种屏幕，以便用户观看。

网络直播卡顿主要表现为图像静止、出现马赛克、声音变调等，关于网络直播卡顿的检测，现有技术中有详细揭示，此处不再赘述。

服务器接收客户端反馈的网络直播卡顿信息和媒体流的播放帧率，并进行后续处理。

进一步的，在本申请提供的另一种实施方式中，所述播放帧率为一段期间内，客户端播放所述媒体流的平均帧率，以提高运算的准确度。

S300：根据所述媒体流的采集帧率、所述播放帧率和所述推流级别，确定网络直播卡顿原因。

进一步的，在本申请提供的另一种实施例中，根据所述媒体流的采集帧率、所述播放帧率和所述推流级别，确定网络直播卡顿原因，具体包括：

当所述播放帧率小于所述采集帧率达到预设帧率差阈值，并且所述推流级别高于预设第一推流级别时，确定网络直播卡顿原因为客户端通信卡顿。

进一步的，在本申请提供的一种实施例中，所述预设第一推流级别为最低级。

网络直播顺畅，体现为播放帧率与采集帧率之间的一致性。可以理解的是，当播放帧率小于采集帧率达到预设帧率差阈值时，说明网络直播可能存在通信不畅通，通信不畅通的原因可能来自于服务器，也可能来自于客户端。例如，采集帧率为80帧/秒，而播放帧率仅为10帧/秒。预设帧率差阈值，可以根据具体场景适应性设置。为了明确通信不畅通的原因，需要进一步检测服务器上传媒体流的推流级别。当推流级别高于预设第一推流级别时，说明服务器上传媒体流的通信状态是正常的。这里的预设第一推流级别，可以设置为最低级。这样可以排除服务器与网络之间通信不畅通的因素。当然，预设第一推流级别还可以设置为其他级别，例如，中间的某个级别。这样，可以充分排除服务器与网络之间通信不畅通的因素，更加准确的确定，网络直播卡顿原因为客户端通信卡顿。

进一步的，在本申请提供的另一种实施例中，还包括：

连续上传若干段媒体流至网络，以便客户端播放；

若干段媒体流中播放帧率小于采集帧率的媒体流的数量，不小于预设阈值数量。

网络直播中存在偶发因素，例如，媒体流中丢失某些关键帧、短暂性的网络断开，这些都可能影响网络直播卡顿原因的判断。为了提高网络直播卡顿原因判断的准确性，在该实施例中，对多段媒体流进行综合考虑。设置预设阈值数量，当若干段媒体流中播放帧率小于采集帧率的媒体流的数量不小于预设阈值数量时，提示网络直播卡顿原因为客户端通信卡顿。也就是说，若干段媒体流中播放帧率小于采集帧率到预设帧率差阈值中的媒体流的数量不小于预设阈值数量时，提示网络直播卡顿原因为客户端通信卡顿。

进一步的，在本申请提供的另一种实施例中，确定网络直播卡顿原因，具体包括：

当所述播放帧率大于所述采集帧率达到预设帧率差阈值，并且所述推流级别低于预设第二推流级别时，确定网络直播卡顿原因为服务器端通信卡顿。

进一步的，在本申请提供的另一种实施例中，所述预设第二推流级别为最高级。

网络直播顺畅，体现为播放帧率与采集帧率之间的一致性。可以理解的是，当播放帧率大于采集帧率达到预设帧率差阈值时，说明网络直播可能存在通信不畅通，通信不畅通的原因可能来自于服务器，也可能来自于客户端。例如，采集帧率为10帧/秒，而播放帧率高达80帧/秒。预设帧率差阈值，可以根据具体场景适应性设置。为了明确通信不畅通的原因，需要进一步检测服务器上传媒体流的推流级别。当推流级别低于第二预设推流级别时，说明客户端与网络之间的通信状态是正常的。这里的预设第二推流级别，可以设置为最高级。这样可以排除客户端与网络之间通信不畅通的因素。当然，预设推流级别还可以设置为其他级别，例如，中间的某个级别。这样，可以充分排除客户端与网络之间通信不畅通的因素，更加准确的确定，网络直播卡顿原因为服务器端的通信卡顿。

进一步的，在本申请提供的另一种实施例中，还包括：

连续上传若干段媒体流至网络，以便客户端播放；

若干段媒体流中播放帧率大于采集帧率的媒体流的数量,不小于预设阈值数量。

网络直播中存在偶发因素，例如，安装客户端的设备过热、假死、短暂性的网络断开，这些都可能影响网络直播卡顿原因的判断。为了提高网络直播卡顿原因判断的准确性，在该实施例中，对多段媒体流进行综合考虑。设置预设阈值数量，当若干段媒体流中播放帧率大于采集帧率的媒体流的数量不小于预设阈值数量时，提示网络直播卡顿原因为服务器通信卡顿。也就是说，若干段媒体流中播放帧率大于采集帧率到预设帧率差阈值中的媒体流的数量不小于预设阈值数量时，确定网络直播卡顿原因为服务器端的通信卡顿。

在本申请提供的实施例中，当网络直播卡顿时，根据所述采集帧率、所述播放帧率和所述推流级别，确定网络直播卡顿原因，从而可以建立网络直播卡顿原因反馈机制，提升用户体验。

进一步的，在本申请提供的另一种实施例中，还包括：

将确定的网络直播卡顿原因向客户端做出提示。

这样，客户端的用户可以根据确定的网络直播卡顿原因，采取措施。例如，客户端更换网络以改善客户端通信状态，或者切换网络直播源，以改善

如图2所示，本申请还提供另一种网络直播卡顿的处理方法，包括：

S101：加载来自网络的媒体流，以播放帧率播放所述媒体流。

客户端可以通过网络，请求访问服务器的数据资源，从而与服务器建立连接，加载来自网络的媒体流。客户端也可以接收由服务器主动推送的数据资源的信息，同意与服务器建立连接后，加载来自网络的媒体流。

客户端获取媒体流后，以播放帧率播放所述媒体流。

S102：解析所述媒体流，获得所述媒体流的采集帧率以及服务器上传所述媒体流至网络的推流级别。

客户端解析媒体流，获得媒体流的采集帧率和服务器上传媒体流至网络的推流级别。

进一步的，在本申请提供的一种实施方式中，媒体流包括用于表达内容的内容帧，和用于表达所述采集帧率、所述推流级别的增强信息帧。内容帧和增强信息帧集合于媒体流中，便于及时校检。这里增强信息帧中的信息包括但不限于采集帧率、推流级别，还可以包括上传时的码率等即时信息。客户端解析媒体流，获得增强信息帧中包含的采集帧率、推流级别等信息。

S103：根据所述采集帧率、所述播放帧率和所述推流级别，确定网络直播卡顿原因。

进一步的，在本申请提供的另一种实施例中，确定网络直播卡顿原因，具体包括：

当所述播放帧率小于所述采集帧率达到预设帧率差阈值，并且所述推流级别高于预设第一推流级别时，确定网络直播卡顿原因为客户端通信卡顿。

进一步的，在本申请提供的另一种实施例中，所述预设第一推流级别为最低级。

进一步的，在本申请提供的另一种实施例中，确定网络直播卡顿原因，具体包括：

当所述播放帧率大于所述采集帧率达到预设帧率差阈值，并且所述推流级别低于预设第二推流级别时，确定网络直播卡顿原因为服务器端通信卡顿。

进一步的，在本申请提供的另一种实施例中，所述预设第二推流级别为最高级。

进一步的，在本申请提供的另一种实施例中，根据所述媒体流的采集帧率、所述播放帧率和所述推流级别，确定网络直播卡顿原因，具体包括：

当所述播放帧率小于所述采集帧率达到预设帧率差阈值，并且所述推流级别高于最低推流级别时，确定网络直播卡顿原因为客户端通信卡顿；

当所述播放帧率大于采集帧率达到预设帧率差阈值，并且所述推流级别低于最高级时，确定网络直播卡顿原因为客户端通信卡顿为服务器端通信卡顿。

网络直播顺畅，体现为播放帧率与采集帧率之间的一致性。可以理解的是，当播放帧率小于采集帧率达到预设帧率差阈值时，说明网络直播可能存在通信不畅通，通信不畅通的原因可能来自于服务器，也可能来自于客户端。例如，采集帧率为80帧/秒，而播放帧率仅为10帧/秒。预设帧率差阈值，可以根据具体场景适应性设置。为了明确通信不畅通的原因，需要进一步检测服务器上传媒体流的推流级别。当推流级别高于预设第一推流级别时，说明服务器上传媒体流的通信状态是正常的。这里的预设第一推流级别，可以设置为最低级。这样可以排除服务器与网络之间通信不畅通的因素。当然，预设第一推流级别还可以设置为其他级别，例如，中间的某个级别。这样，可以充分排除服务器与网络之间通信不畅通的因素，更加准确的确定，网络直播卡顿原因为客户端通信卡顿。

相对的，当播放帧率大于采集帧率达到预设帧率差阈值时，说明网络直播同样可能存在通信不畅通，通信不畅通的原因可能来自于服务器，也可能来自于客户端。例如，采集帧率为10帧/秒，而播放帧率高达80帧/秒。预设帧率差阈值，可以根据具体场景适应性设置。为了明确通信不畅通的原因，需要进一步检测服务器上传媒体流的推流级别。当推流级别低于第二预设推流级别时，说明客户端与网络之间的通信状态是正常的。这里的预设第二推流级别，可以设置为最高级。这样可以排除客户端与网络之间通信不畅通的因素。当然，预设推流级别还可以设置为其他级别，例如，中间的某个级别。这样，可以充分排除客户端与网络之间通信不畅通的因素，更加准确的确定，网络直播卡顿原因为服务器端的通信卡顿。

在本申请提供的实施例中，当网络直播卡顿时，根据所述采集帧率、所述播放帧率和所述推流级别，确定网络直播卡顿原因，从而可以建立网络直播卡顿原因反馈机制，提升用户体验。

本申请还提供一种网络直播卡顿的处理方法，包括：

服务器将媒体流按照推流级别上传至网络；

客户端加载来自网络的媒体流，以播放帧率播放所述媒体流；

当网络直播卡顿时，服务器或客户端至少其中之一，根据所述媒体流的采集帧率、所述播放帧率和所述推流级别，确定网络直播卡顿原因。

在网络直播的通道建立后，服务器将媒体流按照一定的推流级别上传至网络。客户端加载来自网络的媒体流，以播放帧率播放所述媒体流。当网络直播卡顿时，服务器接收客户端反馈的网络直播卡顿信息和客户端播放所述媒体流的播放帧率。服务器根据所述媒体流的采集帧率、所述播放帧率和所述推流级别，确定网络直播卡顿原因。

或者，当网络直播卡顿时，客户端解析所述媒体流，获得所述媒体流的采集帧率以及服务器上传所述媒体流至网络的推流级别。客户端根据所述采集帧率、所述播放帧率和所述推流级别，确定网络直播卡顿原因。

在本申请提供的实施例中，当网络直播卡顿时，根据所述采集帧率、所述播放帧率和所述推流级别，确定网络直播卡顿原因，从而可以建立网络直播卡顿原因反馈机制，提升用户体验。

服务器或客户端，确定网络直播卡顿原因的具体方式，前面已做了详细陈述，这里不再赘述。

以上是本申请实施例提供的网络直播卡顿的处理方法,基于同样的思路，请参照图3，本申请还提供一种网络直播卡顿的处理装置，包括：

推送模块11，用于将媒体流按照推流级别上传至网络；

接收模块12，用于接收客户端反馈的网络直播卡顿信息和客户端播放所述媒体流的播放帧率；

计算模块13，用于根据所述媒体流的采集帧率、所述播放帧率和所述推流级别，确定网络直播卡顿原因。

进一步的，在本申请提供的另一种实施例中，所述计算模块13具体用于：

当所述播放帧率小于所述采集帧率达到预设帧率差阈值，并且所述推流级别高于预设第一推流级别时，确定网络直播卡顿原因为客户端通信卡顿。

进一步的，在本申请提供的另一种实施例中，所述预设第一推流级别为最低级。

进一步的，在本申请提供的另一种实施例中，所述推送模块11具体用于连续上传若干段媒体流至网络，以便客户端播放；

其中，若干段媒体流中播放帧率小于采集帧率的媒体流的数量，不小于预设阈值数量。

进一步的，在本申请提供的另一种实施例中，所述计算模块13具体用于：

当所述播放帧率大于所述采集帧率达到预设帧率差阈值，并且所述推流级别低于预设第二推流级别时，确定网络直播卡顿原因为服务器端通信卡顿。

进一步的，在本申请提供的另一种实施例中，所述预设第二推流级别为最高级。

进一步的，所述推送模块11具体用于连续上传若干段媒体流至网络，以便客户端播放；

其中，若干段媒体流中播放帧率大于采集帧率的媒体流的数量,不小于预设阈值数量。

在本申请提供的实施例中，当网络直播卡顿时，根据所述采集帧率、所述播放帧率和所述推流级别，确定网络直播卡顿原因，从而可以建立网络直播卡顿原因反馈机制，提升用户体验。

请参照图4，本申请还提供一种网络直播卡顿的处理装置，包括：

加载模块21，用于加载来自网络的媒体流，以播放帧率播放所述媒体流；

解析模块22，用于解析所述媒体流，获得所述媒体流的采集帧率以及服务器上传所述媒体流至网络的推流级别；

运算模块23，用于根据所述采集帧率、所述播放帧率和所述推流级别，确定网络直播卡顿原因。

进一步的，在本申请提供的另一种实施例中，所述运算模块23具体用于：

当所述播放帧率小于所述采集帧率达到预设帧率差阈值，并且所述推流级别高于预设第一推流级别时，确定网络直播卡顿原因为客户端通信卡顿。

进一步的，在本申请提供的另一种实施例中，所述预设第一推流级别为最低级。

进一步的，在本申请提供的另一种实施例中，所述运算模块23具体用于：

当所述播放帧率大于所述采集帧率达到预设帧率差阈值，并且所述推流级别低于预设第二推流级别时，确定网络直播卡顿原因为服务器端通信卡顿。

进一步的，在本申请提供的另一种实施例中，所述预设第二推流级别为最高级。

进一步的，在本申请提供的另一种实施例中，所述运算模块23具体用于：

当所述播放帧率小于所述采集帧率达到预设帧率差阈值，并且所述推流级别高于最低推流级别时，确定网络直播卡顿原因为客户端通信卡顿；

当所述播放帧率大于采集帧率达到预设帧率差阈值，并且所述推流级别低于最高级时，确定网络直播卡顿原因为客户端通信卡顿为服务器端通信卡顿。

在本申请提供的实施例中，当网络直播卡顿时，根据所述采集帧率、所述播放帧率和所述推流级别，确定网络直播卡顿原因，从而可以建立网络直播卡顿原因反馈机制，提升用户体验。

本申请还提供一种网络直播卡顿的处理系统，包括：

服务器，用于将媒体流按照推流级别上传至网络；

客户端，用于加载来自网络的媒体流，以播放帧率播放所述媒体流；

当网络直播卡顿时，服务器或客户端至少其中之一，根据所述媒体流的采集帧率、所述播放帧率和所述推流级别，确定网络直播卡顿原因。

在本申请提供的实施例中，当网络直播卡顿时，根据所述采集帧率、所述播放帧率和所述推流级别，确定网络直播卡顿原因，从而可以建立网络直播卡顿原因反馈机制，提升用户体验。

以上所述仅为本申请的较佳实施例而已，并不用以限制本申请，凡在本申请的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本申请保护的范围之内。