估计处理器负荷的制作方法

文档序号:11139451阅读:247来源:国知局
估计处理器负荷的制造方法与工艺

本发明涉及用于估计处理器的负荷的方法和设备。



背景技术:

互联网上的多媒体内容的流传输近年来已经成为越来越普遍的应用。诸如点播电视、直播电视观看、直播视频流传输、音频流传输、视频会议、网络会议、可视电话、互联网协议语音(VoIP)以及许多其它的广泛的多媒体应用依靠端到端流传输解决方案。对以高质量播放流传输媒体存在逐渐增加的需求。

高质量的媒体通常需要能以高分辨率和帧率(除其它参数以外)捕捉媒体的媒体源。例如,许多摄像机现在能够以高清晰度(HD)、4K或甚至8K的分辨率捕捉视频。甚至更大的分辨率被设想用于未来的视频应用。来自这样的媒体源的原始数据由于高数据速率而不适于通过互联网传输。例如,HD视频具有超过100MBps的持续数据速率。因此,原始的媒体数据在通过互联网传输之前被压缩。

存在许多用于压缩媒体数据的编解码器。编码原始媒体数据减小其数据速率同时保持该原始源材料的质量的特定水平。编码媒体要求显著的处理能力,尤其是当编码高质量的媒体时。设备上的处理容量通常与其它应用共享,并且来自其它应用的高处理需求可能导致处理器负荷的增加以及用于编码媒体的可用容量的减小。该处理器负荷的增加可能导致编码和发送媒体流的延迟。这样的延迟可能具有不期望的影响,诸如“实时”媒体的重放的延迟、分组未及时到达重放设备以便重放等。因此,需要估计处理器上的负荷从而(例如)调整媒体流以消除由处理器上的负荷所导致的任何影响。



技术实现要素:

根据第一方面,提供了一种在用于发送媒体流的设备处估计处理器负荷的方法,所述设备包括编码器和能够执行用于所述编码器的指令的处理器,所述方法包括以下步骤:在所述编码器处对第一媒体帧和第二媒体帧进行编码;确定与所述第一媒体帧相关联的第一时间戳和与所述第二媒体帧相关联的第二时间戳之间的第一时段;确定代表所述第一媒体帧的编码完成的第一完成时间与代表所述第二媒体帧的编码完成的第二完成时间之间的第二时段;以及根据所述第一时段与所述第二时段之间的差形成处理器负荷的度量。

所述设备可包括分组器,根据在所述分组器处接收到的第一编码帧来确定所述第一完成时间,并且根据在所述分组器处接收到的第二编码帧来确定所述第二完成时间。

所述设备可包括被配置成对编码帧进行分组的分组器,并且其中,根据从所述分组器输出的第一编码帧的第一分组来确定所述第一完成时间;并且根据从所述分组器输出的第二编码帧的第一分组来确定所述第二完成时间。

所述分组器可被配置成将编码帧分组成RTP分组。

该方法还可包括以下步骤:将所述度量发送至用于接收所述媒体流的设备。

该方法还可包括以下步骤:接收网络的延迟的度量;以及根据所述延迟的度量和所估计的处理器负荷来调整用于所述媒体流的发送带宽。

该方法还可包括在所述接收设备处的以下步骤:形成所述网络的延迟的度量;经由所述网络接收所述处理器负荷的度量;以及根据所述处理器负荷的度量调整所述延迟的度量。

可通过下列步骤形成所述网络的延迟的度量:确定在接收设备处接收所述第一媒体帧的第一接收到的分组与接收所述第二媒体帧的第一接收到的分组之间的第三时段,其中,所述第一媒体帧的所述分组包括所述第一时间戳,并且所述第二媒体帧的所述分组包括所述第二时间戳;确定所述第一时间戳与所述第二时间戳之间的第四时段;以及根据所述第三时段与所述第四时段之间的差形成所述延迟的度量。

可通过下列步骤形成所述网络的延迟的度量:确定在接收所述第一媒体帧与接收所述第二媒体帧之间的第三时段,其中,所述第一媒体帧包括所述第一时间戳,并且所述第二媒体帧包括所述第二时间戳;确定所述第一时间戳与所述第二时间戳之间的第四时段;以及根据所述第三时段与所述第四时段之间的差形成所述延迟的度量。

该方法还可包括以下步骤:如果所述第二时段大于所述第一时段,则确定所述处理器超负荷。

该方法还可包括以下步骤:响应于确定所述处理器超负荷,改变用于对所述媒体帧进行编码的参数,以便使要被所述编码器输出的帧的质量降低。

根据第二方面,提供了一种用于识别一对网络设备之间的网络状况的方法,其中,所述设备中的一个包括能够执行用于形成通过网络传输媒体流的指令的处理器,所述方法包括以下步骤:监测在通过所述网络接收媒体中的延迟的度量;监测所述处理器上的负荷的度量;以及根据所述延迟的度量的变化和所述处理器上的所述负荷的度量识别网络状况。

识别的步骤可包括:如果所述延迟的度量的变化表示网络延迟增加,并且所述负荷的度量表示所述处理器未超负荷,则识别出所述网络拥塞。

