CN111327964A - 一种定位视频播放卡顿的方法及设备 - Google Patents

一种定位视频播放卡顿的方法及设备 Download PDF

Info

Publication number
CN111327964A
CN111327964A CN201811544632.9A CN201811544632A CN111327964A CN 111327964 A CN111327964 A CN 111327964A CN 201811544632 A CN201811544632 A CN 201811544632A CN 111327964 A CN111327964 A CN 111327964A
Authority
CN
China
Prior art keywords
video stream
playing
video
positioning
time length
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN201811544632.9A
Other languages
English (en)
Other versions
CN111327964B (zh
Inventor
高爱丽
吕万
盛中来
秦文丽
杨晓青
周梦菲
刘桓
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
China Mobile Communications Group Co Ltd
China Mobile Group Beijing Co Ltd
Original Assignee
China Mobile Communications Group Co Ltd
China Mobile Group Beijing Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by China Mobile Communications Group Co Ltd, China Mobile Group Beijing Co Ltd filed Critical China Mobile Communications Group Co Ltd
Priority to CN201811544632.9A priority Critical patent/CN111327964B/zh
Publication of CN111327964A publication Critical patent/CN111327964A/zh
Application granted granted Critical
Publication of CN111327964B publication Critical patent/CN111327964B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/845—Structuring of content, e.g. decomposing content into time segments
    • H04N21/8456—Structuring of content, e.g. decomposing content into time segments by decomposing the content in the time domain, e.g. in time segments
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/238—Interfacing the downstream path of the transmission network, e.g. adapting the transmission rate of a video stream to network bandwidth; Processing of multiplex streams
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/238—Interfacing the downstream path of the transmission network, e.g. adapting the transmission rate of a video stream to network bandwidth; Processing of multiplex streams
    • H04N21/2387—Stream processing in response to a playback request from an end-user, e.g. for trick-play
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/438—Interfacing the downstream path of the transmission network originating from a server, e.g. retrieving encoded video stream packets from an IP network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/845—Structuring of content, e.g. decomposing content into time segments
    • H04N21/8455—Structuring of content, e.g. decomposing content into time segments involving pointers to the content, e.g. pointers to the I-frames of the video stream
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/85—Assembly of content; Generation of multimedia applications
    • H04N21/858—Linking data to content, e.g. by linking an URL to a video object, by creating a hotspot
    • H04N21/8586—Linking data to content, e.g. by linking an URL to a video object, by creating a hotspot by using a URL

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Abstract

本发明公开了一种定位视频播放卡顿的方法及设备，涉及互联网技术领域，用以解决现有技术中评估视频播放卡顿方式都存在不同程度的实现难点，很难精确地评估视频播放卡顿的情况的问题，本发明方法包括：确定触发定位视频播放卡顿时，根据定位视频流的视频流分片数据包的时间信息，确定所述定位视频流的实际播放时长，根据所述定位视频流的视频流分片数据包中的最新视频流分片数据包，确定所述定位视频流的理论播放时长，通过比较所述定位视频流的实际播放时长和理论播放时长，确定是否存在视频播放卡顿现象。

Description

一种定位视频播放卡顿的方法及设备
技术领域
本发明涉及互联网视频技术领域，特别涉及一种定位视频播放卡顿的方法及设备。
背景技术
随着长期演进LTE(Long Term Evolution)4G业务的普及，移动互联网视频成为4G的十分重要的业务，移动用户充分享用LTE带来高速率特性的同时，也将视频业务质量作为考察LTE网络适用性最直接的手段，承载在LTE网络上的视频播放引发的各项用户感知指标，是网络优化维护工程师评估用户使用感知体验，及时发现网络问题的重点依据，尤其是视频播放卡顿指标是用户使用感知的最直接反馈，因此需要一种可以准确定位视频播放卡顿的方法。
目前评估视频播放卡顿主要有以下几种方法：
(1)通过向视频播放软件开发公司获取埋码规则，但这种方式需要视频播放软件开发公司提供相关特征码明文规则，并且特征码可能会随时变化；
(2)通过在视频播放软件进行SDK(software development kit，软件开发工具包)植入形式，采用这种方式，需要公司自有开发的视频播放软件，才能在视频播放软件中植入；
(3)应用采集层视频分片打点形式，采用这种方式时，传统的基于信令的打点方式，主要是利用三个元素(视频码率、下载速率、缓冲区播放逻辑) 进行关联建模，分析视频加载时长、卡顿次数等质量指标，但是此方式存在瓶颈，如视频码率识别困难(存在flv、f4v、mp4、ts多文件格式的视频文件)，且不同播放器业务逻辑差异大，播放参数获取困难(不同播放器首播视频缓冲长度、不同清晰度视频码率、缓冲区设置均有很大差异，且经常变化)，并且还需要对采集侧进行改动，需部署专门的视频卡顿采集程序，基于信令打点推测分析卡顿情况。如按照200ms打点，根据现网每天715TB视频业务量估算，需要处理大概500亿次打点，数据量大，负荷高，对处理服务器要求高。
综上所述，目前评估视频播放卡顿方式都存在不同程度的实现难点，很难精确地评估视频播放卡顿的情况。
发明内容
本发明提供一种定位视频播放卡顿的方法及设备，用以解决现有技术中评估视频播放卡顿方式都存在不同程度的实现难点，很难精确地评估视频播放卡顿的情况的问题。
第一方面，本发明实施例提供的一种定位视频播放卡顿的方法，该方法包括：
确定触发定位视频播放卡顿时，根据定位视频流的视频流分片数据包的时间信息，确定所述定位视频流的实际播放时长；
根据所述定位视频流的视频流分片数据包中的最新视频流分片数据包，确定所述定位视频流的理论播放时长；
通过比较所述定位视频流的实际播放时长和理论播放时长，确定是否存在视频播放卡顿现象。
上述方法，直接通过视频流的视频流分片数据包的相关信息，计算所述视频流的实际播放时长和理论播放时长，并根据计算结果判断是否存在视频播放卡顿现象，能够精确地评估视频播放卡顿的情况，且上述方法易于实施。
在一种可能的实现方式中，所述定位视频流的起始视频流分片数据包为最近一次定位视频播放发生卡顿的视频流分片数据包的下一个视频流分片数据包。
在一种可能的实现方式中，初次触发定位视频播放卡顿时，所述定位视频流的起始视频流分片数据包为下载的第一个视频流分片数据包。
在一种可能的实现方式中，所述定位视频流的最新视频流分片数据包为请求下载的第N+1个视频流分片数据包；N为当前下载完的视频流分片数据包的个数。
在一种可能的实现方式中，根据所述定位视频流中的最新视频流分片数据包开始下载的时间点，及所述定位视频流中初始视频流分片数据包开始下载的时间点，确定所述定位视频流的实际播放时长。
在一种可能的实现方式中，所述最新视频流分片数据包和初始视频流分片数据包开始下载的时间点，分别通过请求下载所述最新视频流分片数据包和初始视频流分片数据包的请求信息的信息记录获取。
在一种可能的实现方式中，将所述定位视频流的视频流分片时长，乘以所述定位视频流的视频流分片数据包的总个数，确定所述定位视频流的理论播放时长。
若所述定位视频流的实际播放时长小于/等于理论播放时长，则确定所述定位视频流不存在视频播放卡顿现象；若所述定位视频流的实际播放时长大于理论播放时长，则确定所述定位视频流存在视频播放卡顿现象。
在一种可能的实现方式中，确定所述定位视频流存在视频播放卡顿现象之后，还包括：将所述定位视频流的实际播放时长和理论播放时长置零；将发生视频播放卡顿的视频流分片数据包的下一个视频流分片数据包作为起始视频流分片数据包，重新触发定位视频播放卡顿。
在一种可能的实现方式中，确定所述定位视频流存在视频播放卡顿现象之后，还包括：
对所述定位视频流做视频播放卡顿参数评估。
将当前已下载的视频流的卡顿的累积次数，除以当前定已下载的定位视频流的视频流分片数据包总数作为当前已下载的定位视频流的卡顿次数占比；将当前已下载的视频流的卡顿时长的累积时长，除以当前已下载的定位视频流的视频流分片数据包总数与所述视频流分片时长之积的结果作为当前已下载的视频流的卡顿时长占比。在一种可能的实现方式中，通过如下方式获得所述当前已下载的视频流的卡顿时长：确定所述视频流的理论播放时长与实际播放时长差值的绝对值为所述视频流的卡顿时长。
在一种可能的实现方式中，将所述定位视频流的最新视频流分片数据包开始下载的时间点减去所述初始视频流分片数据包开始下载的时间点的结果，作为所述定位视频流的实际播放时长；或者将所述定位视频流的最新视频流分片数据包开始下载的时间点减去所述初始视频流分片数据包开始下载的时间点，再根据视频播放卡顿修正值确定所述定位视频流的实际播放时长。
在一种可能的实现方式中，通过以下任一或任多方式确定所述视频播放卡顿修正值：将缓存的穿插到定位视频流中进行播放的冗余视频流的实际播放时长，确定为所述视频播放卡顿修正值；将定位视频流中在播放过程中暂停播放的时长，确定为所述视频播放卡顿修正值。
上述方法中，利用视频播放卡顿修正值对定位视频流的定位视频播放卡顿进行修正，提高了定位视频播放卡顿的精准性。
在一种可能的实现方式中，确定所述定位视频流在播放过程中发生拖拽事件时，将发生拖拽事件后的最新的视频流分片数据包作为定位视频流的起始视频流分片数据包，重新触发定位视频播放卡顿；
上述方法中，在定位视频在播放过程中发生拖拽事件后，重新触发定位视频播放卡顿，提高了定位视频播放卡顿的精准性。
第二方面，本发明实施例提供的一种定位视频播放卡顿的设备，该设备包括：处理器以及收发机：
所述处理器：用于利用收发机确定触发定位视频播放卡顿时，根据定位视频流的视频流分片数据包的时间信息，确定所述定位视频流的实际播放时长；
根据所述定位视频流的视频流分片数据包中的最新视频流分片数据包，确定所述定位视频流的理论播放时长；
通过比较所述定位视频流的实际播放时长和理论播放时长，确定是否存在视频播放卡顿现象。
第三方面，本发明实施例提供的一种定位视频播放卡顿的设备，该设备包括：至少一个处理单元以及至少一个存储单元，其中，所述存储单元存储有程序代码，当所述程序代码被所述处理单元执行时，使得所述处理单元执行下列过程：
确定触发定位视频播放卡顿时，根据定位视频流的视频流分片数据包的时间信息，确定所述定位视频流的实际播放时长；
根据所述定位视频流的视频流分片数据包中的最新视频流分片数据包，确定所述定位视频流的理论播放时长；
通过比较所述定位视频流的实际播放时长和理论播放时长，确定是否存在视频播放卡顿现象。
第四方面，本申请还提供一种计算机存储介质，其上存储有计算机程序，该程序被处理单元执行时实现第一方面所述方法的步骤。
另外，第二方面至第四方面中任一种实现方式所带来的技术效果可参见第一方面中不同实现方式所带来的技术效果，此处不再赘述。
附图说明
为了更清楚地说明本发明实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简要介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域的普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
图1A为本发明实施例一提供的一种定位视频播放卡顿的方法示意图；
图1B为本发明实施例一提供的获得视频流分片数据包的TCP流开始的时间点的截图示意图；
图1C为本发明实施例一提供的一种定位视频播放卡顿的具体实施方法的示意图；
图1D为本发明实施例一提供的客户端从服务端下载的视频流的信令的交互过程；
图1E为本发明实施例一提供的视频播放软件“云视界”的视频流分片数据包的识别规则示意图；
图1F为本发明实施例一提供的视频播放软件“腾讯视频”的视频正片的视频流分片数据包的识别规则示意图；
图1G为本发明实施例一提供的视频播放软件“咪咕视频”的视频流分片数据包的识别规则示意图；
图2A为本发明实施例二提供的“腾讯视频”的广告信令截图；
图2B为本发明实施例二提供的存在广告缓存时进行视频播放卡顿评估时的一组测试计算结果；
图2C为本发明实施例二提供的存在视频播放暂停时进行视频播放卡顿评估时的一组测试计算结果；
图2D为本发明实施例二提供的广告播放及视频暂停播放标志位的识别规则示意图；
图2E为本发明实施例二提供的视频播放暂停结束后视频播放开始的标志示意图；
图2F为本发明实施例二提供的视频播放软件“腾讯视频”的发生拖拽进度的视频流分片数据包的识别规则示意图；
图2G为本发明实施例二提供的存在视频拖拽现象的一组TCP会话流截图；
图3A为本发明实施例三提供的定位视频播放卡顿的第一设备示意图；
图3B为本发明实施例三提供的定位视频播放卡顿的第二设备示意图；
图4为本发明实施例四提供的定位视频播放卡顿的第三设备示意图。
具体实施方式
为了使本发明的目的、技术方案和优点更加清楚，下面将结合附图对本发明作进一步地详细描述，显然，所描述的实施例仅仅是本发明一部份实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本发明保护的范围。
下面对文中出现的一些词语进行解释：
1、本发明实施例中术语“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。字符“/”一般表示前后关联对象是一种“或”的关系。
本发明实施例描述的应用场景是为了更加清楚的说明本发明实施例的技术方案，并不构成对于本发明实施例提供的技术方案的限定，本领域普通技术人员可知，随着新应用场景的出现，本发明实施例提供的技术方案对于类似的技术问题，同样适用。其中，在本发明的描述中，除非另有说明，“多个”的含义是两个或两个以上。
目前，国内主流视频类应用软件APP(优酷、搜狐、腾讯、爱奇艺等)均是基于TCP/HTTP的OTT(Over The Top)视频，OTT视频是指基于HTTP协议和开放互联网的视频服务，同传统的IPTV视频协议栈(基于UDP/RTP的 MPEG-TS视频码流)不同，OTT视频采用标准HTTP/TCP协议来递送媒体数据。
常用的流媒体协议主要有HTTP渐进下载和基于RTSP/RTP的实时流媒体协议，这二种基本是完全不同的技术，目前比较方便又好用的是用HTTP渐进下载方法。在这个中apple公司的HTTP Live Streaming是这个方面的代表。
HTTP Live Streaming(缩写是HLS)是一种由苹果公司提出的基于HTTP 的流媒体网络传输协议。把整个视频流分成一个个小段，基于HTTP的文件来下载，每次只下载一些，传输内容包括两部分，一是M3U8索引文件，二是 TS媒体文件。视频分片是HLS中的TS媒体文件，通过将整个视频按照固定时长进行切片，用户无需缓存整个视频，能够节省服务器带宽。目前主流视频类应用软件App均采用此技术。
当用户使用客户端App在线播放视频，客户端会向服务器请求相应的视频信息，服务器响应请求下发视频的相关信息，客户端根据获得的视频下载地址发起资源下载请求，服务器响应资源请求消息即发送相应的视频数据。当客户端收到的视频数据超过初始缓冲门限后，客户端即可一边进行下载一边播放视频。
为了使本发明的目的、技术方案和优点更加清楚，下面将结合附图对本发明作进一步地详细描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本发明保护的范围。
针对上述场景，下面结合说明书附图对本发明实施例做进一步详细描述。
实施例一：
如图1A所示，本实施例提供的一种定位视频播放卡顿的方法，具体包括以下步骤：
步骤101，确定触发定位视频播放卡顿时，根据定位视频流的视频流分片数据包的时间信息，确定上述定位视频流的实际播放时长；
上述定位视频流为需要进行视频播放是否存在卡顿情况的从服务端下载的视频流；作为一种可能的实施方式，在初次触发定位视频播放卡顿时，上述定位视频流的起始视频流分片数据包为下载的第一个视频流分片数据包。
在对从服务端下载视频流进行卡顿情况评估的过程中，上述定位视频流的起始视频流分片数据包为最近一次定位视频播放发生卡顿的视频流分片数据包的下一个视频流分片数据包。
上述定位视频流的最新视频流分片数据包为请求下载的第N+1个视频流分片数据包；N为当前下载完的视频流分片数据包的个数。
作为一种可选的实施方式，上述定位视频流的最新视频流分片数据包还可以为当前最新下载完的第N个视频流分片数据包。
在实施中，根据上述定位视频流中的最新视频流分片数据包开始下载的时间点，及上述定位视频流中初始视频流分片数据包开始下载的时间点，确定上述定位视频流的实际播放时长，在本实施中，将上述定位视频流的最新视频流分片数据包开始下载的时间点减去上述初始视频流分片数据包开始下载的时间点的结果，作为上述定位视频流的实际播放时长。
作为一种可选的实施方式，当上述定位视频流的最新视频流分片数据包还可以为当前最新下载完的第N个视频流分片数据包时，根据上述定位视频流中的最新视频流分片数据包结束下载的时间点，及上述定位视频流中初始视频流分片数据包开始下载的时间点，确定上述定位视频流的实际播放时长，在本实施中，将上述定位视频流的最新视频流分片数据包结束下载的时间点减去上述初始视频流分片数据包开始下载的时间点的结果，作为上述定位视频流的实际播放时长。
作为一种可能的实施方式，上述最新视频流分片数据包和初始视频流分片数据包开始下载的时间点，分别通过请求下载上述最新视频流分片数据包和初始视频流分片数据包的请求信息的信息记录获取；
作为一种可能的实施方式，当上述定位视频流的最新视频流分片数据包还可以为当前最新下载完的第N个视频流分片数据包时，上述最新视频流分片数据包结束下载的时间点，可以通过下载上述最新视频流分片数据包完成的信息的信息记录获取。
在本实施例中，当客户端向服务端每发送一条请求下载视频流分片数据包的请求信息(get请求)时，可以但不局限于使用DPI(Deep Packet Inspection，深度包检测)设备采集的关键信息记录XDR(X Data Recording，X数据记录) 生成规则为每个get请求生成1条XDR记录，可以但不局限于解析XDR记录获得视频流分片数据包的TCP流开始的时间点(即上述视频流分片数据包开始下载的时间点)，如图1B所示；
上述客户端的DPI设备是一种基于数据包的深度检测技术的设备，针对不同的网络应用层载荷(例如HTTP、DNS等)进行深度检测，通过对报文的有效载荷检测决定其合法性；
上述get请求，即为http协议里的http请求的方法，如get请求方法：在浏览器的地址栏中输入网址的方式访问网页时，浏览器采用get方法向服务器获取资源即如GET/form.html HTTP/1.1；上述http请求由请求行、消息报头和请求正文三部分组成。
步骤102，根据上述定位视频流的视频流分片数据包中的最新视频流分片数据包，确定上述定位视频流的理论播放时长；
在实施中，将上述定位视频流的视频流分片时长，乘以上述定位视频流的视频流分片数据包的总个数，确定上述定位视频流的理论播放时长。
步骤103，通过比较上述定位视频流的实际播放时长和理论播放时长，确定是否存在视频播放卡顿现象。
在实施中，若上述定位视频流的实际播放时长小于/等于理论播放时长，则确定上述定位视频流不存在视频播放卡顿现象；
若上述定位视频流的实际播放时长大于理论播放时长，则确定上述定位视频流存在视频播放卡顿现象。
确定上述定位视频流存在视频播放卡顿现象之后，还包括：将上述定位视频流的实际播放时长和理论播放时长置零；将发生视频播放卡顿的视频流分片数据包的下一个视频流分片数据包作为起始视频流分片数据包，重新触发定位视频播放卡顿。
作为一种可选的实施方式，确定上述定位视频流存在视频播放卡顿现象之后，还包括：对上述定位视频流做以下内容的视频播放卡顿参数评估：
将当前已下载的视频流的卡顿的累积次数，除以当前已下载的定位视频流的视频流分片数据包总数作为当前已下载的定位视频流的卡顿次数占比；
将当前已下载的视频流的卡顿时长的累积时长，除以当前已下载的定位视频流的视频流分片数据包总数与上述视频流分片时长之积的结果作为当前已下载的视频流的卡顿时长占比。
在实施中，确定上述视频流的理论播放时长与实际播放时长差值的绝对值为上述视频流的卡顿时长；
在实施中，可以但不局限于在每次确定上述定位视频流存在视频播放卡顿现象之后，进行视频播放卡顿参数评估，或者在上述定位视频流播放结束时，进行视频播放卡顿参数评估，本领域的技术人员可根据实际需求设置。
如图1C所示，本发明实施例提供的一种客户端定位视频播放卡顿的具体实施方法包括：
步骤1101，触发定位视频播放卡顿；
可以设置触发定位视频播放卡顿的触发机制，如设置为每请求下载一个新的视频流分片数据包，则触发一次定位视频播放卡顿。也可以设置为间隔设定时间周期触发一次确定定位视频播放卡顿等。
步骤1102，利用协议分析器捕捉关键信息记录XDR；
上述协议分析器可以但不局限于设置在客户端；
步骤1103，根据捕捉的XDR中的定位视频流的视频流分片数据包的时间信息，计算上述定位视频流的实际播放时长；
步骤1104，根据最新视频流分片数据包，确定定位视频流的理论播放时长；
步骤1105，比较定位视频流的实际播放时长和理论播放时长；
步骤1106，判断实际播放时长是否大于理论播放时长，若大于进入步骤 1107，否则进入步骤1101；
步骤1107，确定存在视频播放卡顿现象，将上述定位视频流的实际播放时长和理论播放时长置零；将发生视频播放卡顿的视频流分片数据包的下一个视频流分片数据包作为起始视频流分片数据包，进入步骤1108；
步骤1108，判断上述定位视频流播放是否结束，若结束进入步骤1109，否则进入步骤1101；
步骤1109，对上述定位视频流做视频播放卡顿参数评估，计算卡顿次数占比和卡顿时长占比。
以下给出一个定位视频播放卡顿的具体实施方法：
上述客户端从服务端下载的视频流的信令的交互过程如图1D所示：
当用户使用客户端在线播放视频，客户端会向服务器请求相应的视频信息，服务器响应请求下发视频的相关信息，客户端根据获得的视频下载地址发起资源下载请求，服务器响应资源请求消息即发送相应的视频流分片数据包。当客户端收到的视频流分片数据包超过初始缓冲门限后，客户端即可一边进行下载一边播放视频。
常用的流媒体协议主要有HTTP渐进下载和基于RTSP/RTP的实时流媒体协议，这二种基本是完全不同的技术，本实施例中是以苹果公司的HTTP Live Streaming的HTTP渐进下载为例。
上述HTTP Live Streaming(缩写是HLS)是一种由苹果公司提出的基于 HTTP的流媒体网络传输协议，在上述HLS中，把整个视频流分成一个个片段，基于HTTP的文件来下载，每次只下载，其中下载时传输的内容包括两部分，一是M3U8索引文件，二是TS媒体文件。上述视频流分片数据包是HLS中的 TS媒体文件，通过将整个视频流按照固定的视频分片时长进行切片，这种方式中，用户无需缓存整个视频流，能够节省服务器带宽。目前主流视频播放软件均采用此技术，因此均适用于本实施例提供的定位视频播放卡顿的方法。
视频、音频资源是通过一段段的码流，即TS(Transport Stream，传输流), 用于数据传输。TS码流由于采用了固定长度的包结构，当传输误码破坏了某一TS包的同步信息时，接收机仍然可在固定的位置检测它后面包中的同步信息，从而恢复同步，避免了信息丢失。由于TS码流具有较强的抵抗传输误码的能力，因此目前在传输媒体中基本上都采用了TS码流的包格式。
因为视频资源是以TS码流分片形式基于TCP/HTTP协议进行传输，客户端向服务器发起http get请求，每次get请求会获取1个TS分片资源(即视频流分片数据包)，而现有DPI设备采集的XDR生成规则为每个get请求生成1 条XDR记录，那么每个视频TS分片都会生成1条XDR。由于TS码流采用了固定长度(即固定的视频流分片时长)的包结构，假如按照每个get请求的视频分片播放时间长度为12s，那么按照如下方法计算定位视频播放卡顿，实现简单，不需要对解码层、共享层规则修改，直接在现有共享层XDR基础上快速实现。
在实施中，由于上述get请求中，不仅有TS分片资源，还会有图片、文本等其他相关的资源，因此在触发定位视频播放卡顿时，需要对上述定位视频流的视频流分片数据包进行识别，对于不同视频播放软件，对应有不同的识别视频流数据包的规则，如下给出几种视频播放软件对应的视频流分片数据包的具体识别规则：
(1)如图1E所示，视频播放软件“云视界”的视频流分片数据包的识别规则如下：
A、Request Method：GET，且Request URI中，第2个“/”后为otttv.bj.chinamobile.com，且第7个“/”后第2个“.”后为“ts”；
B、并且有http返回状态为200或者206的；
C、并且Content-Type:video/mpeg；
同时满足上述A、B和C条件的视频流分片数据包为“云世界”的视频流分片数据包。
(2)如图1F所示，视频播放软件“腾讯视频”的视频正片的视频流分片数据包的识别规则如下：
A、通过HTTP get，第1个“/”后，域名为omts.tc.qq.com，或newsts.tc.qq.com 或moviets.tc.qq.com，第4个“/”后第3个“.”为“ts”；
B、并且有http返回状态为200或者206的；
C、并且Content-Type:video/MP2T；
同时满足上述A、B和C条件的视频流分片数据包为“腾讯视频”的视频正片的视频流分片数据包，如图1F为“腾讯视频”的视频正片的视频流分片数据包的信令截图。
(3)如图1G所示，视频播放软件“咪咕视频”的视频流分片数据包的识别规则如下：
A、通过HTTP Get，Host:hlsmgspvod.miguvideo.com：8080；
B、并且通过HTTP get，第9个“/”后的第2个“.”后为“ts”；
C、并且有http返回状态为200或者206；
D、并且Content-Type:video/mpeg；
同时满足上述A、B、C和D条件的视频流分片数据包为“咪咕视频”视频流分片数据包。
如下表1所示，在本实施例中，上述视频流分片时长(即表1中TS分片支持播放时长B)为可以播放12秒的时长，计算出定位视频流的实际播放时长(即下表1中{(第N+1的分片包TCP流开始的时间)-(第1的分片包 TCP流开始的时间)＝A})，且计算出上述定位视频流的理论播放时长；
作为一种可选的实施方式，计算上述定位视频流的实际播放时长和理论播放时长的方式如下：
(1)实际播放时长＝(第N+1的分片包TCP流开始时间)-(第1个的分片包TCP流开始时间)；
(2)理论播放时长＝(N+1)X(TS分片支持播放时长B)；
表1：
Figure BDA0001909044840000141
Figure BDA0001909044840000151
通过比较上述定位视频流的实际播放时长和理论播放时长，确定是否存在视频播放卡顿现象的方法如下：
(1)实际播放时长小于/等于理论播放时长时，则确定上述定位视频流不存在视频播放卡顿现象；
(2)实际播放时长大于理论播放时长，则确定上述定位视频流存在视频播放卡顿现象。
在表1中，第1个的分片包TCP流开始时间为从TCP三次握手后的第1个视频分片；
确定上述定位视频流存在视频播放卡顿现象后，将上述定位视频流的实际播放时长和理论播放时长置零；将发生视频播放卡顿的视频流分片数据包的下一个视频流分片数据包(即如表1中的Atime7对应的视频流分片数据包)作为起始视频流分片数据包，重新触发定位视频播放卡顿；
且对上述定位视频流做以下内容的视频播放卡顿参数评估：
(1)卡顿次数占比＝(当前已下载的视频流的卡顿的累积次数)/(当前定位视频播放卡顿总次数)；
在实施中，可以在下载一个视频流分片数据包时进行一次定位视频播放卡顿，也可以在下载两个或任多个视频流分片数据包时进行一次定位视频播放卡顿；
在本实施例中，下载TS分片的总次数即为上述当前定位视频播放卡顿总次数，如表1，下载TS分片的总次数为10次，共有10条XDR记录，在图1D 中卡顿时长小于0时，即表示发生了视频播放卡顿现象，由表1可知当前已下载的视频流的卡顿的累积次数为1，即计算出的卡顿次数占比为1/10＝10％；
(2)卡顿时长占比＝(当前已下载的视频流的卡顿时长的累积时长)/{(当前定位视频播放卡顿的总次数)X(视频流分片时长)}；
如表1所示，视频流分片时长为12秒，下载TS分片的总次数为10次，当前已下载的视频流的卡顿时长的累积时长为3秒，则计算出卡顿时长占比为 3/(10X12)＝2.5％；
本实施例提供的一种定位视频播放卡顿的方法适用于诸多视频软件评估视频播放卡顿的情况，如经验证已知的“云世界”视频软件的TS分片的播放时长为10S，“腾讯视频”视频软件的TS分片的播放时长为12S，“咪咕视频”视频软件的TS分片的播放时长为10S，“乐视”视频软件的TS分片的播放时长为10S。
利用本实施例提供的方法对视频播放卡顿情况进行评估时，直接通过视频流的视频流分片数据包的相关信息，计算上述视频流的实际播放时长和理论播放时长，并根据计算结果判断是否存在视频播放卡顿现象，能够精确地评估视频播放卡顿的情况，且上述方法易于实施。
本实施例提供的方案中，通过基于视频流的码流特征解码，依据视频流分片特征，提出的视频播放卡顿评估方法，与通过向视频播放软件APP开发公司获取埋码规则，或者通过在视频播放软件APP进行软件开发工具包SDK植入形式而言，更具有通用性，且现有的主流视频约80％采用视频流切片形式进行下载和播放，均可使用本实施例提供的方法。
本实施例提供发单方法与使用采集层视频分片打点形式进行视频播放卡顿评估而言，实现简单，不需要对采集层、共享层规则修改，不需要进行解码视频码率等复杂操作，在现有共享层基础上方便快速部署实现，并且定位卡顿准确性和上述方式相比无明显差别。
本实施例提供的方法，可应用于实时监控单/多用户观看视频业务时产生卡顿的情况，指导相关网络优化方案实施，保障用户实时观看时获取良好的感知，同时也可以用于单/多用户视频业务卡顿情况的统计分析，评估用户或网络等多个维度的视频业务感知。
实施例二：
本实施例在实施例一的基础上，对上述一种定位视频播放卡顿的方法进行优化，适用于视频实际播放过程中会存在视频正片前的广告播放(有广告缓存时)、视频发生拖拽进度、视频暂停等情况；
在本实施例中，采用如下方法对定位视频流的实际播放时长进行修正：
将定位视频流的最新视频流分片数据包开始下载的时间点减去初始视频流分片数据包开始下载的时间点，再根据视频播放卡顿修正值确定上述定位视频流的实际播放时长。
其中一种可能的实施方式如下：
实际播放时长＝(第N+1个的分片包TCP流开始时间)-(第1个的分片包TCP流开始时间)-视频播放卡顿修正值；
在实施中，通过以下任一或任多方式确定上述视频播放卡顿修正值：
将缓存的穿插到定位视频流中进行播放的冗余视频流的实际播放时长，确定为上述视频播放卡顿修正值；
将定位视频流中在播放过程中暂停播放的时长，确定为上述视频播放卡顿修正值。
在实施中还包括：确定上述定位视频流在播放过程中发生拖拽事件时，将发生拖拽事件后的最新的视频流分片数据包作为定位视频流的起始视频流分片数据包，重新触发定位视频播放卡顿。
以下给出一种对定位视频流的实际播放时长进行修正的具体实施方式：
(1)针对于存在视频正片前的广告播放(即有广告缓存时)：
实际播放时长＝(第N+1的分片包TCP流开始时间)-(第1个的分片包TCP流开始时间)-缓存的广告的实际播放时长(即视频播放卡顿修正值)；
在实施中，对上述广告播放也要按照视频流分片数据包，计算上述广告播放的实际播放时长和理论播放时长；即实际视频播放过程时，会存在广告，在广告播放期间，视频正片分片会进行下载缓存，所以在视频播放卡顿计算时，广告分片也要按照定位视频流的计算方式进行计算。
在具体的实施中，当视频播放软件在本地无上述广告播放的广告缓存时，直接按照视频流分片数据包，计算上述广告播放的实际播放时长和理论播放时长，并根据计算结果判断是否存在视频播放卡顿现象；
当视频播放软件在本地存有上述广告播放的广告缓存时，需要识别出广告播放的开始时间点和结束时间点，进而计算出上述广告缓存的实际播放时长；
此处以腾讯视频的广告为例，给出视频播放软件“腾讯视频”的广告播放的视频流分片数据包的识别规则如下：
A、通过HTTP get，第1个“/”后，域名为variety.tc.qq.com，或vlive.qqvideo.tc.qq.com，第3个“/”后第3个“.”为“mp4”；
B、并且有http返回状态为200或者206的；
C、并且Content-Type:video/mp4；
同时满足上述A、B和C条件的视频流分片数据包为“腾讯视频”的广告播放的视频流分片数据包；
如图2A的广告信令截图所示，为variety.tc.qq.com、vlive.qqvideo.tc.qq.com的广告地址。
实际测验得，腾讯视频的每个广告分片数据包的播放时长为15S，在有本地缓存的广告时，在计算定位视频流的实际播放时长时需要减去已缓存的广告的实际播放时长；在评估计算视频卡顿情况时，将发生卡顿的下一个视频流分片数据包作为新的起始视频流分片数据包，重新进行实际播放时长的计算。
如图2B所示，是腾讯视频进行视频播放卡顿评估时的一组测试计算结果：
A、卡顿次数占比＝当前已下载的视频流的卡顿的累积次数/当前定位视频播放卡顿总次数；
如图2B所示，下载TS分片15次，广告分片5次，那么按照XDR 20条(实际18条XDR，有2条由于APP有广告缓存，没有重新下载)，其中发送卡顿的次数为2次，那么计算得到卡顿次数占比为2/20＝10％；
B、卡顿时长占比＝(当前已下载的视频流的卡顿时长的累积时长)/{(当前定位视频播放卡顿的总次数)X(视频流分片时长)}；
如图2B所示，下载TS分片15次，广告分片5次，15个TS分片的每个分片的播放时间为12秒，5个广告分片的每个分片播放时长是15s，总的视频时长为15x12+5x15＝255秒，其中发生卡顿的视频的总时长为25秒，那么计算得到卡顿时间占比为25/255＝9.8％；
(2)针对存在视频暂停情况时：
实际播放时长＝(第N+1的分片包TCP流开始时间)-(第1个的分片包 TCP流开始时间)-暂停播放时长(即视频播放卡顿修正值)；
在视频播放暂停后，还存在视频缓存下载情况时，在实际的评估视频播放卡顿情况时，视频播放暂停的时间需要从实际播放时长中(对应图2B的表中的卡顿时长列)减去；
在实际的实施过程中，为排除暂停时间影响，视频播放暂停后的前一个视频流分片数据包开始对累计下载时长减去暂停的时长。
上述暂停的时长可通过以下方式获取：即暂停结束后出现的第一个POST /mkvcollect HTTP/1.1为开始播放标志，其对应的“TCP/UDP流开始时间”减去暂停开始对应“TCP/UDP流开始时间”。
在图2C中，卡顿时长，即视频可播放时长，数值为负值，标识发生卡顿的值的大小就是卡顿的时长。
如图2D所示，以下给出一个上述广告播放及视频暂停播放标志位的识别规则如下(此处以“腾讯视频”的广告播放及视频播放暂停标志位的识别规则为例)：
A、出现GET/irt，通过HTTP GET流程中包含/irt；
B、_iwt_vid1＝g00264yfk8m；_iwt_vid1后为广告结束后视频正片的文件名；
C、并且出现Host:qq.irs01.com；
D、且出现Content-Type:text/javascript；
E、http返回状态为200或者206；
同时出现上述A、B、C、D和E情况时，确定当前为广告开始播放/视频正片开始播放/视频播放暂停的标志位；
如图2E所示，视频播放暂停结束后出现的第一个POST/mkvcollect HTTP/1.1为视频播放开始的标志。
(3)针对视频发生拖拽进度的情况：
如图2F，此处以腾讯视频的视频播放为例，视频播放软件“腾讯视频”的发生拖拽进度的视频流分片数据包的识别规则如下：
A、通过HTTP GET，GET后第1个“/”和第2个“/”间内容为video_caps；
B、并且Host：puui.qpic.cn；
C、并且有http返回状态为200或者206的；
D、并且Content-Type:image/webp；
同时满足上述A、B、C和D条件的视频流分片数据包为“腾讯视频”的发生拖拽进度的视频流分片数据包。
HTTP get，get后第3个“/”和其后的第1个“.”间内容和对应视频分片文件名一样。
在实施中，将定位视频流的实际播放时长和理论播放时长清零，并将发生拖拽事件后的最新的视频流分片数据包作为定位视频流的起始视频流分片数据包，重新触发定位视频播放卡顿。
对于同一组视频源，视频播放中间发生拖拽情况时，需按照从第一个分片开始到第一次拖拽TCP会话之前的分片作为一组视频流，进行卡顿计算。而最后一次拖拽返回http状态为200或者206的完成时间后，产生的新的ts分片时间开始作为下一组视频分片组，进行评估计算视频播放卡顿的情况；
如图2G，No.＝58830属于拖拽的一组TCP会话流，No.＝72858属于拖拽的另一组TCP会话流，而在之后并没有ts视频分片下载，而在No.＝73276最后一次拖拽的TCP会话流之后会有ts视频分片下载，此种情况把拖拽间隙(约为3分26秒)没有下载视频分片时间算到评估计算视频播放卡顿的情况中，会影响计算准确性。
实施例三：
如图3A所示，本实施例提供一种定位视频播放卡顿的第一设备，该设备包括处理器301和收发机302；
上述处理器用于利用收发机确定触发定位视频播放卡顿时，根据定位视频流的视频流分片数据包的时间信息，确定上述定位视频流的实际播放时长；
根据上述定位视频流的视频流分片数据包中的最新视频流分片数据包，确定上述定位视频流的理论播放时长；
通过比较上述定位视频流的实际播放时长和理论播放时长，确定是否存在视频播放卡顿现象。
在实施中，上述定位视频流的起始视频流分片数据包为最近一次定位视频播放发生卡顿的视频流分片数据包的下一个视频流分片数据包。
在实施中，初次触发定位视频播放卡顿时，上述定位视频流的起始视频流分片数据包为下载的第一个视频流分片数据包。
上述定位视频流的最新视频流分片数据包为请求下载的第N+1个视频流分片数据包；N为当前下载完的视频流分片数据包的个数。
可选地，上述处理器具体用于，根据上述定位视频流中的最新视频流分片数据包开始下载的时间点，及上述定位视频流中初始视频流分片数据包开始下载的时间点，确定上述定位视频流的实际播放时长。
上述最新视频流分片数据包和初始视频流分片数据包开始下载的时间点，分别通过请求下载上述最新视频流分片数据包和初始视频流分片数据包的请求信息的信息记录获取。
可选地，上述处理器具体用于，将上述定位视频流的视频流分片时长，乘以上述定位视频流的视频流分片数据包的总个数，确定上述定位视频流的理论播放时长。
上述处理器具体用于：若上述定位视频流的实际播放时长小于/等于理论播放时长，则确定上述定位视频流不存在视频播放卡顿现象；
若上述定位视频流的实际播放时长大于理论播放时长，则确定上述定位视频流存在视频播放卡顿现象。
可选地，上述处理器还用于，将上述定位视频流的实际播放时长和理论播放时长置零；将发生视频播放卡顿的视频流分片数据包的下一个视频流分片数据包作为起始视频流分片数据包，重新触发定位视频播放卡顿。
上述处理器还用于，对上述定位视频流做视频播放卡顿参数评估。
上述处理器具体用于，将当前已下载的视频流的卡顿的累积次数，除以当前已下载的定位视频流的视频流分片数据包总数作为当前已下载的定位视频流的卡顿次数占比；
将当前已下载的视频流的卡顿时长的累积时长，除以当前已下载的定位视频流的视频流分片数据包总数与上述视频流分片时长之积的结果作为当前已下载的视频流的卡顿时长占比。
上述处理器具体用于通过如下方式获得上述当前已下载的视频流的卡顿时长：确定上述视频流的理论播放时长与实际播放时长差值的绝对值为上述视频流的卡顿时长。
上述处理器具体用于，将上述定位视频流的最新视频流分片数据包开始下载的时间点减去上述初始视频流分片数据包开始下载的时间点的结果，作为上述定位视频流的实际播放时长；或者
将上述定位视频流的最新视频流分片数据包开始下载的时间点减去上述初始视频流分片数据包开始下载的时间点，再根据视频播放卡顿修正值确定上述定位视频流的实际播放时长。
上述处理器具体用于通过以下任一或任多方式确定上述视频播放卡顿修正值：
将缓存的穿插到定位视频流中进行播放的冗余视频流的实际播放时长，确定为上述视频播放卡顿修正值；
将定位视频流中在播放过程中暂停播放的时长，确定为上述视频播放卡顿修正值。
上述处理器还用于，确定上述定位视频流在播放过程中发生拖拽事件时，将发生拖拽事件后的最新的视频流分片数据包作为定位视频流的起始视频流分片数据包，重新触发定位视频播放卡顿。
如图3B所示，本发明实施例还提供一种定位视频播放卡顿的第二设备，该设备包括：至少一个处理单元303、以及至少一个存储单元304，其中，上述存储单元304存储有程序代码，当上述程序代码被上述处理单元303执行时，使得上述处理单元303执行下列过程：
确定触发定位视频播放卡顿时，根据定位视频流的视频流分片数据包的时间信息，确定上述定位视频流的实际播放时长；
根据上述定位视频流的视频流分片数据包中的最新视频流分片数据包，确定上述定位视频流的理论播放时长；
通过比较上述定位视频流的实际播放时长和理论播放时长，确定是否存在视频播放卡顿现象。
由于该设备即是本发明实施例中的方法中的设备，并且该设备解决问题的原理与该方法相似，因此该设备的实施可以参见方法的实施，重复之处不再赘述。
实施例四：
本实施例提供一种定位视频播放卡顿的第三设备，如图4所示，该设备包括：
实际播放时长确定单元401，用于确定触发定位视频播放卡顿时，根据定位视频流的视频流分片数据包的时间信息，确定上述定位视频流的实际播放时长；
理论播放时长确定单元402，用于根据上述定位视频流的视频流分片数据包中的最新视频流分片数据包，确定上述定位视频流的理论播放时长；
视频播放卡顿评估单元403，用于通过比较上述定位视频流的实际播放时长和理论播放时长，确定是否存在视频播放卡顿现象。
在实施中，上述定位视频流的起始视频流分片数据包为最近一次定位视频播放发生卡顿的视频流分片数据包的下一个视频流分片数据包。
在实施中，初次触发定位视频播放卡顿时，上述定位视频流的起始视频流分片数据包为下载的第一个视频流分片数据包。
上述定位视频流的最新视频流分片数据包为请求下载的第N+1个视频流分片数据包；
N为当前下载完的视频流分片数据包的个数。
可选地，上述实际播放时长确定单元，用于根据上述定位视频流中的最新视频流分片数据包开始下载的时间点，及上述定位视频流中初始视频流分片数据包开始下载的时间点，确定上述定位视频流的实际播放时长。
上述最新视频流分片数据包和初始视频流分片数据包开始下载的时间点，分别通过请求下载上述最新视频流分片数据包和初始视频流分片数据包的请求信息的信息记录获取。
可选地，上述理论播放时长确定单元，用于将上述定位视频流的视频流分片时长，乘以上述定位视频流的视频流分片数据包的总个数，确定上述定位视频流的理论播放时长。
上述视频播放卡顿评估单元用于，若上述定位视频流的实际播放时长小于/等于理论播放时长，则确定上述定位视频流不存在视频播放卡顿现象；
若上述定位视频流的实际播放时长大于理论播放时长，则确定上述定位视频流存在视频播放卡顿现象。
可选地，上述视频播放卡顿评估单元还用于，将上述定位视频流的实际播放时长和理论播放时长置零；将发生视频播放卡顿的视频流分片数据包的下一个视频流分片数据包作为起始视频流分片数据包，重新触发定位视频播放卡顿。
上述视频播放卡顿评估单元还用于，对上述定位视频流做视频播放卡顿参数评估。
上述视频播放卡顿评估单元用于，将当前已下载的视频流的卡顿的累积次数，除以当前已下载的定位视频流的视频流分片数据包总数作为当前已下载的定位视频流的卡顿次数占比；
将当前已下载的视频流的卡顿时长的累积时长，除以当前已下载的定位视频流的视频流分片数据包总数与上述视频流分片时长之积的结果作为当前已下载的视频流的卡顿时长占比。
上述视频播放卡顿评估单元用于通过如下方式获得上述当前已下载的视频流的卡顿时长：确定上述视频流的理论播放时长与实际播放时长差值的绝对值为上述视频流的卡顿时长。
上述实际播放时长确定单元用于，将上述定位视频流的最新视频流分片数据包开始下载的时间点减去上述初始视频流分片数据包开始下载的时间点的结果，作为上述定位视频流的实际播放时长；或者
将上述定位视频流的最新视频流分片数据包开始下载的时间点减去上述初始视频流分片数据包开始下载的时间点，再根据视频播放卡顿修正值确定上述定位视频流的实际播放时长。
上述实际播放时长确定单元用于通过以下任一或任多方式确定上述视频播放卡顿修正值：
将缓存的穿插到定位视频流中进行播放的冗余视频流的实际播放时长，确定为上述视频播放卡顿修正值；
将定位视频流中在播放过程中暂停播放的时长，确定为上述视频播放卡顿修正值。
上述实际播放时长确定单元还用于，确定上述定位视频流在播放过程中发生拖拽事件时，将发生拖拽事件后的最新的视频流分片数据包作为定位视频流的起始视频流分片数据包，重新触发定位视频播放卡顿。
实施例五：
本实施例提供一种计算机可读非易失性存储介质，包括程序代码，当上述程序代码在计算终端上运行时，上述程序代码用于使所述计算终端执行上述本发明实施例一和实施例二提供的一种定位视频播放卡顿的方法的步骤。
以上参照示出根据本申请实施例的方法、装置(系统)和/或计算机程序产品的框图和/或流程图描述本申请。应理解，可以通过计算机程序指令来实现框图和/或流程图示图的一个块以及框图和/或流程图示图的块的组合。可以将这些计算机程序指令提供给通用计算机、专用计算机的处理器和/或其它可编程数据处理装置，以产生机器，使得经由计算机处理器和/或其它可编程数据处理装置执行的指令创建用于实现框图和/或流程图块中所指定的功能/动作的方法。
相应地，还可以用硬件和/或软件(包括固件、驻留软件、微码等)来实施本申请。更进一步地，本申请可以采取计算机可使用或计算机可读存储介质上的计算机程序产品的形式，其具有在介质中实现的计算机可使用或计算机可读程序代码，以由指令执行系统来使用或结合指令执行系统而使用。在本申请上下文中，计算机可使用或计算机可读介质可以是任意介质，其可以包含、存储、通信、传输、或传送程序，以由指令执行系统、装置或设备使用，或结合指令执行系统、装置或设备使用。
显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。

Claims (32)

1.一种定位视频播放卡顿的方法，其特征在于，该方法包括：
确定触发定位视频播放卡顿时，根据定位视频流的视频流分片数据包的时间信息，确定所述定位视频流的实际播放时长；
根据所述定位视频流的视频流分片数据包中的最新视频流分片数据包，确定所述定位视频流的理论播放时长；
通过比较所述定位视频流的实际播放时长和理论播放时长，确定是否存在视频播放卡顿现象。
2.如权利要求1所述的方法，其特征在于，所述定位视频流的起始视频流分片数据包为最近一次定位视频播放发生卡顿的视频流分片数据包的下一个视频流分片数据包。
3.根据权利要求2所述的方法，其特征在于，初次触发定位视频播放卡顿时，所述定位视频流的起始视频流分片数据包为下载的第一个视频流分片数据包。
4.根据权利要求1所述的方法，其特征在于，所述定位视频流的最新视频流分片数据包为请求下载的第N+1个视频流分片数据包，N为当前下载完的视频流分片数据包的个数。
5.如权利要求1-4任一所述的方法，其特征在于，根据所述定位视频流的视频流分片数据包的时间信息，确定所述定位视频流的实际播放时长，包括：
根据所述定位视频流中的最新视频流分片数据包开始下载的时间点，及所述定位视频流中初始视频流分片数据包开始下载的时间点，确定所述定位视频流的实际播放时长。
6.如权利要求5所述的方法，其特征在于，所述最新视频流分片数据包和初始视频流分片数据包开始下载的时间点，分别通过请求下载所述最新视频流分片数据包和初始视频流分片数据包的请求信息的信息记录获取。
7.如权利要求1-4任一所述的方法，其特征在于，根据所述定位视频流的视频流分片数据包中的最新视频流分片数据包，确定所述定位视频流的理论播放时长，包括：
将所述定位视频流的视频流分片时长，乘以所述定位视频流的视频流分片数据包的总个数，确定所述定位视频流的理论播放时长。
8.如权利要求1-4任一所述的方法，其特征在于，通过比较所述定位视频流的实际播放时长和理论播放时长，确定是否存在视频播放卡顿现象，包括：
若所述定位视频流的实际播放时长小于/等于理论播放时长，则确定所述定位视频流不存在视频播放卡顿现象；
若所述定位视频流的实际播放时长大于理论播放时长，则确定所述定位视频流存在视频播放卡顿现象。
9.如权利要求1-4任一所述的方法，其特征在于，确定所述定位视频流存在视频播放卡顿现象之后，还包括：
将所述定位视频流的实际播放时长和理论播放时长置零；
将发生视频播放卡顿的视频流分片数据包的下一个视频流分片数据包作为起始视频流分片数据包，重新触发定位视频播放卡顿。
10.如权利要求1-4任一所述的方法，其特征在于，确定所述定位视频流存在视频播放卡顿现象之后，还包括：
对所述定位视频流做视频播放卡顿参数评估。
11.根据权利要求10所述的方法，其特征在于，对所述定位视频流做视频播放卡顿参数评估，包括：
将当前已下载的视频流的卡顿的累积次数，除以当前已下载的定位视频流的视频流分片数据包总数作为当前已下载的定位视频流的卡顿次数占比；
将当前已下载的视频流的卡顿时长的累积时长，除以当前已下载的定位视频流的视频流分片数据包总数与所述视频流分片时长之积的结果作为当前已下载的视频流的卡顿时长占比。
12.如权利要求11所述的方法，其特征在于，通过如下方式获得所述当前已下载的视频流的卡顿时长：
确定所述视频流的理论播放时长与实际播放时长差值的绝对值为所述视频流的卡顿时长。
13.如权利要求5所述的方法，其特征在于，根据所述定位视频流中的最新视频流分片数据包开始下载的时间点，及所述定位视频流中初始视频流分片数据包开始下载的时间点，确定所述定位视频流的实际播放时长，包括：
将所述定位视频流的最新视频流分片数据包开始下载的时间点减去所述初始视频流分片数据包开始下载的时间点的结果，作为所述定位视频流的实际播放时长；或者
将所述定位视频流的最新视频流分片数据包开始下载的时间点减去所述初始视频流分片数据包开始下载的时间点，再根据视频播放卡顿修正值确定所述定位视频流的实际播放时长。
14.如权利要求13所述的方法，其特征在于，通过以下任一或任多方式确定所述视频播放卡顿修正值：
将缓存的穿插到定位视频流中进行播放的冗余视频流的实际播放时长，确定为所述视频播放卡顿修正值；
将定位视频流中在播放过程中暂停播放的时长，确定为所述视频播放卡顿修正值。
15.如权利要求1所述的方法，其特征在于，还包括：
确定所述定位视频流在播放过程中发生拖拽事件时，将发生拖拽事件后的最新的视频流分片数据包作为定位视频流的起始视频流分片数据包，重新触发定位视频播放卡顿。
16.一种定位视频播放卡顿的设备，其特征在于，该设备包括：处理器以及收发机：
所述处理器：用于利用收发机确定触发定位视频播放卡顿时，根据定位视频流的视频流分片数据包的时间信息，确定所述定位视频流的实际播放时长；
根据所述定位视频流的视频流分片数据包中的最新视频流分片数据包，确定所述定位视频流的理论播放时长；
通过比较所述定位视频流的实际播放时长和理论播放时长，确定是否存在视频播放卡顿现象。
17.如权利要求16所述的设备，其特征在于，所述定位视频流的起始视频流分片数据包为最近一次定位视频播放发生卡顿的视频流分片数据包的下一个视频流分片数据包。
18.根据权利要求17所述的设备，其特征在于，初次触发定位视频播放卡顿时，所述定位视频流的起始视频流分片数据包为下载的第一个视频流分片数据包。
19.根据权利要求16所述的设备，其特征在于，所述定位视频流的最新视频流分片数据包为请求下载的第N+1个视频流分片数据包；N为当前下载完的视频流分片数据包的个数。
20.如权利要求16-19任一所述的设备，其特征在于，所述处理器具体用于：
根据所述定位视频流中的最新视频流分片数据包开始下载的时间点，及所述定位视频流中初始视频流分片数据包开始下载的时间点，确定所述定位视频流的实际播放时长。
21.如权利要求20所述的设备，其特征在于，所述最新视频流分片数据包和初始视频流分片数据包开始下载的时间点，分别通过请求下载所述最新视频流分片数据包和初始视频流分片数据包的请求信息的信息记录获取。
22.如权利要求16-19任一所述的设备，其特征在于，所述处理器具体用于：
将所述定位视频流的视频流分片时长，乘以所述定位视频流的视频流分片数据包的总个数，确定所述定位视频流的理论播放时长。
23.如权利要求16-19任一所述的设备，其特征在于，所述处理器具体用于：若所述定位视频流的实际播放时长小于/等于理论播放时长，则确定所述定位视频流不存在视频播放卡顿现象；
若所述定位视频流的实际播放时长大于理论播放时长，则确定所述定位视频流存在视频播放卡顿现象。
24.如权利要求16-19任一所述的设备，其特征在于，所述处理器还用于：
将所述定位视频流的实际播放时长和理论播放时长置零；
将发生视频播放卡顿的视频流分片数据包的下一个视频流分片数据包作为起始视频流分片数据包，重新触发定位视频播放卡顿。
25.如权利要求16-19任一所述的设备，其特征在于，所述处理器还用于：
对所述定位视频流做视频播放卡顿参数评估。
26.根据权利要求25所述的设备，其特征在于，所述处理器具体用于：
将当前已下载的视频流的卡顿的累积次数，除以当前已下载的定位视频流的视频流分片数据包总数作为当前已下载的定位视频流的卡顿次数占比；
将当前已下载的视频流的卡顿时长的累积时长，除以当前已下载的定位视频流的视频流分片数据包总数与所述视频流分片时长之积的结果作为当前已下载的视频流的卡顿时长占比。
27.如权利要求26所述的设备，其特征在于，所述处理器具体用于通过如下方式获得所述当前已下载的视频流的卡顿时长：
确定所述视频流的理论播放时长与实际播放时长差值的绝对值为所述视频流的卡顿时长。
28.如权利要求20所述的设备，其特征在于，所述处理器具体用于：将所述定位视频流的最新视频流分片数据包开始下载的时间点减去所述初始视频流分片数据包开始下载的时间点的结果，作为所述定位视频流的实际播放时长；或者
将所述定位视频流的最新视频流分片数据包开始下载的时间点减去所述初始视频流分片数据包开始下载的时间点，再根据视频播放卡顿修正值确定所述定位视频流的实际播放时长。
29.如权利要求28所述的设备，其特征在于，所述处理器具体用于通过以下任一或任多方式确定所述视频播放卡顿修正值：
将缓存的穿插到定位视频流中进行播放的冗余视频流的实际播放时长，确定为所述视频播放卡顿修正值；
将定位视频流中在播放过程中暂停播放的时长，确定为所述视频播放卡顿修正值。
30.如权利要求16所述的设备，其特征在于，所述处理器还用于：
确定所述定位视频流在播放过程中发生拖拽事件时，将发生拖拽事件后的最新的视频流分片数据包作为定位视频流的起始视频流分片数据包，重新触发定位视频播放卡顿。
31.一种定位视频播放卡顿的设备，其特征在于，该设备包括：至少一个处理单元以及至少一个存储单元，其中，所述存储单元存储有程序代码，当所述程序代码被所述处理单元执行时，使得所述处理单元执行权利要求1～15任一所述方法的步骤。
32.一种计算机可存储介质，其上存储有计算机程序，其特征在于，该程序被处理器执行时实现如权利要求1～15任一所述方法的步骤。
CN201811544632.9A 2018-12-17 2018-12-17 一种定位视频播放卡顿的方法及设备 Active CN111327964B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201811544632.9A CN111327964B (zh) 2018-12-17 2018-12-17 一种定位视频播放卡顿的方法及设备

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201811544632.9A CN111327964B (zh) 2018-12-17 2018-12-17 一种定位视频播放卡顿的方法及设备

Publications (2)

Publication Number Publication Date
CN111327964A true CN111327964A (zh) 2020-06-23
CN111327964B CN111327964B (zh) 2022-11-25

Family

ID=71172438

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201811544632.9A Active CN111327964B (zh) 2018-12-17 2018-12-17 一种定位视频播放卡顿的方法及设备

Country Status (1)

Country Link
CN (1) CN111327964B (zh)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114845164A (zh) * 2021-02-02 2022-08-02 中国移动通信有限公司研究院 一种数据处理方法、装置及设备
CN115514684A (zh) * 2021-06-07 2022-12-23 中国移动通信集团北京有限公司 音频卡顿评估的方法及装置
CN116095056A (zh) * 2021-11-05 2023-05-09 中国移动通信集团河南有限公司 基于http和p2p传输的视频卡顿检测方法和装置

Citations (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104639955A (zh) * 2015-03-09 2015-05-20 德科仕通信(上海)有限公司 检测mpeg2-ts vbr码流质量问题的方法
CN104702563A (zh) * 2013-12-06 2015-06-10 乐视网信息技术（北京）股份有限公司 流媒体播放时长的获取方法和装置
CN104735473A (zh) * 2015-03-05 2015-06-24 天脉聚源（北京）科技有限公司 一种视频流播放的检测方法及装置
CN104937899A (zh) * 2014-01-22 2015-09-23 华为技术有限公司 一种评估音视频业务质量的方法及装置
CN104967894A (zh) * 2014-09-04 2015-10-07 腾讯科技（深圳）有限公司 视频播放的数据处理方法及客户端、服务器
CN105553939A (zh) * 2015-12-07 2016-05-04 中国联合网络通信集团有限公司 一种流媒体卡顿的确定方法及装置
CN105578258A (zh) * 2015-12-11 2016-05-11 浙江大华技术股份有限公司 一种视频预处理和视频回放的方法及装置
CN106254902A (zh) * 2016-08-19 2016-12-21 恒安嘉新(北京)科技有限公司 一种基于移动互联网视频用户感知和分析的方法及系统
CN106482707A (zh) * 2016-10-21 2017-03-08 上海建工集团股份有限公司 自行式循迹测斜装置及方法
WO2017092336A1 (zh) * 2015-12-01 2017-06-08 乐视控股（北京）有限公司 一种流媒体的处理方法及装置
CN106817619A (zh) * 2016-12-26 2017-06-09 江苏省公用信息有限公司 一种识别视频暂停状态，提高ott视频质量监测精度的方法
CN106961632A (zh) * 2017-04-12 2017-07-18 四川九鼎瑞信软件开发有限公司 视频质量分析方法及装置
US20170324998A1 (en) * 2015-05-26 2017-11-09 Tencent Technology (Shenzhen) Company Limited Method for playing video, client, and computer storage medium
CN108235149A (zh) * 2016-12-21 2018-06-29 中国移动通信集团公司 一种优化视频播放流畅度的方法及装置
CN108270738A (zh) * 2016-12-30 2018-07-10 北京华为数字技术有限公司 一种视频处理方法及网络设备
CN108347598A (zh) * 2018-01-25 2018-07-31 晶晨半导体(上海)股份有限公司 一种音视频卡顿信息自动检测上报系统及方法

Patent Citations (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104702563A (zh) * 2013-12-06 2015-06-10 乐视网信息技术（北京）股份有限公司 流媒体播放时长的获取方法和装置
CN104937899A (zh) * 2014-01-22 2015-09-23 华为技术有限公司 一种评估音视频业务质量的方法及装置
CN104967894A (zh) * 2014-09-04 2015-10-07 腾讯科技（深圳）有限公司 视频播放的数据处理方法及客户端、服务器
CN104735473A (zh) * 2015-03-05 2015-06-24 天脉聚源（北京）科技有限公司 一种视频流播放的检测方法及装置
CN104639955A (zh) * 2015-03-09 2015-05-20 德科仕通信(上海)有限公司 检测mpeg2-ts vbr码流质量问题的方法
US20170324998A1 (en) * 2015-05-26 2017-11-09 Tencent Technology (Shenzhen) Company Limited Method for playing video, client, and computer storage medium
WO2017092336A1 (zh) * 2015-12-01 2017-06-08 乐视控股（北京）有限公司 一种流媒体的处理方法及装置
CN105553939A (zh) * 2015-12-07 2016-05-04 中国联合网络通信集团有限公司 一种流媒体卡顿的确定方法及装置
CN105578258A (zh) * 2015-12-11 2016-05-11 浙江大华技术股份有限公司 一种视频预处理和视频回放的方法及装置
CN106254902A (zh) * 2016-08-19 2016-12-21 恒安嘉新(北京)科技有限公司 一种基于移动互联网视频用户感知和分析的方法及系统
CN106482707A (zh) * 2016-10-21 2017-03-08 上海建工集团股份有限公司 自行式循迹测斜装置及方法
CN108235149A (zh) * 2016-12-21 2018-06-29 中国移动通信集团公司 一种优化视频播放流畅度的方法及装置
CN106817619A (zh) * 2016-12-26 2017-06-09 江苏省公用信息有限公司 一种识别视频暂停状态，提高ott视频质量监测精度的方法
CN108270738A (zh) * 2016-12-30 2018-07-10 北京华为数字技术有限公司 一种视频处理方法及网络设备
CN106961632A (zh) * 2017-04-12 2017-07-18 四川九鼎瑞信软件开发有限公司 视频质量分析方法及装置
CN108347598A (zh) * 2018-01-25 2018-07-31 晶晨半导体(上海)股份有限公司 一种音视频卡顿信息自动检测上报系统及方法

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114845164A (zh) * 2021-02-02 2022-08-02 中国移动通信有限公司研究院 一种数据处理方法、装置及设备
CN115514684A (zh) * 2021-06-07 2022-12-23 中国移动通信集团北京有限公司 音频卡顿评估的方法及装置
CN115514684B (zh) * 2021-06-07 2023-11-10 中国移动通信集团北京有限公司 音频卡顿评估的方法及装置
CN116095056A (zh) * 2021-11-05 2023-05-09 中国移动通信集团河南有限公司 基于http和p2p传输的视频卡顿检测方法和装置

Also Published As

Publication number Publication date
CN111327964B (zh) 2022-11-25

Similar Documents

Publication Publication Date Title
Krishnamoorthi et al. BUFFEST: Predicting buffer conditions and real-time requirements of HTTP (S) adaptive streaming clients
US20230127341A1 (en) Methods and apparatus to credit media presentations for online media distributions
US11277662B2 (en) Methods and apparatus to measure exposure to streaming media
Dimopoulos et al. Measuring video QoE from encrypted traffic
CN109474854B (zh) 视频播放方法、播放列表的生成方法及相关设备
EP3313043B1 (en) System and method for determining quality of a media stream
Wei et al. Low latency live video streaming over HTTP 2.0
US11290778B2 (en) Determining a quality of experience metric based on uniform resource locator data
Hoßfeld et al. Internet video delivery in YouTube: From traffic measurements to quality of experience
US9521179B2 (en) Validation of live media stream based on predetermined standards
Ameigeiras et al. Analysis and modelling of YouTube traffic
CN111327964B (zh) 一种定位视频播放卡顿的方法及设备
CN109587521B (zh) 视频卡顿的判定方法及装置
JP5780684B2 (ja) コンテンツ再生情報推定装置及び方法及びプログラム
WO2016053370A1 (en) Methods and apparatus to measure exposure to streaming media
JP2017529726A (ja) ストリーミングサービスのためのクライアント及びサーバの動作方法
JP6132116B2 (ja) ビデオ品質のユーザ体験値を評価するための方法、デバイス、及びシステム
Chen et al. A study of user behavior in online VoD services
US11095699B1 (en) Streaming media file management
CN105100172A (zh) 一种http协议的缓存状态更新方法和设备、处理机
CN109981550B (zh) 一种游戏业务质量评估方法及装置
Szilágyi et al. Network side lightweight and scalable YouTube QoE estimation
WO2015132222A1 (en) Method to determine re-buffering events in video sessions
CN115514684B (zh) 音频卡顿评估的方法及装置
AT&T LinLibertineT

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant