CN115767143A - 播放卡顿的判断方法、装置、电子设备和可读存储介质 - Google Patents

播放卡顿的判断方法、装置、电子设备和可读存储介质 Download PDF

Info

Publication number
CN115767143A
CN115767143A CN202211166837.4A CN202211166837A CN115767143A CN 115767143 A CN115767143 A CN 115767143A CN 202211166837 A CN202211166837 A CN 202211166837A CN 115767143 A CN115767143 A CN 115767143A
Authority
CN
China
Prior art keywords
time
sequence number
receiver
media object
transmission
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.)
Pending
Application number
CN202211166837.4A
Other languages
English (en)
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.)
Alibaba China Co Ltd
Original Assignee
Alibaba China 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 Alibaba China Co Ltd filed Critical Alibaba China Co Ltd
Priority to CN202211166837.4A priority Critical patent/CN115767143A/zh
Publication of CN115767143A publication Critical patent/CN115767143A/zh
Pending legal-status Critical Current

Links

Images

Landscapes

  • Communication Control (AREA)

Abstract

本申请公开了播放卡顿的判断方法、装置、电子设备和可读存储介质,该方法包括:获取待传输的媒体对象;获取将所述媒体对象发送给接收方的传输速度,其中,所述传输速度为单位时间内发送的数据量,所述接收方用于对接收到的媒体对象进行播放;获取所述媒体对象的平均码率;根据所述传输速度与所述平均码率判断所述接收方在对接收到的媒体对象进行播放时是否出现卡顿。通过本申请解决了现有技术中CDN的提供方无法获知其发送的多媒体文件在播放时是否会存在卡顿所导致的问题,进而能够预测到用户在播放多媒体文件所出现的卡顿,为多媒体文件传输的优化提供了数据支持。

Description

播放卡顿的判断方法、装置、电子设备和可读存储介质
技术领域
本申请涉及到多媒体处理领域,具体而言,涉及播放卡顿的判断方法、装置、电子设备和可读存储介质。
背景技术
内容分发网络(Content Delivery Network,简称为CDN)是构建在现有网络基础之上的用于进行内容分发的网络。内容分发网络通过负载均衡、资源调度等技术手段进行内容分发,使用户就近获取所需要的内容,降低网络拥塞,提高用户获取所需要的内容的速度。
随着技术的发展,用户越来越多通过网络来获取音频或者视频等多媒体内容,因此,在目前的CDN中,通过点播和直播等方式来进行音频或视频内容的传输是CDN中重要的流量分发场景,尤其是视频的点播和直播,据统计当前的视频点播流量约占CDN总流量的60%,视频直播流量约占CDN总流量的10%。
在音频或视频的传输和播放过程中,可能会出现卡顿,卡顿是影响用户使用的体验的重要原因之一。例如,在视频传输的场景中,视频服务提供方会使用CDN厂商(即CDN的提供方)来进行视频内容的分发,最终用户通过CDN厂商提供的分发服务之后来观看视频服务提供方所提供的视频。通常情况下,视频内容提供方通常采用视频播放卡顿率作为比较各家CDN厂商服务质量的指标。因此,提升视频传输的性能,降低用户的视频播放卡顿率成为了各个CDN厂商提升服务质量的关键。
然而,视频播放是在用户侧通过视频播放器来进行的,即在用户播放视频的时候才能感知到的一种现象。现有技术中解决视频卡顿的方法均是从用户一侧来进行解决的,例如,在播放多媒体文件时可以增加缓存以缓存更多的文件,这样可以利用播放缓存中的文件来争取到更多的文件下载时间,以减少视频播放的卡顿等。但是,对于CDN的提供方来说,其无法获得用户侧播放多媒体文件的卡顿数据,也无法从用户侧的角度来解决视频卡顿的问题,因此在现有技术中,CDN的提供方无法判断自身提供的多媒体文件分发方式是否会导致用户在播放时产生卡顿,从而也无法进行针对多媒体的分发进行优化。
发明内容
本申请实施例提供了播放卡顿的判断方法、装置、电子设备和可读存储介质,以至少解决现有技术中CDN的提供方无法获知其发送的多媒体文件在播放时是否会存在卡顿所导致的问题。
根据本申请的一个方面,提供了一种播放卡顿的判断方法,包括:获取待传输的媒体对象;获取将所述媒体对象发送给接收方的传输速度,其中,所述传输速度为单位时间内发送的数据量,所述接收方用于对接收到的媒体对象进行播放;获取所述媒体对象的平均码率;根据所述传输速度与所述平均码率判断所述接收方在对接收到的媒体对象进行播放时是否出现卡顿。
根据本申请的另一个方面,还提供了一种播放卡顿的判断装置,包括:第一获取模块,用于获取待传输的媒体对象;第二获取模块,用于获取将所述媒体对象发送给接收方的传输速度,其中,所述传输速度为单位时间内发送的数据量,所述接收方用于对接收到的媒体对象进行播放;第三获取模块,用于获取所述媒体对象的平均码率;判断模块,用于根据所述传输速度与所述平均码率判断所述接收方在对接收到的媒体对象进行播放时是否出现卡顿。
根据本申请的另一个方面,还提供了一种电子设备,包括存储器和处理器;其中,所述存储器用于存储一条或多条计算机指令,其中,所述一条或多条计算机指令被所述处理器执行以实现上述的方法步骤。
根据本申请的另一个方面,还提供了一种可读存储介质,其上存储有计算机指令,其中,该计算机指令被处理器执行时实现上述的方法步骤。
在本申请实施例中,采用了获取待传输的媒体对象;获取将所述媒体对象发送给接收方的传输速度,其中,所述传输速度为单位时间内发送的数据量,所述接收方用于对接收到的媒体对象进行播放;获取所述媒体对象的平均码率;根据所述传输速度与所述平均码率判断所述接收方在对接收到的媒体对象进行播放时是否出现卡顿。通过本申请解决了现有技术中CDN的提供方无法获知其发送的多媒体文件在播放时是否会存在卡顿所导致的问题,进而能够预测到用户在播放多媒体文件所出现的卡顿,为多媒体文件传输的优化提供了数据支持。
附图说明
构成本申请的一部分的附图用来提供对本申请的进一步理解,本申请的示意性实施例及其说明用于解释本申请,并不构成对本申请的不当限定。在附图中:
图1是根据本申请实施例的播放卡顿的判断方法的流程图;
图2是根据本申请实施例的基于TCP层数据报文预测卡顿的示意图;以及,
图3是根据本申请实施例的不同视频传输算法的卡顿预测结果比较示意图。
具体实施方式
需要说明的是,在不冲突的情况下,本申请中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本申请。
需要说明的是,在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行,并且,虽然在流程图中示出了逻辑顺序,但是在某些情况下,可以以不同于此处的顺序执行所示出或描述的步骤。
多媒体内容提供方用于向用户提供媒体对象(例如,音频文件或者视频文件),用户通过多媒体内容提供方所提供的获取方式来播放这些媒体对象。例如,多媒体内容提供方提供的是直播服务,用户可以通过多媒体内容提供方所提供的应用或者软件来浏览直播间,然后利用该应用或者软件中的多媒体播放器来播放媒体对象。又例如,多媒体内容提供方提供的是点播服务,用于可以通过浏览器访问多媒体内容提供方提供的网站,然后通过浏览器中的播放器来播放媒体对象。需要注意的是,由于用户浏览多媒体以及用户播放多媒体的行为均是通过多媒体内容提供方提供的服务来进行的,所以多媒体内容提供方可以收集播放器在播放视频时的数据,并根据这些数据判断视频播放是否会出现卡顿。但是,对于CDN提供方来说,其仅仅是负责了多媒体内容的分发,其无法从播放器的角度来收集数据,并且多媒体内容提供方也不会主动将收集到的数据提供给CDN提供方,这就导致了CDN提供方无法判断其分发多媒体文件的方式是否会导致在播放过程中产生卡顿,从而影响到CDN的服务质量。
多媒体文件播放卡顿的原因有多种,例如,播放器在对媒体对象进行解码时解码较慢所导致的播放卡顿,这种卡顿是由于播放器本身或者视频编解码所导致的,这种卡顿需要对播放器进行优化,因此以下实施方式中所能预测到的卡顿并不包括由于播放器本身原因所导致的卡顿。另一种多媒体文件播放产生的卡顿是由于文件传输所导致的,以点播方式播放一个视频文件为例,视频文件一般情况下文件尺寸都比较大,因此该视频文件无法在短时间内完全发送给用户进行播放,如果等待该视频文件全部传输完毕再进行播放,虽然在播放的过程中不会产生卡顿,但是用户需要等待较长的时间才能看到该视频。为了解决这个问题,视频文件会分块传输,在播放器接收到一部分视频文件之后就可以进行播放了,并且在播放的过程中可以继续接收视频文件,如果视频接收速度要大于播放速度,那么视频在播放的过程中就不会因为视频传输而产生卡顿。
对于CDN提供方而言,其提供了多媒体文件的分发,即发送多媒体文件的传输速度(也可以称为发送速度)是CDN可以获取到的,考虑到这一点可以根据发送速度来预测是否会产生卡顿,这与上述判断播放器一侧是否会产生卡顿的原理是相似的:在播放器中如果接收速度小于播放速度,在播放完所有的缓存之后,播放器就会停止播放来等待后续文件的接收,从而产生卡顿;CDN在发送多媒体文件时,如果单位时间发送的数据量小于播放器单位时间播放的数据量,则播放器必然产生卡顿。
基于上述原理,在以下实施例中提供了一种播放卡顿的判断方法,图1是根据本申请实施例的播放卡顿的判断方法的流程图,如图1所示,下面对图1示出的方法所包括的步骤进行说明。
步骤S102,获取待传输的媒体对象,例如,媒体对象可以包括音频文件或视频文件。
在该步骤中,接收方作为媒体对象的获取方,其会首先发送一个请求,发送方在接收到该请求之后,根据该请求向接收方传输分块的媒体对象(例如,视频文件或者音频文件),所以在该步骤中的待传输的媒体对象可以理解接收方发送请求之后,响应于该请求发送的分块的视频文件或者音频文件,即该待传输的媒体对象可以是一个完整视频文件或者完整音频文件的一部分,该完整视频文件或完整音频文件可以分为多次发送给接收方,每次发送的内容都可以理解为是该步骤中的待传输的媒体对象。
步骤S104,获取将所述媒体对象发送给接收方的传输速度(或者也可以称为发送速度),其中,所述传输速度为单位时间内发送的数据量,所述接收方用于对接收到的媒体对象进行播放。
在通过网络进行数据传输的过程中,发送方将数据发送给接收方,发送方发送的速度是发送速度,接收方接收的速度是接收速度,如果发送方和接收方之间的网络是理想化的、不会产生任何丢包或网络延迟的网络,则发送速度与接收速度相同,但是这种理想化的网络一般是不存在的,所以正常情况下,接收速度是要小于发送速度的。在该步骤内使用了发送方的传输速度,一方面是因为CDN提供方可以得到该速度,另一方面如果发送速度都无法满足播放要求的话,则必然会导致播放卡顿的出现。
步骤S106,获取所述媒体对象的平均码率。
在该步骤中涉及到平均码率,在介绍平均码率之前,首先对码率进行说明。媒体对象可以包括视频文件或音频文件,无论是视频文件还是音频文件其均是与时间相关的文件。下面以视频文件为例进行说明。码率可以理解为在该视频文件被播放时,以一倍速进行正常播放时每播放1秒钟所消耗的数据量。
码率可以根据视频的分辨率和帧率来进行计算。例如,4K分辨率的视频文件,其每帧的画面分辨率为4096*2160或者3840*2160。下面按照分辨率为3840*2160来进行计算。3860*2160的分辨率表示具有3860*2160个像素点,每个像素点有3个子像素(红、蓝、绿),每个子像素占8比特(bit),则一帧的数据量为3840*2160*8*3比特。如果帧率为60帧/每秒(fps),则每1秒内会有60帧被播放,即该秒内的播放图像所消耗的数据量为3840*2160*8*3*60≈12Gbps;而这个仅仅是图像,如果考虑到音轨大概占1/10,合计13G比特/每秒(bps),即这1秒内的码率为13G比特/每秒。需要说明的是,由于每一帧的图像内容不同,因此每一帧的大小均可能是不相同的,也就是说每1秒播放的数据量也可能是不相同的,即码率是在不断变化的。因此,如果使用码率来进行判断,则需要每1秒均需要计算码率并执行步骤S108的比较动作,这会消耗比较大的计算资源。
考虑到使用码率会消耗比较大的计算资源的问题,在该步骤中采用了平均码率,平均码率是该视频文件的码率的平均值,在一个可选实施方式中,平均码率可以根据视频文件的大小和视频文件的时长来进行计算,例如,一个视频文件的时长是N秒,该视频文件的大小是M比特,则该视频的平均码率为M比特/N秒。
步骤S108,根据所述传输速度与所述平均码率判断所述接收方在对接收到的媒体对象进行播放时是否出现卡顿。
在上述的步骤中,采用了向接收方发送文件时的传输速度作为判断卡顿的依据,该传输速度在发送方是可以获取到的,对于被发送出去的文件的码流在发送方也是可以获取到,因此,CDN提供方作为音频文件或视频文件的发送方可以获取到用于判断视频卡顿的发送速度和平均码率,然后根据发送速度和平均码率来判断接收方在播放时是否会出现卡顿,通过上述步骤CDN提供方不需要来自播放器的数据,根据自己作为发送方能够获取到的数据就可以预测出接收方在播放时是否会出现卡顿,从而解决了现有技术中CDN的提供方无法获知其发送的多媒体文件在播放时是否会存在卡顿所导致的问题,进而能够预测到用户在播放多媒体文件所出现的卡顿,为多媒体文件传输的优化提供了数据支持。
上述步骤中需要根据发送速度和平均码率来预测接收方在播放接收到的媒体对象时是否会出现卡顿,在步骤S106中已经描述了平均码率的计算方式,对于发送速度的计算,可以采用多种计算方式。例如,在开始发送所述媒体对象的时候就可以进行计时,然后在发送结束之后停止计时从而得到传输时间,然后根据待传输的媒体对象的大小和传输时间计算得到所述传输速度(即发送速度)。需要说明的是,在上述步骤S102中描述了该待传输的媒体对象可以是一个完整视频文件或者完整音频文件的一部分,由于该待传输的媒体对象可能是完整文件的一部分,因此,可能无法直接通过待传输媒体对象的文件属性来获取到待待传输媒体对象的大小,在这种情况下,作为另一个可选的方式,可以使用发送方发送的数据量作为传输速度的计算依据,即获取将所述媒体对象发送给所述接收方的传输速度可以包括如下步骤:获取所述媒体对象发送给所述接收方时向所述接收方传输的数据量;获取将所述媒体对象发送给所述接收方所用的传输时间;根据向所述接收方传输的数据量和所述传输时间计算得到所述传输速度。在该可选实施方式中,使用向接收方发送的数据量来计算发送速度,该数据量在发送方是能够获取到的,例如可以监控负责发送媒体对象的进程或者线程,并将该进程或线程发送的数据量作为向接收方发送的数据量;或者,还可以监控发送媒体对象所用的网络接口的数据量,将该通过该网络接口发送的数据量作为向接收方发送的数据量。
考虑到音频文件和视频文件均是按照网络传输协议构建成数据包之后发送出去的,为了获取更加准确向接收方传输的数据量,可以根据网络传输协议的性质来获取向接收方发送的数据量。在CDN网络中为了确保发送的数据包能够被接收方接收到,通常会使用传输控制协议(Transmission Control Protocol,简称为TCP)来进行数据包的发送,下面对TCP进行介绍。
互联网由一整套协议构成,该协议可以分为四层,数据链路层、网络层、传输层和应用层。其中,数据链路层用于实现网卡接口的网络驱动,以处理数据在以太网线等物理媒介上的传输,在数据链路层中隐藏了不同物理网络的不同电气特性,为上层协议提供一个统一的接口,例如,在以太网(Ethernet)中,数据链路层使用的是以太网协议。在网络中会使用路由器来连接分散的主机或者局域网,即通讯的两台主机一般不是直接连接,而是通过多个中间节点(路由器)连接的,从而形成网络拓扑连接。因此网络层用于确定两台主机间的通讯路径,即网络层对上层协议隐藏了网络拓扑连接的细节,在使得传输层看来通讯双方是直接连接的。在网络层中使用的核心协议为网络协议(Internet Protocol,简称为IP),因此,网络层也被称作是IP层。传输层的作用是为应用程序提供端对端通讯,即为应用程序隐藏了数据包跳转的细节,负责数据包的收发、链路超时重连等,网络层(也被称为TCP层)主要使用的协议为TCP协议和用户数据报协议(User Data-gram Protocol,简称为UDP),TCP协议为应用程序提供可靠的、面向连接的、基于流的服务,具有超时重传、数据确认等方式来确保数据包被正确发送到接收端,在CDN中主要使用了TCP协议;UDP协议与TCP协议相反,它为应用程序提供的是不可靠的、无连接的基于数据报的服务。应用层负责处理具体的操作逻辑,如文件传输、网络管理等。
TCP协议是以太网协议和IP协议的上层协议,也是应用层协议的下层协议。在以太网协议中规定了电子信号如何组成数据包,IP协议可以连接多个局域网,IP协议定义了一套自己的地址规则,称为IP地址。它实现了路由功能,允许某个局域网的A主机,向另一个局域网的B主机发送消息。IP协议只是一个地址协议,并不保证数据包的完整。如果路由器丢包,就需要发现丢了哪一个包,以及如何重新发送这个包。这就要依靠TCP协议。TCP协议的作用是,保证数据通信的完整性和可靠性,防止丢包。
以太网数据包的大小是固定的,最初是1518字节,后来增加到1522字节。其中,1500字节是负载(payload),22字节是头信息(head)。IP数据包在以太网数据包的负载里面,它也有自己的头信息,最少需要20字节,所以IP数据包的负载最多为1480字节。TCP数据包(也可以称为TCP层数据报文)在IP数据包的负载里面。它的头信息最少也需要20字节,因此TCP数据包的最大负载是1480-20=1460字节。由于IP和TCP协议往往有额外的头信息,所以TCP负载实际为1400字节左右,每个TCP层数据报文的大小是可以获取到的。如果一个TCP层数据报文为1400字节,那么一次性发送大量数据,就必须分成多个报文。例如,一个10MB的文件,需要发送7100多个报文。发送的时候,TCP协议为每个TCP层数据报文编号,该编号称为序列号(sequence number,简称SEQ),以便接收方按照顺序还原,该序列号也是将TCP成数据报文打包成数据包之后的数据包的序列号。
考虑到TCP层数据报文的特点,在一个可选的实施方式中可以利用TCP层数据报文的特点来获取向接收方传输的数据量,即在该可选实施方式中,获取所述媒体对象发送给所述接收方时向所述接收方传输的数据量可以包括如下步骤:获取将所述媒体对象发送给所述接收方时传输控制协议层数据报文的起始序列号和终止序列号,根据所述起始序列号和所述终止序列号得到所述传输控制协议层报文或数据包的数量(一个数据包携带有一个传输控制协议层报文,所以数据包的数量与传输控制协议层报文数量相同),根据传输控制协议层报文或数据包的数量和大小得到向所述接收方传输的数据量;和/或,获取将所述媒体对象发送给所述接收方所用的传输时间可以包括如下步骤:获取发送携带有所述起始序列号的数据包(也可以称为第一个数据包)的第一时间和将携带有所述终止序列号的数据包(也可以称为最后一个数据包)发送到所述接收方的第二时间,根据所述第二时间和所述第一时间的差值得到将所述媒体对象发送给所述接收方所用的传输时间;其中,所述媒体对象的数据包为对所述传输控制协议层报文打包形成的并且能够在网络中传输的数据包。例如,发送第一个数据包的时间为T1,发送第10个数据包的时间为T2,需要说明的是,在T2时第10个数据包还没有通过网络传输到接收方,因此,使用T2-T1得到的时间并没有包括第10个数据包的传输时间。一个数据包的传输时间是比较短的,如果传输的数据量是1000个数据包的数据量,此时传输时间使用发送第1000个数据包的时间减去发送第1个数据包的时间来进行计算的话,虽然会有误差,但是误差不是很大。在这个例子中,发送了10个数据包,如果直接使用T2来进行计算,则得到的传输速度的误差会比较大。在一个可选的实施方式中,可以使用将最后一个数据包发送到所述接收方的第二时间(即接收方接收到第10个数据包的时间)来计算传输时间,这样会使得传输时间计算更加准确。在该可选实施方式中,可以TCP协议的数据包来获取传输时间和向接收方传输的数据量,从而是计算得到的向接收方发送媒体对象的传输速度更加精确。
在使用TCP协议时,由于TCP协议提供的服务是可靠的,因此,使用TCP协议通讯的双方必须先建立起TCP连接,接收方也会对接收到的数据包进行确认,即接收方在接收到数据包之后会向发送方发送确认消息。对于发送方来说,在接收到接收方发送的确认消息之后,就可以根据确认消息中携带的序列号确定该序列号对应的数据包已经被接收方接收到。在一个可选的实施方式中,发送方可以根据接收到的确认消息来计算传输的数据量和传输时间。即在该可选实施方式中,获取所述媒体对象发送给所述接收方时向所述接收方传输的数据量和所述传输时间可以包括如下步骤:接收来自所述接收方的第一确认消息,其中,所述第一确认消息用于确认所述接收方已经接收到了携带有第一序列号的数据包;接收到来自所述接收方的第二确认消息,其中,所述确认消息用于确认所述接收方已经接收到了携带有第二序列号的数据包;将所述第一序列号作为所述起始序列号以及将所述第二序列号作为所述终止序列号,根据所述第一序列号和所述第二序列号之间的传输控制协议层报文或数据包的数量和大小得到向所述接收方传输的数据量;将所述第二时间和所述第一时间的时间差值作为所述传输时间,其中,所述第二时间=接收到所述第二确认消息的时间-(接收到所述第二确认消息的时间-发送携带有所述第二序列号的数据包的时间)/2,所述第一时间为发送携带有所述第一序列号的数据包的时间。例如,在发送了序列号为1的数据包之后,接收到序列号为1数据包(第1个数据包)的确认消息,则说明该数据包已经被接收方接收到了;在发送了序列号为10的数据包(第10个数据包)之后,接收到序列号为10的数据包的确认消息,则说明该数据包也被接收到了。发送第1个数据包的时间是T1,发送第10个数据包的时间是T2,接收到第10个数据包的确认消息的时间是T3,在T2和T3之间第10个数据包发送给了接收方,同时第10个数据包的确认消息发送给了发送方,一般情况下,发送方到接收方与接收方到发送方的传送时间是相同的,那么(T3-T2)/2就是第10个数据包从发送方到接收方的传送时间,因此传输时间=(T3-(T3-T2)/2)-T1,其中,(T3-(T3-T2)/2)为第二时间,T1为第一时间,在得到传输时间之后就可以计算传输速度了。需要说明的是,如果每次接收到一个确认消息就计算传输速度对于发送方来说需要占用大量的资源,会影响发送方的传输速度,而且也没有必要。因此,可以间隔预定数量个数据包或者间隔预定时长计算一次传输速度,即上述携带有所述第二序列号的数据包和携带有所述第一序列号的数据包之间间隔预定数量的数据包,或者,发送携带有所述第二序列号的数据包的时间和发送携带有所述第一序列号的数据包的时间之间间隔预定时长。例如,接收到对序列号为1001的数据包的确认消息之后,计算发送序列号为1到序列号1000的数据包所用的传输时间,然后每间隔1000个数据包计算一次传输速度;又例如,每间隔60秒计算一次传输速度等。
对于TCP协议来说,在建立TCP连接之后,在操作系统的内核中为该连接的维持保存了一些必要的数据结构,例如,连接的状态、数据报文的属性信息等。当通讯结束时双方必须关闭连接以释放这些保存在内核中的数据。因此,在获取发送数据包的时间以及TCP层数据报文的序列号时可以从发送方的操作系统内核中采集得到,即在发送方的操作系统内核中采集所述起始序列号以及所述终止序列号,和/或,在所述操作系统内核中采集所述第一时间和所述第二时间。
图2是根据本申请实施例的基于TCP层数据报文预测卡顿的示意图,如图2所示,将基于TCP层报文数据预测卡顿的功能分为三个模块:数据采集模块、视频分析模块、卡顿预测模块,其中,数据采集模块内嵌在CDN的服务器的操作系统内核(kernel)中,在传输过程中采集传输文件的大小、传输文件时间。其中,传输文件大小通过计算TCP层传输数据报文的起始序列号、传输结束时的序列号两者的差值获得,传输文件时间通过计算发送第一个数据包时间和最后一个数据包时间的差值获得;数据采集模块在取得上述数据后,将数据存储下来,供后续使用供卡顿预测模型使用。通过这种采集方式可以更加精确的得到起始序列号、终止序列号、第一时间和第二时间,从而能够准确的计算出发送速度。另外,通过内核进行采集的方式也可以提高数据获取的准确性。视频分析模块用于计算分析视频的平均码率,例如,根据分辨率、帧率等信息来就算平均码率。通过视频分析模块和数据采集模块可以得到向接收方发送媒体对象的传输速度和平均码率,然后就可以根据传输速度和平均码率判断是否卡顿了。卡顿预测模块可以根据上述两个模块提供的信息进行卡顿预测。
在一个可选实施方式中,可以认为如果平均码率大于传输速度,则就可以确定在接收方播放时会出现卡顿。即图2中的卡顿预测模块可以根据上述两个模块提供的信息进行卡顿预测,首先计算平均传输速度,用传输文件大小/传输时间得到传输速度;然后比较视频平均码率大小和传输速度大小,若视频平均码率>传输速度,则输出卡顿。对于视频平均码率小于等于传输速度的情况,可以直接输出未卡顿。
在上述实施方式中指出:对于视频平均码率小于等于传输速度的情况,可以直接输出未卡顿或者,作为另一个可选实施方式,考虑到在CDN中使用了TCP协议来进行传输,TCP协议为了保证发送的数据包均被接收方获取到,在由于网络原因出现丢包的时候,丢掉的数据包会被发送方重新进行发送。如果网络传输情况良好,丢包的数量不会很多,如果网络情况不好,则会产生数量比较大的丢包。在上述实施方式中,发送方使用了发送的数据量来来衡量发送速度,如果考虑到发送的数据量中包括重发的数据包,则发送方发送的数据包的数量是大于接收方数据包的数量的,在这种情况下,可以根据将发送的数据包中重发的数据包删除,这样相当于可以根据接收方真实接收到的数据包的数据量来计算发送速度。即在所述平均码率小于或等于所述传输速度的情况下,获取在发送所述媒体对象时向所述接收方传输的总数据量和重新传输的数据量,其中,所述重新传输的数据量是对所述接收方未接收到的数据量进行重新传输产生的;根据所述总数据量减去重新传输的数据量得到的差值重新计算传输速度;在所述平均码率大于重新计算得到的传输速度的情况下,确定所述接收方在播放时会出现卡顿,在所述平均码率小于等于重新计算得到的传输速度的情况下,确定所述接收方在播放时不会出现卡顿。通过这样方式将丢弃的数据包排除,重新计算了发送速度,使得计算得到的发送速度接近于接收方的接收速度,这样预测得到的卡顿会更加精确。
例如,待发送的视频文件的平均码率是900K比特/每秒,如果不考虑重传的数据包,计算得到的传输速度是1000K比特/每秒。此时,传输速度大于文件的平均码率,可以认为不会接收方在播放的时候不会发生卡顿。如果发现数据包的重传率高于预先配置的阈值,则需要考虑重传的数据包重新计算传输速度,此时获取到的数据包的重传率为20%,即之前发送的100个数据包里接收方只接收到80个,因此,重新计算得到的传输速度是800K比特/每秒,该重新计算得到的传输速度小于视频文件的平均码率,确定接收方在播放时会发生卡顿。
通过上述方式可以判断出接收方是否出现卡顿,然后统计预定时间内的不同数据传输算法发生卡顿的百分比,这样就可以通过比较出不同数据传输算法的优劣。图3是根据本申请实施例的不同视频传输算法的卡顿预测结果比较示意图,如图3所示,将卡顿百分比在CDN视频传输业务中使用作为评价视频传输质量的指标,在图3中,以接收视频文件的客户端的IP地址的最后一位按照奇数和偶数分别配置不同的视频传输算法,用预测的卡顿结果可以比较两种算法的优劣性。作为接收方的客户端,在发送请求之后,判断该请求来源的客户端的IP地址的最后一位是奇数还是偶数,如果是奇数在使用第一传输算法向客户端发送视频文件或音频文件,在发送之后判断此次发送是否会导致客户端播放出现卡顿;如果是偶数使用第二传输算法向客户端发送视频文件,并判断此次发送是否会导致客户端播放出现卡顿。然后对请求的次数和预测出现卡顿的次数进行统计,计算每一天卡顿出现次数和请求次数的百分比作为衡量第一传输算法和第二传输算法优劣的指标。接收方发送请求之后,响应于该请求发送的分块的视频文件或者音频文件,即该待传输的媒体对象可以是一个完整视频文件或者完整音频文件的一部分,该完整视频文件或完整音频文件可以分为多次发送给接收方,每次发送的内容都可以理解为是该步骤中的待传输的媒体对象。在图3中,第一传输算法预测卡顿百分比对应于预测卡顿_奇数,第二传输算法预测卡顿百分比对应于预测卡顿_偶数,从图3中示出的趋势来看,预测卡顿百分比随着日期是上升的,但是第二传输算法要优于第一传输算法。
预测得到的卡顿除了可以进行不同传输算法优劣的评估之外,还可以根据预测得到的卡顿在CDN中进行调整,以尽可能的消除卡顿。在一个可选实施方式中,在确定所述接收方在播放时会出现卡顿之后,所述方法还包括:对所述接收方所请求的媒体对象的码流进行调整,并向所述接收方发送码流调整后的媒体对象。
例如,待发送的视频文件的平均码率是900K比特/每秒,如果计算得到的传输速度是800K比特/每秒,则确定接收方在播放时会发生卡顿。此时,如果接收到接收方继续传输该视频文件的请求,则可以获取该视频文件对应的更低平均码率的文件,如700K比特/每秒,然后将平均码率调整后的文件发送给接收方。另一方面,如果计算得到的传输速度大于平均码率,此时可以获取更高平均码率的文件,如果更高平均码率的文件的平均码率仍然小于计算得到的传输速度,则可以使用向接收方传输更高平均码率的文件(即媒体对象)。通过该例子可以灵活调整发送文件的平均码率一方面减少播放的卡顿,另一方面还可以在一定程度上提高画面播放质量。
在另一个可选的实施方式中,可以设置一个阈值,该阈值作为调整平均码率的参考,如果视频文件的平均码率大于传输速度与该阈值的和,则降低传输的视频文件的平均码率,如果视频文件的平均码率小于传输速度与该阈值的差,则提高传输的视频文件的平均码率。如果视频文件的平均码率大于等于传输速度与该阈值的差,并且小于等于传输速度与该阈值的和,则不对传输的视频文件的平均码率进行调整。该阈值可以是预先配置的,如果能够得到客户端真实的卡顿数据的话,则可以根据客户端真实的卡顿数据来调整该阈值,以减少卡顿的发生。
又例如,还可以为发送方增加计算资源和网络资源以提高发送方的发送速度,这样也可以减少卡顿的发生。
需要说明的是上述以视频文件为例进行说明的实施方式对音频文件也适用。
通过上述实施方式解决了现有技术中CDN的提供方无法获知其发送的多媒体文件在播放时是否会存在卡顿所导致的问题,进而能够预测到用户在播放多媒体文件所出现的卡顿,为多媒体文件传输的优化提供了数据支持。另外,在CDN场景下,通过上述卡顿预测得到的结果可以辅助CDN进行传输算法的优化,提高CDN的服务质量。
在本实施例中,提供一种电子装置,包括存储器和处理器,存储器中存储有计算机程序,处理器被设置为运行计算机程序以执行以上实施例中的方法。
上述程序可以运行在处理器中,或者也可以存储在存储器中(或称为计算机可读介质),计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括,但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带,磁带磁盘存储或其他磁性存储设备或任何其他非传输介质,可用于存储可以被计算设备访问的信息。按照本文中的界定,计算机可读介质不包括暂存电脑可读媒体(transitory media),如调制的数据信号和载波。
这些计算机程序也可装载到计算机或其他可编程数据处理设备上,使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理,从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤,对应与不同的步骤可以通过不同的模块来实现。
在一个实施例中就提供了这样的一种装置。该装置本称为一种播放卡顿的判断装置,包括:第一获取模块,用于获取待传输的媒体对象;第二获取模块,用于获取将所述媒体对象发送给接收方的传输速度,其中,所述传输速度为单位时间内发送的数据量,所述接收方用于对接收到的媒体对象进行播放;第三获取模块,用于获取所述媒体对象的平均码率;判断模块,用于根据所述传输速度与所述平均码率判断所述接收方在对接收到的媒体对象进行播放时是否出现卡顿。
该系统或者装置用于实现上述的实施例中的方法的功能,该系统或者装置中的每个模块与方法中的每个步骤相对应,已经在方法中进行过说明的,在此不再赘述。
例如,所述第二获取模块,用于获取所述媒体对象发送给所述接收方时,向所述接收方传输的数据量;获取将所述媒体对象发送给所述接收方所用的传输时间;根据向所述接收方传输的数据量和所述传输时间计算得到所述传输速度。
可选地,所述第二获取模块,用于获取将所述媒体对象发送给所述接收方时传输控制协议层数据报文的起始序列号和终止序列号,根据所述起始序列号和所述终止序列号得到所述传输控制协议层报文或数据包的数量,根据传输控制协议层报文或数据包的数量和大小得到向所述接收方传输的数据量;和/或,获取发送携带有所述起始序列号的数据包的第一时间和将携带有所述终止序列号的数据包发送到所述接收方的第二时间,根据所述第二时间和所述第一时间的差值得到将所述媒体对象发送给所述接收方所用的传输时间;其中,所述媒体对象的数据包为对所述传输控制协议层报文打包形成的并且能够在网络中传输的数据包。
可选地,所述第二获取模块,用于接收来自所述接收方的第一确认消息,其中,所述第一确认消息用于确认所述接收方已经接收到了携带有第一序列号的数据包;接收到来自所述接收方的第二确认消息,其中,所述确认消息用于确认所述接收方已经接收到了携带有第二序列号的数据包;将所述第一序列号作为所述起始序列号以及将所述第二序列号作为所述终止序列号,根据所述第一序列号和所述第二序列号之间的传输控制协议层报文或数据包的数量和大小得到向所述接收方传输的数据量;将所述第二时间和所述第一时间的时间差值作为所述传输时间,其中,所述第二时间=接收到所述第二确认消息的时间-(接收到所述第二确认消息的时间-发送携带有所述第二序列号的数据包的时间)/2,所述第一时间为发送携带有所述第一序列号的数据包的时间。
又例如,所述判断模块用于在所述平均码率大于所述传输速度的情况下,确定所述接收方在播放时会出现卡顿;所述判断模块用于在所述平均码率小于或等于所述传输速度的情况下,确定所述接收方在播放时不会出现卡顿;或者,在所述平均码率小于或等于所述传输速度的情况下,获取在发送所述媒体对象时向所述接收方传输的总数据量和重新传输的数据量,其中,所述重新传输的数据量是对所述接收方未接收到的数据量进行重新传输产生的;根据所述总数据量减去重新传输的数据量得到的差值重新计算传输速度;在所述平均码率大于重新计算得到的传输速度的情况下,确定所述接收方在播放时会出现卡顿,在所述平均码率小于等于重新计算得到的传输速度的情况下,确定所述接收方在播放时不会出现卡顿。
又例如,上述装置还可以包括:调整模块,用于在确定所述接收方在播放时会出现卡顿之后,对所述接收方所请求的媒体对象的码流进行调整,并向所述接收方发送码流调整后的媒体对象。
通过上述实施方式,基于数据采集模块在内核中采集到的视频文件或音频文件在传输过程中的详细数据,计算得出的数据传输速度要更精确;采用数据传输速度和视频平均码率进行比较,预测客户端是否发生卡顿,提升了卡顿预测的准确性,使得视频传输优化算法间有可比较的关键指标,提高了优化效率。
以上仅为本申请的实施例而已,并不用于限制本申请。对于本领域技术人员来说,本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等,均应包含在本申请的权利要求范围之内。

Claims (14)

1.一种播放卡顿的判断方法,包括:
获取待传输的媒体对象;
获取将所述媒体对象发送给接收方的传输速度,其中,所述传输速度为单位时间内发送的数据量;
获取所述媒体对象的平均码率;
根据所述传输速度与所述平均码率判断所述接收方在对接收到的媒体对象进行播放时是否出现卡顿。
2.根据权利要求1所述的方法,其中,获取将所述媒体对象发送给所述接收方的传输速度包括:
获取所述媒体对象发送给所述接收方时,向所述接收方传输的数据量;
获取将所述媒体对象发送给所述接收方所用的传输时间;
根据向所述接收方传输的数据量和所述传输时间计算得到所述传输速度。
3.根据权利要求2所述的方法,其中,
获取所述媒体对象发送给所述接收方时向所述接收方传输的数据量包括:获取将所述媒体对象发送给所述接收方时传输控制协议层数据报文的起始序列号和终止序列号,根据所述起始序列号和所述终止序列号得到所述传输控制协议层报文或数据包的数量,根据所述传输控制协议层报文或数据包的数量和大小得到向所述接收方传输的数据量;其中,所述数据包为对所述传输控制协议层报文打包形成的并且能够在网络中传输的数据包;和/或,
获取将所述媒体对象发送给所述接收方所用的传输时间包括:获取发送携带有所述起始序列号的数据包的第一时间和将携带有所述终止序列号的数据包发送到所述接收方的第二时间,根据所述第二时间和所述第一时间的差值得到将所述媒体对象发送给所述接收方所用的传输时间。
4.根据权利要求3所述的方法,其中,获取所述媒体对象发送给所述接收方时向所述接收方传输的数据量和所述传输时间包括:
接收来自所述接收方的第一确认消息,其中,所述第一确认消息用于确认所述接收方已经接收到了携带有第一序列号的数据包;
接收到来自所述接收方的第二确认消息,其中,所述确认消息用于确认所述接收方已经接收到了携带有第二序列号的数据包;
将所述第一序列号作为所述起始序列号以及将所述第二序列号作为所述终止序列号,根据所述第一序列号和所述第二序列号之间的传输控制协议层报文或数据包的数量和大小得到向所述接收方传输的数据量;
将所述第二时间和所述第一时间的时间差值作为所述传输时间,其中,所述第二时间=接收到所述第二确认消息的时间-(接收到所述第二确认消息的时间-发送携带有所述第二序列号的数据包的时间)/2,所述第一时间为发送携带有所述第一序列号的数据包的时间。
5.根据权利要求4所述的方法,其中,携带有所述第二序列号的数据包和携带有所述第一序列号的数据包之间间隔预定数量的数据包,或者,发送携带有所述第二序列号的数据包的时间和发送携带有所述第一序列号的数据包的时间之间间隔预定时长。
6.根据权利要求3至5中任一项所述的方法,其中,
在发送方的操作系统内核中采集所述起始序列号以及所述终止序列号,和/或,在所述操作系统内核中采集所述第一时间和所述第二时间,其中,所述发送方为向所述接收方发送所述媒体对象的一方。
7.根据权利要求1至5中任一项所述的方法,其中,根据所述传输速度与所述平均码率判断所述接收方在对接收到的媒体对象进行播放时是否出现卡顿包括:
在所述平均码率大于所述传输速度的情况下,确定所述接收方在播放时会出现卡顿;
在所述平均码率小于或等于所述传输速度的情况下,确定所述接收方在播放时不会出现卡顿。
8.一种播放卡顿的判断装置,包括:
第一获取模块,用于获取待传输的媒体对象;
第二获取模块,用于获取将所述媒体对象发送给接收方的传输速度,其中,所述传输速度为单位时间内发送的数据量,所述接收方用于对接收到的媒体对象进行播放;
第三获取模块,用于获取所述媒体对象的平均码率;
判断模块,用于根据所述传输速度与所述平均码率判断所述接收方在对接收到的媒体对象进行播放时是否出现卡顿。
9.根据权利要求8所述的装置,其中,
所述第二获取模块,用于获取所述媒体对象发送给所述接收方时,向所述接收方传输的数据量;获取将所述媒体对象发送给所述接收方所用的传输时间;根据向所述接收方传输的数据量和所述传输时间计算得到所述传输速度。
10.根据权利要求9所述的装置,其中,
所述第二获取模块,用于获取将所述媒体对象发送给所述接收方时传输控制协议层数据报文的起始序列号和终止序列号,根据所述起始序列号和所述终止序列号得到所述传输控制协议层报文或数据包的数量,根据传输控制协议层报文或数据包的数量和大小得到向所述接收方传输的数据量;和/或,获取发送携带有所述起始序列号的数据包的第一时间和将携带有所述终止序列号的数据包发送到所述接收方的第二时间,根据所述第二时间和所述第一时间的差值得到将所述媒体对象发送给所述接收方所用的传输时间;其中,所述数据包为对所述传输控制协议层报文打包形成的并且能够在网络中传输的数据包。
11.根据权利要求10所述的装置,其中,
所述第二获取模块,用于接收来自所述接收方的第一确认消息,其中,所述第一确认消息用于确认所述接收方已经接收到了携带有第一序列号的数据包;接收到来自所述接收方的第二确认消息,其中,所述确认消息用于确认所述接收方已经接收到了携带有第二序列号的数据包;将所述第一序列号作为所述起始序列号以及将所述第二序列号作为所述终止序列号,根据所述第一序列号和所述第二序列号之间的传输控制协议层报文或数据包的数量和大小得到向所述接收方传输的数据量;将所述第二时间和所述第一时间的时间差值作为所述传输时间,其中,所述第二时间=接收到所述第二确认消息的时间-(接收到所述第二确认消息的时间-发送携带有所述第二序列号的数据包的时间)/2,所述第一时间为发送携带有所述第一序列号的数据包的时间。
12.根据权利要求8至11中任一项所述的装置,其中,
所述判断模块用于在所述平均码率大于所述传输速度的情况下,确定所述接收方在播放时会出现卡顿;
所述判断模块用于在所述平均码率小于或等于所述传输速度的情况下,确定所述接收方在播放时不会出现卡顿。
13.一种电子设备,包括存储器和处理器;其中,所述存储器用于存储一条或多条计算机指令,其中,所述一条或多条计算机指令被所述处理器执行以实现权利要求1至7任一项所述的方法步骤。
14.一种可读存储介质,其上存储有计算机指令,其中,该计算机指令被处理器执行时实现权利要求1至7任一项所述的方法步骤。
CN202211166837.4A 2022-09-23 2022-09-23 播放卡顿的判断方法、装置、电子设备和可读存储介质 Pending CN115767143A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202211166837.4A CN115767143A (zh) 2022-09-23 2022-09-23 播放卡顿的判断方法、装置、电子设备和可读存储介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202211166837.4A CN115767143A (zh) 2022-09-23 2022-09-23 播放卡顿的判断方法、装置、电子设备和可读存储介质

Publications (1)

Publication Number Publication Date
CN115767143A true CN115767143A (zh) 2023-03-07

Family

ID=85351895

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202211166837.4A Pending CN115767143A (zh) 2022-09-23 2022-09-23 播放卡顿的判断方法、装置、电子设备和可读存储介质

Country Status (1)

Country Link
CN (1) CN115767143A (zh)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101309400A (zh) * 2008-06-27 2008-11-19 上海华为技术有限公司 一种流媒体业务停顿信息获取方法及装置
CN101924603A (zh) * 2009-06-09 2010-12-22 华为技术有限公司 数据传输速率的自适应调整方法、装置及系统
CN105872764A (zh) * 2015-12-21 2016-08-17 乐视云计算有限公司 基于p2p网络的数据下载方法及装置
US20190124006A1 (en) * 2017-10-19 2019-04-25 Cisco Technology, Inc. Latency correction between transport layer host and deterministic interface circuit

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101309400A (zh) * 2008-06-27 2008-11-19 上海华为技术有限公司 一种流媒体业务停顿信息获取方法及装置
CN101924603A (zh) * 2009-06-09 2010-12-22 华为技术有限公司 数据传输速率的自适应调整方法、装置及系统
CN105872764A (zh) * 2015-12-21 2016-08-17 乐视云计算有限公司 基于p2p网络的数据下载方法及装置
US20190124006A1 (en) * 2017-10-19 2019-04-25 Cisco Technology, Inc. Latency correction between transport layer host and deterministic interface circuit