识别的步骤可包括:如果所述延迟的度量的变化表示网络延迟增加,并且所述负荷的度量表示所述处理器超负荷,则识别出所述网络未拥塞。

监测延迟的度量的步骤可包括:确定接收初始媒体帧的第一接收到的分组与接收随后媒体帧的第一接收到的分组之间的第一时段,其中,每个接收到的分组都包括时间戳;确定所述初始媒体帧的分组的时间戳与所述随后媒体帧的分组的时间戳之间的第二时段;以及根据所述第一时段与所述第二时段之间的差形成所述延迟的度量。

所述分组可以是RTP分组。可根据RTP时间戳确定所述延迟的度量。

监测延迟的度量的步骤可包括:确定接收初始媒体帧与接收随后媒体帧之间的第一时段,其中,每个接收到的帧都包括时间戳;确定所述初始媒体帧的时间戳与所述随后媒体帧的时间戳之间的第二时段;以及根据所述第一时段与所述第二时段之间的差形成所述延迟的度量。

根据第三方面,提供了一种用于发送媒体流的设备,所述设备包括:编码器,所述编码器被配置成对第一媒体帧和第二媒体帧进行编码;处理器,所述处理器能够执行用于所述编码器的指令;以及控制器,所述控制器被配置成:确定与所述第一媒体帧相关联的第一时间戳和与所述第二媒体帧相关联的第二时间戳之间的第一时段;确定代表所述第一媒体帧的编码完成的第一完成时间与代表所述第二媒体帧的编码完成的第二完成时间之间的第二时段;以及根据所述第一时段与所述第二时段之间的差形成处理器负荷的度量。

该设备还可包括分组器,该分组器被配置成对编码帧进行分组,其中,所述控制器被配置成根据在所述分组器处接收到的第一编码帧来确定所述第一完成时间,并且根据在所述分组器处接收到的第二编码帧来确定所述第二完成时间。

该设备还可包括分组器,该分组器被配置成对编码帧进行分组,其中,所述控制器被配置成根据从所述分组器输出的第一编码帧的第一分组来确定所述第一完成时间,并且根据从所述分组器输出的第二编码帧的第一分组来确定所述第二完成时间。

所述分组器可被配置成将编码帧分组成RTP分组

所述控制器可被配置成,如果所述第二时段大于所述第一时段,则确定所述处理器超负荷。

响应于确定所述处理器超负荷,所述控制器可被配置成改变用于对所述媒体帧进行编码的参数,以便使要被所述编码器输出的帧的质量降低。

该设备还可包括收发器,所述收发器被配置成将所述度量发送至用于接收所述媒体流的设备。

所述收发器可被配置成接收所述网络的延迟的度量;并且所述控制器被配置成根据所述延迟的度量和所估计的处理器负荷来调整用于所述媒体流的发送带宽。

根据第四方面,提供了一种用于经由网络接收媒体流的设备,所述设备包括:控制器,所述控制器被配置成形成所述网络的延迟的度量;以及收发器,所述收发器被配置成从发送所述媒体流的设备接收处理器负荷的度量;所述控制器被配置成根据所述处理器负荷的度量调整所述延迟的度量。

可以通过下列步骤形成所述网络延迟的度量:确定在所述设备处接收第一媒体帧的第一接收到的分组与接收第二媒体帧的第一接收到的分组之间的第一时段,其中,所述第一媒体帧的分组包括第一时间戳,并且所述第二媒体帧的分组包括第二时间戳;确定所述第一时间戳与所述第二时间戳之间的第二时段;以及根据所述第一时段与所述第二时段之间的差形成所述延迟的度量。

可以通过下列步骤形成所述网络延迟的度量:确定接收第一媒体帧与接收第二媒体帧之间的第一时段,其中,所述第一媒体帧包括第一时间戳,并且所述第二媒体帧包括第二时间戳;确定所述第一时间戳与所述第二时间戳之间的第二时段;以及根据所述第一时段与所述第二时段之间的差形成所述延迟的度量。

根据第五方面,提供了一种用于识别网络状况的设备,所述设备包括控制器,该控制器被配置成:监测在通过网络接收媒体流中的延迟的度量;监测能够执行用于形成所述媒体流的指令的处理器上的负荷的度量;以及根据所述延迟的度量的变化和所述处理器上的所述负荷的度量识别网络状况。

所述控制器可被配置成,如果所述延迟的度量的变化表示网络延迟增加,并且所述负荷的度量表示所述处理器未超负荷,则识别出所述网络拥塞。

所述控制器可被配置成,如果所述延迟的度量的变化表示网络延迟增加,并且所述负荷的度量表示所述处理器超负荷,则识别出所述网络未拥塞。

所述控制器可被配置成通过以下操作监测所述延迟的度量:确定接收初始媒体帧的第一接收到的分组与接收随后媒体帧的第一接收到的分组之间的第一时段,其中,每个接收到的分组都包括时间戳;确定所述初始媒体帧的分组的时间戳与所述随后媒体帧的分组的时间戳之间的第二时段;以及根据所述第一时段与所述第二时段之间的差形成所述延迟的度量。