Similar Documents

Publication Publication Date Title
US8943206B2 (en) Network bandwidth detection and distribution
KR101046105B1 (ko) 컴퓨터 프로그램 제조품, 리소스 요구 조정 방법 및 엔드 시스템
CN113271316B (zh) 多媒体数据的传输控制方法和装置、存储介质及电子设备
JP4491257B2 (ja) 終端間測定に基づくネットワークへのデータストリームの許容の制御
WO2018121742A1 (zh) 一种流数据的传输方法和装置
JP2024509728A (ja) データ再送処理方法、装置、コンピュータ機器及びコンピュータプログラム
JP2005503722A (ja) 輻輳制御用に伝送レートを計算するためにバッファサイズの受領を用いるデータ通信方法とシステム
CN109560901A (zh) 一种数据重传方法、装置、终端设备及存储介质
WO2017144643A1 (en) Retransmission of data in packet networks
JP2010504652A (ja) ビデオネットワークを管理する方法及びシステム
CN110830460B (zh) 一种连接建立方法、装置、电子设备及存储介质
CN106664440B (zh) 用于在多媒体系统中接收和发送信息的方法和设备
US7991905B1 (en) Adaptively selecting timeouts for streaming media
US6850488B1 (en) Method and apparatus for facilitating efficient flow control for multicast transmissions
US11812114B2 (en) Method and server for audio and/or video content delivery
US11190430B2 (en) Determining the bandwidth of a communication link
US20110185018A1 (en) Content delivery system, content delivery method and computer program
US20060002425A1 (en) Determining available bandwidth in a network
CN111031340B (zh) 自适应地传输数据流的方法和通信网络中的节点
Clayman et al. Managing video processing and delivery using big packet protocol with SDN controllers
CN113726817B (zh) 一种流媒体数据的传输方法、装置及介质
CN115767143A (zh) 播放卡顿的判断方法、装置、电子设备和可读存储介质
Hisamatsu et al. Non bandwidth-intrusive video streaming over TCP
JP2004186793A (ja) ストリーミング配信装置、ストリーミング端末装置、ストリーミング配信システム、及びストリーミング配信方法
US20240298051A1 (en) Data relay apparatus, distribution system, data relay method, and computer-readable medium

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