所述分组可以是RTP分组。可根据RTP时间戳确定所述延迟的度量。

所述控制器可被配置成通过以下操作监测所述延迟的度量:确定接收初始媒体帧与接收随后媒体帧之间的第一时段,其中,每个接收到的帧都包括时间戳;确定所述初始媒体帧的时间戳与所述随后媒体帧的时间戳之间的第二时段;以及根据所述第一时段与所述第二时段之间的差形成所述延迟的度量。

根据第六方面,提供了用于实现上述方法的机器可读代码。

根据第七方面,提供了一种其上编码有用于实现上述的方法的机器可读代码的机器可读非瞬时存储介质。

附图说明

现在将参照附图,通过示例的方式描述本发明。在附图中:

图1示出发送设备和接收设备的示例;

图2a至图2d示出在各种处理器负荷和编码器参数下的帧接收时序;

图3a至图3d示出在各种网络状况下的帧接收时序;以及

图4是示出估计处理器负荷的示例的流程图。

具体实施方式

提供以下描述以使得本领域的任何技术人员都能够制作和使用本发明。对所公开的实施方式的各种修改对于本领域的技术人员来说将是显而易见的。

本文所定义的通用原理在不脱离本发明的精神和范围的情况下可以被应用到其它实施方式和应用。因此本发明不旨在被限制于所示实施方式,而是旨在赋予本发明与本文所公开的原理和特征一致的最宽的范围。

图1描绘了发送设备10,其可以是能够产生基于分组的数据的任何适合的设备,诸如计算机、智能电话、可视电话等。发送设备10包括用于连接到诸如互联网或其它基于分组的网络的通信网络的收发器11。发送设备10可以经由收发器11向和/或从通信网络12发送和/或接收分组。

发送设备10包括媒体源13。媒体源13例如可以是照相机、麦克风、存储设备(例如闪存、硬盘)、可拆卸存储设备(例如存储卡、CD)、网路存储设备(例如网络驱动器或者云)、互联网媒体提供商(例如流传输服务)、无线电(例如DAB)等。媒体源13可以被包括在发送设备10内或者经由有线或无线接口(诸如HDMI、USB、模拟信号线输入(line-in)、I2S、S/PDIF、蓝牙、以太网、Wi-Fi、DAB等)连接到发送设备10。

发送设备10包括用于编码来自媒体源13的媒体数据(例如视频和/或音频数据)的编码器14。来自媒体源13的媒体可以作为媒体帧被提供。编码器14可以根据诸如ITU-T建议书H.264或ISO/IEC国际标准14496-10(二者也被称为高级视频编码(AVC))、MPEG-DASH、HTTP实时流传输或任何其它适合的编解码器的编码标准来编码媒体帧。

发送设备10可以包括分组器15,其从编码器14接收经编码的媒体帧并将这些帧分组成一系列分组,以便经由收发器11通过网络12进行发送。每帧可以被分组成一个或更多个分组。分组器15可以根据实时传输协议(RTP)标准来分组媒体。可以使用其它标准化的分组格式。分组器15将这些分组提供至收发器11,以便通过网络12发送至接收设备20。

接收设备20包括用于从网络12接收分组的收发器21。分组可以被提供至缓冲区22,其可以是能够根据媒体数据在分组中的播放顺序对分组进行排序的抖动缓冲区。该序列可以通过包含在每一分组中的序列号或时间戳来表示。解码器23对由缓冲区22按顺序提供至该解码器23的分组进行解码以形成媒体流。解码器23根据编码器13所使用的编解码器对分组进行解码。媒体用户24接收经解码的媒体流以便进行重放。媒体用户24例如可以是音频和/或视频播放器。

发送设备10包括处理器16(其例如可以是CPU或GPU)。处理器16执行用于在发送设备10处运行的应用的指令。这些指令可能来自用于对从媒体源13接收到的媒体帧进行编码的编码器14、来自用于分组经编码的媒体帧的分组器15、或来自可以在发送设备10处运行的其它应用(未示出)。

如上所述,有时处理器16可能变得超负荷。通常,当其它应用正使用大多数的处理器资源而使得其影响编码器13的操作时,处理器16可被认为超负荷。处理器16的超负荷可能由需求的峰值、热节流(throttling)、流氓(rogue)处理或其它原因而引起。处理器16的超负荷可能导致正被发送至接收设备20的媒体流出现问题。因此,期望确定处理器16上的负荷以使得可以适当地调整需要由处理器16执行的工作量。

发送设备10可以包括控制器17,其能够估计处理器16上的负荷并且基于所估计的负荷使得需要由处理器16执行的工作量得以调整。例如,如果控制器17确定处理器16超负荷,则其可以使编码器14使用对处理器16需求更少的编解码器。

控制器17可以通过比较帧被提供至编码器14的速率与经编码的帧从该编码器14输出的速率之间的差来估计处理器16上的负荷。如上所述,编码媒体帧通常需要显著的处理能力并且因此对编码器14编码帧所花费的时间量的测量提供了处理器16上的负荷的指征。

来自媒体源13的每一帧都与时间戳相关联。时间戳可以表示来自媒体源13的媒体根据时钟(未示出)被采样的时间(即,采样时刻),该时钟可以是在发送设备10和接收设备20处同步的挂钟。帧从媒体源13被提供至编码器14的速率可以根据这些帧的时间戳来确定。经编码的帧从编码器14输出的速率可以根据在编码器14之后的媒体处理流水线中的数据处理单元(例如分组器15或收发器11或可能在编码器14与收发器11之间出现的任何其它适合的单元)中的一个处接收到每个经编码的帧的时间来确定。将输入帧率与输出帧率进行比较以形成对处理器上的负荷的估计。例如,如果输出帧率小于输入帧率,则这可以表示处理器16超负荷。然后控制器17可以采取适当的行动来降低对处理器16的需求。

优选地,控制器17形成用于估计处理器16上的负荷的负荷度量。该负荷度量可以基于从编码器14接收每个新编码的帧的时间与从编码器14接收基准编码的帧的时间之间的时间差以及该时间差与这些帧的时间戳之间的时间差的比较。公式1是可以如何进行比较的示例:

负荷度量=(CurrentFramePk-RefFramePk)-(CurrentFrameTS-RefFrameTS)

(1)

其中,CurrentFramePk是在分组器15处接收到经编码的当前帧的时间,RefFramePk是在分组器15处接收到经编码的基准帧的时间,CurrentFrameTS是经编码的当前帧的时间戳,并且RefFrameTS是经编码的基准帧的时间戳。帧的时间戳可以被包括在该帧内。

在该示例以及下面的示例中,在分组器15处接收到经编码的帧的时间得以确定。然而,如上所述,接收到经编码的帧的时间被确定的点可能是该帧的编码已经完成之后的任何点,其通常将是编码器14之后的某一点。例如,用于经编码的帧的第一分组从分组器15被收发器11接收到的时间可以被用于确定CurrentFrameRx和RefFrameRx。相比于编码媒体,分组器15使用用于分组化的处理资源的量是可相对忽略不计的,并因此确定在分组器15之前接收经编码的帧的时间或者在分组器15之后接收这些帧的分组的时间之间没有明显的差。

公式2是在使用RTP分组来发送媒体数据的系统中可以如何确定拥塞度量的示例:

负荷度量=(CurFrameWALLTS-RefFrameWALLTS)-[(CurFrameRTPTS-RefFrameRTPTS)/90] (2)

其中,CurFrameWALLTS是在分组器15处接收到当前帧的时间(以毫秒为单位),RefFrameWALLTS是在分组器15处接收到基准帧的时间(以毫秒为单位),CurFrameRTPTS是包括在当前帧中的时间戳,以及RefFrameRTPTS是包括在基准帧中的时间戳。CurFrameRTPTS和RefFrameRTPTS时间戳可以由编码器基于由媒体源13提供的帧率信息确定并应用。除以90将时间戳的RTP时间单位转换成毫秒。

基准帧根据最佳可用知识被认为是以尽可能最短的时间被编码的帧。最初,媒体流的第一帧被选择为基准帧。随后,每当帧比之前的基准帧更快地被编码时就更新基准帧。

图2a至图2d示出了显示如何确定负荷度量以及其如何用于估计处理器16上的负荷的不同情况。

图2a示出了其中处理器具有较低负荷并且在正常情况下运行的情况。各箭头代表已经被编码器14编码的媒体帧。箭头上面表示该帧的RTP时间戳(RTPTS)。由箭头下面的时间(以毫秒为单位)表示各个经编码的帧在分组器15处被接收的时间。该时间作为相对于第一帧的时间被示出,但是其也可能是绝对时间。在这种情况下,第一帧被选择为基准帧。针对具有RTP时间戳的帧使用公式2,如下计算出针对各个帧的负荷度量:

第1帧:

负荷度量=(0-0)-((10000-10000)/90)=0

第2帧:

负荷度量=(100-0)-((19000-10000)/90)=(100-100)=0

第3帧:

负荷度量=(200-0)-((28000-10000)/90)=(200-200)=0

第4帧:

负荷度量=(300-0)-((37000-10000)/90)=(300-300)=0

第11帧:

负荷度量=(10000-0)-((910000-10000)/90)=(10000-10000)=0

第21帧:

负荷度量=(20000-0)-((1810000-10000)/90)=(20000-20000)=0

在该情况下,从第1帧至第21帧,负荷度量是恒定值零。这表示帧由编码器14以最熟知的速率进行编码,并且因此处理器未超负荷并且为了发送媒体流的目的而令人满意地运行。

图2b示出了其中处理器超负荷的情况。使用公式2,如下计算出针对各个帧的负荷度量:

第1帧:

负荷度量=(0-0)-((10000-10000)/90)=0

第2帧:

负荷度量=(200-0)-((19000-10000)/90)=(200-100)=100

第3帧:

负荷度量=(400-0)-((28000-10000)/90)=(400-200)=200

第4帧:

负荷度量=(1000-0)-((37000-10000)/90)=(1000-300)=700

第11帧:

负荷度量=(20000-0)-((910000-10000)/90)=(20000-10000)=10000

第21帧:

拥塞度量=(40000-0)-((1810000-10000)/90)=(40000-20000)=20000

由于第2帧至第21帧在分组器15处以渐增地延迟的方式被接收,所以该情况不同于图2a的情况。当处理器16超负荷时,存在较少的处理能力可用于编码器14编码输入帧。因此,花费更大量的时间来完成帧的编码,这导致在分组器15处接收经编码的帧的延迟。编码器14的减速可能会导致在编码器14的输入缓冲器处帧的累积。这导致帧被渐增地延迟,因此针对各随后的帧,负荷度量值增加。因此,渐增的负荷度量表示处理器16超负荷。

图2c示出了其中存在编码器14编码帧所花费的时间增加的情况,这可能是例如由于由编码器14输出的帧所需的像素分辨率的改变或者可能需要更多处理资源用于编码帧的任何其它改变。该改变可能由于其它控制算法(诸如可以响应于可用网络带宽的改变调整传输比特率的网络带宽自适应算法)已经开始。在图2c的示例中,由于帧的像素分辨率的增加导致在第二帧与第三帧之间出现的编码时间的增加(如图所示)。使用公式2,如下计算出针对各个帧的负荷度量:

第1帧:

负荷度量=(0-0)-((10000-10000)/90)=0

第2帧:

负荷度量=(100-0)-((19000-10000)/90)=(100-100)=0

第3帧:

负荷度量=(250-0)-((28000-10000)/90)=(250-200)=50

第4帧:

负荷度量=(350-0)-((37000-10000)/90)=(350-300)=50

第11帧:

负荷度量=(10050-0)-((910000-10000)/90)=(10050-10000)=50

第21帧:

负荷度量=(20050-0)-((1810000-10000)/90)=(20050-20000)=50

在这种情况下,针对第三帧的负荷度量增加并且与针对随后帧的增加值保持恒定。由于帧被输入的速率和帧被编码器14输出的速率相同,所以这表示处理器16未超负荷并且令人满意地运行。延迟增加例如表示已经存在在第二帧之后的各帧的编码时间的增加(这可能是由于由编码器14编码的帧的像素分辨率的改变所导致的)。优选地,当通过质量控制器15确定这种情况时,从负荷度量的计算结果减去该恒定值(在本示例中是50),直到基准帧被更新为止。

图2d示出了其中存在编码器14编码帧所花费的时间减少的情况,这可能是例如由于由编码器14输出的帧所需的使用的像素分辨率的改变或者编码帧可能需要更少的处理资源的任何其它改变所导致的。在本示例中,由于帧的像素分辨率的减小而导致在第三帧与第四帧之间出现编码时间的减少(如图所示)。使用公式2,如下计算出针对各个帧的负荷度量:

第1帧:

负荷度量=(0-0)-((10000-10000)/90)=0

第2帧:

负荷度量=(100-0)-((19000-10000)/90)=(100-100)=0

第3帧:

负荷度量=(200-0)-((28000-10000)/90)=(200-200)=0

第4帧:

负荷度量=(250-0)-((37000-10000)/90)=(250-300)=-50

更新基准帧,RefFrame=第四帧

第11帧:

负荷度量=(9950-250)-((910000-37000)/90)=(9700-9700)=0

第21帧:

负荷度量=(19950-250)-((1810000-37000)/90)=(19700-19700)=0

在这种情况下,针对第四帧的负荷度量减小。该减小例如表示从第四帧开始已经存在像素分辨率的改变,这导致在编码器14处需要更少量的时间来编码帧。在这种情况下,第四帧被认为是比第一帧更快地被编码的帧,并因此基准帧被从第一帧更新成第四帧,用于计算针对随后帧的负荷度量。

控制器17可以监测负荷度量的改变以确定处理器16上的负荷,如通过上述情况所描述的。基于所确定的处理器上的负荷,控制器17可以调整用于编码器14的编码参数,以便降低对处理器的需求,使得帧可以按及时方式被发送。例如,如果确定处理器16超负荷,则控制器17可以使编码器14降低要被该编码器14输出的帧的质量(例如通过降低像素分辨率),使得编码过程占用更少的资源。这将减少每帧所需的处理并因此减少编码各帧所需的时间量。可以响应于处理器超负荷通过控制器15对其它编码器参数(诸如输出帧率、比特率、颜色的数量、帧类型等)进行调整。控制器17可以被配置成如果处理器16超负荷则使发送设备10上的其它应用降低对该处理器16的需求。通过该方法,将存在更多的处理资源可用于编码器14,并因此媒体流的质量能够得以保持。

处理器上的负荷的确定可以与网络延迟的度量结合使用以准确地确定网络12的状况。网络12的状况可能会改变(例如,其可能变得拥塞),这可能会导致在接收设备20处接收分组的延迟。该延迟可能会导致太晚接收到媒体用户24要按时播放的完整的帧。因此,期望确定网络12的状况是否已经改变以及如何改变,使得发送设备10可以适当地调整其发送以便补偿该改变。

接收设备20包括用于识别网络12的改变的控制器25。该控制器25能够确定分组何时被接收设备20接收。分组被接收的时间可以根据挂钟或内部时钟(未示出)推导出,该内部时钟可能不一定与所述挂钟同步。控制器25还能够确定由包括在各个接收到的分组中的时间戳表示的时间。控制器25能够通过将在接收设备20处接收到分组的时间与由这些分组的时间戳表示的时间进行比较来识别网络状况的改变(如下面更详细地讨论的)。控制器25可以将标识出的改变的指征发送至发送设备10,使得该发送设备10可以适当地调整其发送参数。控制器25还可以响应于某些网络状况调整其接收参数(例如,目标抖动缓冲器大小)中的一些。

优选地,(下面所描述的)拥塞度量被用作网络延迟的度量。然而,可以使用网络延迟的其它度量,诸如:

-分组往返时间。

-测量完整的帧之间的到达间(inter-arrival)时间。

-测量经固定的时段(例如一秒)接收到的帧或分组的时间戳之间的时段并将该时段与所述固定的时段进行比较。

-测量不同大小的分组对之间的扩展,并作为成对的分组之间的时间扩展以及它们的大小的函数估计可用带宽。根据可用带宽,分组对随着它们穿过网络元素而在时间上扩展。

质量控制器25可以使用拥塞度量来识别发送设备10与接收设备20之间的网络状况,诸如拥塞、路线改变等。使用每个新接收到的帧与基准帧之间的到达间时间来确定拥塞度量。每个帧都可以由具有相同时间戳的一个或更多个分组构成。可以通过比较完整的帧的到达或针对每个帧第一个接收到的分组的到达来确定帧之间的到达间时间。由于网络12中的分组丢失、改变的网络路径等,所以针对每个帧第一个接收的分组可能不一定是被分组或被发送设备10发送的第一分组。

将新接收到的帧与基准帧之间的到达时间间隔与这些帧的时间戳之间的时间差相比较。该比较被用于形成拥塞度量。公式3是可以如何进行该比较的示例:

拥塞度量=(CurrentFrameRx-RefFrameRx)-(CurrentFrameTS-RefFrameTS)

(3)

其中,CurrentFrameRx是在接收设备20处针对当前帧接收到第一分组的时间,RefFrameRX是在接收设备20处针对基准帧接收到第一分组的时间,CurrentFrameTS是当前帧的时间戳,以及RefFrameTS是基准帧中的时间戳。另选地,CurrentFrameRx和RefFrameRX可以分别是接收到当前帧的时间和接收到基准帧的时间。

公式4是在使用RTP分组来发送媒体数据的系统中可以如何确定拥塞度量的示例:

拥塞度量=(CurrentFrameRx-RefFrameRx)-[(CurrentFrameTS-RefFrameTS)/90](4)

其中,CurrentFrameRx是在接收设备20处针对当前帧接收到第一个RTP分组的时间(以毫秒为单位),RefFrameRX是在接收设备20处针对基准帧接收到第一个RTP分组的时间(以毫秒为单位),CurrentFrameTS是包括在当前帧的第一个RTP分组的RTP报头中的时间戳,以及RefFrameTS是包括在基准帧的第一个RTP分组的RTP报头中的时间戳。另选地,CurrentFrameRx是接收到当前帧的时间(以毫秒为单位)、RefFrameRX是接收到基准帧的时间(以毫秒为单位),以及CurrentFrameTS和RefFrameTS分别是包括在当前帧和基准帧中的时间戳。除以90将RTP时间单位转换成毫秒。

如果拥塞度量是零或是在接近于零的某一阀值内,则认为从网络接收到的分组是“准时(on-time)”的,并因此网络正为了媒体流的目的而令人满意地运行。基准帧根据最佳可用知识被认为是准时到达的帧。最初,媒体流的第一帧被选择为基准帧。随后,每当帧准时或在某一阀值内到达时,则更新基准帧。

图3a至图3d示出了显示可如何使用拥塞度量以确定网络状况的各种情况。

图3a示出了其中网络在正常情况下运行的情况。各箭头表示使用RTP协议发送的媒体帧。箭头上面是表示帧的RTP时间戳(RTPTS)。各个帧的第一分组被接收的时间则由箭头下面的时间(以毫秒为单位)表示。该时间作为相对于第一帧的时间被示出,但是其也可能是绝对时间。在这种情况下,第一帧被选择为基准帧。针对RTP分组使用公式4,如下计算出针对各个帧的拥塞度量:

第1帧:

拥塞度量=(0-0)-((10000-10000)/90)=0

第2帧:

拥塞度量=(100-0)-((19000-10000)/90)=(100-100)=0

第3帧:

拥塞度量=(200-0)-((28000-10000)/90)=(200-200)=0

第4帧:

拥塞度量=(300-0)-((37000-10000)/90)=(300-300)=0

第11帧:

拥塞度量=(10000-0)-((910000-10000)/90)=(10000-10000)=0

第21帧:

拥塞度量=(20000-0)-((1810000-10000)/90)=(20000-20000)=0

在该情况下,从第1帧至第21帧,拥塞度量是恒定值零。这表示帧准时到达接收设备20,并且因此网络为了媒体流的目的而正在令人满意地运行。

图3b示出了网络中存在拥塞的情况。使用公式4,如下计算出针对各个帧的拥塞度量:

第1帧:

拥塞度量=(0-0)-((10000-10000)/90)=0

第2帧:

拥塞度量=(200-0)-((19000-10000)/90)=(200-100)=100

第3帧:

拥塞度量=(400-0)-((28000-10000)/90)=(400-200)=200

第4帧:

负荷度量=(1000-0)-((37000-10000)/90)=(1000-300)=700

第11帧:

拥塞度量=(20000-0)-((910000-10000)/90)=(20000-10000)=10000

第21帧:

拥塞度量=(40000-0)-((1810000-10000)/90)=(40000-20000)=20000

该情况由于针对第2帧至第21帧的第一个接收到的分组是以渐增地延迟的方式被接收的而不同于图3a的情况。在拥塞期间,针对各个帧的拥塞度量与发送速率和瓶颈带宽之间的失配成比例。在其它时间,拥塞度量接近于零或低于表示不拥塞的某一阀值。其中拥塞度量根据发送带宽、瓶颈带宽(或节流)以及网络使用率而增加。

图3c示出了其中存在单次网络延迟增加的情况,单次网络延迟增加发生在第二帧与第三帧之间(如图所示)。使用公式4,如下计算出针对各个帧的拥塞度量:

第1帧:

拥塞度量=(0-0)-((10000-10000)/90)=0

第2帧:

拥塞度量=(100-0)-((19000-10000)/90)=(100-100)=0

第3帧:

拥塞度量=(250-0)-((28000-10000)/90)=(250-200)=50

第4帧:

拥塞度量=(350-0)-((37000-10000)/90)=(350-300)=50

第11帧:

拥塞度量=(10050-0)-((910000-10000)/90)=(10050-10000)=50

第21帧:

拥塞度量=(20050-0)-((1810000-10000)/90)=(20050-20000)=50

在这种情况下,针对第三帧的拥塞度量增加并且针对随后帧的增加值保持不变。由于延迟是恒定的(而不是像图3b的情况那样渐增的),因此这表示该延迟不是由于拥塞所引起的。该延迟的增加例如表示存在网络路径的变化(如图3c中路线改变箭头所描绘的),其导致将分组从发送设备10传送至接收设备20更长的时间量。优选地,当通过质量控制器25确定这种情况时,从拥塞度量的计算结果减去该恒定值(在本示例中是50)直到基准帧被更新为止。

图3d示出了其中存在单次网络延迟减小的情况,单次网络延迟减小发生在第三帧与第四帧之间(如图所示)。使用公式4,如下计算出针对各个帧的拥塞度量:

第1帧:

拥塞度量=(0-0)-((10000-10000)/90)=0

第2帧:

拥塞度量=(100-0)-((19000-10000)/90)=(100-100)=0

第3帧:

拥塞度量=(200-0)-((28000-10000)/90)=(200-200)=0

第4帧:

拥塞度量=(250-0)-((37000-10000)/90)=(250-300)=-50

更新基准帧,RefFrame=第四帧

第11帧:

拥塞度量=(9950-250)-((910000-37000)/90)=(9700-9700)=0

第21帧:

拥塞度量=(19950-250)-((1810000-37000)/90)=(19700-19700)=0

在这种情况下,针对第四帧的拥塞度量减小。该减小例如表示存在网络路径的变化(如图3d中路线改变箭头所描绘的),这导致将分组从发送设备10传送至接收设备20更短的时间量。在这种情况下,第四帧被认为是被准时接收的,并因此基准帧被从第一帧更新成第四帧,用于计算针对随后的帧的拥塞度量。

将所描述的关于网络拥塞度量的情况(图3a至图3d)与所描述的关于处理器负荷度量的情况(图2a至图2d)进行比较,可以看出,发送设备10处的特定状况可以将其自身表现为至接收设备20的网络状况。例如,当处理器16在发送设备10处变得超负荷时(如上关于图2b所描述的),在对帧进行编码期间存在渐增的延迟。该渐增的延迟导致分组的延迟发送,这进而导致在接收设备20处接收分组的延迟。这导致尽管网络表现正常但接收设备20观察到渐增的拥塞度量。因此在发送设备10处超负荷的处理器将其自身表现为在接收设备20处至控制器25的网络拥塞。同样,与图2c和图2d相关描述的像素分辨率的改变可以表现为与图3c和图3d相关描述的网络路径的改变。

可以根据处理器负荷度量调整网络拥塞度量,以避免将其自身表现为网络12中的变化的发送设备10处的任何变化。这可以通过从针对各相应帧的网络拥塞度量减去针对各帧的处理器负荷度量来实现。发送设备10处的控制器17可以将针对各帧的处理器负荷度量的指征发送至接收设备20。接收设备20处的控制器25可以确定针对各帧的拥塞度量,然后减去接收到的针对相应帧的负荷度量,并使用所得出的值来确定网络的状况。

另选地,接收设备20的控制器25可以将针对各帧的拥塞度量发送至发送设备10,以便控制器17可以确定网络12的状况。控制器17可以暂时存储针对各帧的处理器负荷度量,发送设备10发送处理器负荷度量,然后从其针对各帧接收的拥塞度量中减去处理器负荷度量。所得出的值然后可被用于确定网络的状况。发送设备10然后可根据所确定的网络状况来调整其媒体发送。例如,如果确定网络是拥塞的,则质量控制器15可以(作为响应)使发送设备10减小其发送带宽。这可以通过(例如)降低要被发送的媒体的质量、增加分组大小(这降低分组化消耗)、减少纠错冗余等来实现。优选地,发送带宽将被减小至低于拥塞的网络带宽,以便可以避免进一步的拥塞。这将确保所发送的媒体分组以及时方式到达传输设备以便用于重放。

负荷度量向媒体流应用提供了监测处理器负荷的简单且高效利用资源的方法。这消除了用于专门监测处理器负荷并向媒体流应用报告处理器负荷的任何单独的处理或应用的需求。负荷度量可以另外与拥塞度量结合使用以提供准确的网络延迟度量,所述网络延迟度量然后可以被用于可靠地确定网络状况的变化以及这些变化的原因。发送设备可以适当地调整其编码和/或发送参数以补偿处理器负荷的变化和/或网络的变化,以维持接收设备重放媒体流的质量等级。

图4是示出可以如何估计处理器16上的负荷的流程图。

在步骤401,编码器14从媒体源13接收用于编码的帧。在步骤402,编码器对帧进行编码并且将时间戳应用到该帧。时间戳可以是以由媒体源13输出的媒体的帧率为基础的。在步骤403,帧的编码完成的时间(例如,经编码的帧被分组器15接收到的时间)被存储。

在步骤404,检查是否设置了基准帧。如果有,则该处理进行至步骤406。如果没有,则在步骤405将该帧设置为基准帧,并且该处理返回至步骤401,用于由编码器14接收到的下一帧。

在步骤406,将所应用的时间戳与基准帧的时间戳进行比较以确定第一时段。在步骤407,将所存储的完成时间(在步骤403存储的)与基准帧的编码完成的时间进行比较以确定第二时段。在步骤408,确定第一时段与第二时段之间的差以提供处理器负荷的度量。

可以针对从媒体源接收到的每一帧执行图4的处理(如循环返回至步骤401所表示的)。

根据本文所描述的示例配置的发送设备和接收设备可以以硬件、软件或硬件和软件的任何适当的组合的形式来实现。发送设备可以具有与接收设备相同的性能并且反之亦然。如本文所述的设备可以包括(例如)用于在一个或更多个处理器(诸如在CPU和/或GPU)、和/或一个或更多个专用处理器(诸如ASIC)、和/或被适当地编程以便提供设备的功能的一个或更多个可编程处理器(诸如FPGA)、和/或包括一个或更多个专用的、可编程的并且通用的处理功能的异构处理器执行的软件。本文所描述的设备可以包括一个或更多个处理器以及具有存储其上的程序代码的一个或更多个存储器,所述处理器和存储器这样以便(相结合)提供所要求保护的设备和/或执行所要求保护的方法。

本文所描述的数据处理单元(例如,编码器、控制器和分组器)不需要被设置为分立单元并且代表可以(a)以任何方式相结合并且(b)自身包括一个或更多个数据处理实体的功能。数据处理单元可以通过任何适当的硬件或软件功能或者硬件和软件功能的组合来提供。

如本文所使用的术语软件包括用于处理器(例如,CPU和/或GPU)的可执行代码、固件、字节码、诸如C或OpenCL的编程语言代码、以及诸如FPGA的用于可重配置逻辑器件的模块。机器可读代码包括用于限定硬件的软件和代码,诸如可能在Verilog或VHDL中生成的寄存器传送级(RTL)代码。

本文所描述的任何一种或更多种方法可以由一个或更多个物理处理单元来执行,所述物理处理单元执行使得该单元执行所述方法的程序代码。该或每个物理处理单元都可以是任何合适处理器,诸如CPU或GPU(或其内核)、或固定功能或可编程硬件。程序代码可以以非暂时形式存储在机器可读介质中,诸如集成电路存储器、或光或磁存储器。机器可读介质可以包括多个存储器,诸如片上存储器、计算机工作存储器、以及非易失性存储设备。

由此,申请人单独公开了在此描述的每个单独特征以及两个以上这样的特征的任何结合,在这个意义上,这样的特征或结合能够根据本领域技术人员的公知常识,作为一个整体基于本说明书被实现,而不管这样的特征或特征的结合是否解决了在此公开的任何问题,并且不限制权利要求的范围。申请人指出,本发明的多个方面可以由任何这样的单独特征或特征的结构构成。考虑前述说明,可以在本发明的范围内作出多种修改,对于本领域技术人员来说是显而易见的。

当前第1页1 2 3 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1