一种异构网络传输下的动态时间窗口及缓存机制转让专利

申请号 : CN201510064427.2

文献号 : CN105991469B

文献日 :

基本信息:

PDF:

法律信息:

相似专利:

发明人 : 徐异凌张文军孙军管云峰何大治柳宁王成志

申请人 : 上海交通大学

摘要 :

本发明提供了一种异构网络传输下的动态时间窗口及缓存机制,所述方法针对已有的MMT中的信令,在信令中或其他地方增加媒体内容的Available_Time及Asset_Size属性,使客户终端获知相应媒体内容能获取的时间及媒体内容的大小;同时,客户终端通过IP网络中相应的方法可确定当前宽带网络下的网络带宽及内容从宽带到客户端的网络延时,通过宽带源内容的可获取时间和宽带信道的延迟,客户终端可计算出发送请求提前缓存的时间区间及终端所需要的缓存窗口大小。本发明解决了广播与宽带中组成的异构终端中内容因宽带拥塞而无法同步的问题,同时也减小了客户端由于缓存而带来的额外开销。

权利要求 :

1.一种在异构网络终端自适应地调整缓存窗口大小的方法,其特征在于,所述方法针对已有的MPEG媒体传输MMT中的信令,在信令部分增加媒体内容的Available_Time及Asset_Size属性,使客户终端获知相应媒体内容能获取的时间;同时,客户终端通过IP网络中相应的方法确定当前宽带网络下的网络带宽及内容从宽带到客户端的网络延时,通过宽带源内容的可获取时间和宽带信道的延迟,客户终端计算出发送请求提前缓存的时间区间及终端所需要的缓存窗口大小;

所述方法在原有的MPEG媒体传输MMT信令中加入新的属性:Available_Time和Asset_Size,用以说明宽带中待传送的该内容在内容提供商处准备好并可以开始传输的时间以及该部分内容的大小;Available_Time赋值遵循如下规则:

1)时间未知

若服务器端还不能确定待传送的内容准备好的时间,则Available_Time赋值为"unknown";同时为了考虑系统的兼容性,若服务器端发送的信令中未添加Available_Time属性,则终端解析为Available_Time为未知;

2)随时可以访问

若服务器端的媒体内容随时可以访问与发送,则Available_Time赋值为"anytime";

3)某个特定时间开始后,一直有效

若服务器端的内容在某个特定时间开始后一直有效,则Available_Time赋值为该特定的UTC时间,即"(UTC1)";

4)某个特定时间区域内有效

若服务器端的内容在某个特定的时间区间内可获取,则Available_Time赋值为该时间区间,即"(UTC1)-(UTC2)";

对于Available_Time的解析工作在终端完成。

2.一种用于权利要求1所述方法的在异构终端确定请求时间窗口及缓存窗口大小的方法,其特征在于:终端能够获取的呈现信息CI文件中已有的属性包括对象的正常开始呈现的时间—begin,同时通过IP网络内的相应方法,得到当前的单向宽带网络延时—t1与宽带网络的带宽—Bitrate;在信令中加入宽带内容可获取时间的属性Available_Time和Asset_Size后:设定一个阈值Threshold,若延时t1小于此阈值,则该延时可忽略不计,系统无需为宽带传输的媒体内容分配额外缓存;若t1大于此阈值,则通过具体方案中的方法确定请求提前发送宽带中媒体内容的时间区间,并为终端分配缓存窗口;若网络延时很大,内容提供商提供的Available_Time已不满足提前缓存保持同步的条件,则直接将该宽带通道传送的辅助内容丢弃;

具体方案如下:

1)在信令中加入对应内容的Available_Time和Asset_Size属性;

2)客户终端通过IP网络内的相应方法,得到当前宽带网络的单向延时t1与宽带网络的带宽Bitrate;

3)客户端通过解析信令得到对应媒体内容的可获取时间Available_Time,正常播放时间begin以及对应内容的大小Asset_Size;

4)若t1Threshold,则通过如下方法计算出终端发送请求的时间窗口和终端分配的缓存大小:①计算服务商传输一个内容单元所需要的时间:Data_Transfer_Time,此时间由一个内容单元的大小和当前宽带环境下比特率来计算获取;

②若Available_Time为"unknown"或呈现信息CI中并无此属性,则不进行处理;若Available_Time为"anytime",则跳过此步骤进入③;若Available_Time为一个特定的UTC时间区间,则取最早的时间进行如下判断:Available_Time+t1+Data_Transfer_Time

若条件(1)成立,则表明当前网络延时带来的不同步问题可由提前缓存来解决,进行下一步计算;

③计算终端请求提前发送媒体内容的时间区间:

请求最早时间:

Earliest_Request_Time=Available_Time-t1    (2)请求最晚时间:

Latest_Request_Time=begin-2t1-Data_Transfer_Time    (3)实际请求的时间介于两个时间点之间:

Earliest_Request_Time

Δt=begin-Receive_Time    (6)

⑤如果呈现信息CI中给出了Asset_Size属性,则终端分配的缓存窗口大小为:Buffer_Size=min{Δt*bitrate,Asset_Size}    (7)若果呈现信息CI中未给出Asset_Size属性,则终端分配的缓存窗口大小为:Buffer_Size=Δt*bitrate    (8)。

说明书 :

一种异构网络传输下的动态时间窗口及缓存机制

技术领域

[0001] 本发明涉及一种在异构网络传输下客户终端的动态时间请求窗口及缓存机制,具体的说,涉及一种确定终端请求发送媒体内容的时间区间,以及缓存窗口大小的分配方法。

背景技术

[0002] 随着时代的变革,人们已不满足于仅仅依靠传统电视来获取信息和进行娱乐,更多的终端设备出现在我们面前,如连接互联网的PC、几乎人手一台的手机以及越来越普及的移动平板电脑等,这些新的产品已经在慢慢侵蚀传统电视业务的市场。随着移动通信和宽带无线技术的发展,以及多媒体业务的日益成熟,融合已成为信息通信业的发展潮流,它可以使用户能够便捷地接入网络,轻松地享用更丰富的媒体内容和多样化的服务。
[0003] 与此同时,媒体内容的呈现将不只是简单的视频,音频,字幕,媒体类型将会越来越丰富多样。媒体来源也不只是特定的内容提供商,越来越多的制作者参与其中,包括很多个人用户同时也是内容的提供和制作者。这些来自不同提供者的内容存在着各种关联关系,为了满足不同用户的个性化需求,这些关联内容往往需要同步呈现。在此环境下,异构网络融合作为下一代网络发展的必然趋势,充分说明了未来的通信不再是某种特定的接入技术,而是多种接入技术并存、协同工作。
[0004] 在由广播和宽带组成的异构网络环境下,终端呈现的媒体内容可同时从广播和宽带通道传输过来。对于此异构网络终端的呈现,有一种基于呈现信息(CI,Composition Information)的多源内容分发机制。CI采用HTML5和XML等技术提供媒体数据的时间和空间信息,使得多媒体数据可以在终端进行多样化的呈现。
[0005] 终端可以根据信令中的信息从服务器端请求相关内容,但是服务器端收到请求的时候,相关内容可能已经准备好,可能还没有。如果相关内容还没有准备好,终端的请求就会失败,然后再次请求,直到获得相关内容。这对终端是很大的负担,同时也会增加网络负担。
[0006] 由于现在的宽带网络需要在多个节点对内容进行转发,因此存在网络延时大甚至网络阻塞等问题。因此需要在接收端提前对内容进行缓存,以应对终端内容无法播放或者媒体内容无法同步播放的问题。
[0007] 缓存的引入又带来了新的问题,终端需要提前缓存多少的内容、从何时开始缓存,都会影响客户端设备的配置与系统的性能。因此客户端缓存窗口的大小和拉取缓存的时间成为一个亟待解决的问题。

发明内容

[0008] 针对现有技术的不足,本发明提供了一种在异构网络终端自适应地调整请求时间窗口和缓存窗口大小的方法,从而解决了广播与宽带中组成的异构终端中内容因宽带拥塞而无法同步的问题,同时也减小了客户端由于缓存而带来的额外开销。
[0009] 本发明是采用以下技术方案实现的:
[0010] 本发明提供一种在异构网络终端自适应地调整请求时间窗口和缓存窗口大小的方法,所述方法通过在信令(如MPT、CI、MPU)或其他地方增加媒体内容的Available Time和Asset_Size属性,使客户终端获知相应媒体内容能获取的时间;同时,客户终端通过宽带网络中相应的方法确定当前宽带网络下的网络带宽及内容从宽带到客户端的单向网络延时,通过宽带源内容的可获取时间和宽带信道的延迟,客户终端计算出保证当前广播与宽带内容同步所需的缓存窗口大小以及发送请求的时间。
[0011] 与现有技术相比,本发明具有如下的有益效果:
[0012] 采用本发明的技术方案,针对已有的MMT中的信令,通过在信令或其他地方加入新的属性,解决了因宽带中网络阻塞而导致的媒体内容难以同步的问题,从而解决因IP网络拥塞带来的同步问题。

附图说明

[0013] 通过阅读参照以下附图对非限制性实施例所作的详细描述,本发明的其它特征、目的和优点将会变得更明显:
[0014] 图1是异构网络的模型示意图;
[0015] 图2是计算客户端发送请求的动态时间窗口及终端分配的缓存窗口大小的流程图。

具体实施方式

[0016] 下面结合具体实施例对本发明进行详细说明。以下实施例将有助于本领域的技术人员进一步理解本发明,但不以任何形式限制本发明。应当指出的是,对本领域的普通技术人员来说,在不脱离本发明构思的前提下,还可以做出若干变形和改进。这些都属于本发明的保护范围。
[0017] 如今,基于异构网络的多样化终端呈现方式已成为发展的趋势。在观看高质量广播视频节目的同时,人们对于多样化的网络媒体服务的诉求也越来越高。在由广播和宽带网络组成的异构系统中,由CI来控制客户端播放广播与宽带内容的时间与空间布局,实现媒体内容的同步。一般来说,由广播通道过来的媒体内容有很小并且固定的延时,因此对于同步没有影响;而从宽带过来的媒体内容如音视频、字幕、多媒体应用等内容易受当前IP网络影响,产生较大且抖动的延时,给内容同步带来了问题;同时,从宽带过来的内容存在有效访问期的问题,即从某个时间点开始可以访问,到某个时间点前有效。因此本发明给出了内容的有效时间信息,并设计了一种在终端提前请求该信息的发送,并为相应内容分配缓存窗口的机制。
[0018] 为了解决问题,首先在原有的信令或其他地方给每部分内容都加入一个新属性:Available_Time,用以说明宽带中待传送的该内容在内容提供商处准备好并可以开始传输的时间,以及结束访问时间。其赋值遵循如下规则:
[0019] 1)时间未知
[0020] 若服务器端还不能确定待传送的内容准备好的时间,则Available_Time赋值为"unknown";同时为了考虑系统的兼容性,若服务器端发送的信令中未添加Available_Time属性,则终端解析为Available_Time为未知。
[0021] 2)随时可以访问
[0022] 若服务器端的媒体内容随时可以访问与发送,则Available_Time赋值为"anytime"。
[0023] 3)某个特定时间开始后,一直有效
[0024] 若服务器端的内容在某个特定时间开始后一直有效,则Available_Time赋值为该特定的UTC时间,即"UTC1"。
[0025] 4)某个特定时间区域内有效
[0026] 若服务器端的内容在某个特定的时间区间内可获取,则Available_Time赋值为该时间区间,即"UTC1--UTC2",括号内为UTC。
[0027] 对于Available_Time的解析工作在终端完成
[0028] 同样可根据需要在信令或其他地方给每部分内容加入Asset_Size属性,用以表示该部分内容的大小。
[0029] 新添加的属性,Available_Time和Asset_Size,在系统中的具体位置可以根据需要添加在不同地方。比如CI,MPT,MPU等。下面就以这几个位置为例给予介绍。
[0030] 下面分别给出了在CI、MPT和MPU中添加Available_Time和Asset_Size属性的实例:
[0031] 1)在CI中添加新的属性
[0032] 若mediaSrc属性在MediaSync元素里,则将新添加的属性同样放在此元素中,如下:
[0033]
[0034] 若mediaSrc属性在MediaSync元素的子元素sourceList里,则新添加的属性放在相应的sourceList中,如下:
[0035]
[0036]
[0037] 2)在MPT中添加新的属性
[0038] 可以在MPT表中每个asset增加Asset_Size,描述其大小。
[0039] 若内容有多个源地址,则为每个源地址中的该部分内容都分配一个Available_Time;若该内容只有一个源地址,则只为该地址的源内容分配一个Available_Time。具体实现方式可以有多种,下面给出两个示例。
[0040] A.在MPT中加入Available_Time_Type和MMT_Available_Time_info(),以四种情况为例子,我们可以分配Available_Time_Type两个比特,如果可获取时间的分类情况更多,可考虑分配更多比特。MMT_Available_Time_info()说明了媒体内容的可获取时间或可获取时间区间信息。MPT如下:
[0041] MP table Syntax
[0042]
[0043]
[0044]
[0045] MMT_Available_Time_info Syntax
[0046]
[0047] Available_Time_Type:这两个比特表明在可获取时间的类型,说明如下:
[0048] Value of Available_Time_Type
[0049]
[0050] B.只在MPT中加入MMT_Available_Time_info(),MMT_Available_Time_info()说明了媒体内容的可获取时间或可获取时间区间信息。MPT如下:
[0051] MP table Syntax
[0052]
[0053]
[0054]
[0055] MMT_Available_Time_info Syntax
[0056]
[0057] available_begin和available_end的用法如下
[0058]
[0059] 3)在MPU中添加新的属性
[0060] 在MPU中因为描述的是单个MPU的大小,故此处取mpu_size
[0061]
[0062] 动态分配缓存窗口大小的缓存机制设计思路如下:CI文件中已有的属性已包括对象的正常开始呈现的时间—begin,同时可通过IP网络内的相应方法,如发送ICMP报文段的方式得到当前的单向宽带网络延时—t1与宽带网络的带宽—Bandwidth。在信令中或其他地方加入宽带内容可获取时间的属性Available_Time和Asset_Size后:设定一个阈值Threshold,若延时t1小于此阈值,则该延时可忽略不计,系统无需为宽带传输的媒体内容分配额外缓存;若t1大于此阈值,则可通过具体方案中的方法确定请求提前发送宽带中媒体内容的时间区间,并为终端分配缓存窗口。若网络延时很大,内容提供商提供的Available_Time已不满足提前缓存保持同步的条件,则直接将该宽带通道传送的辅助内容丢弃。
[0063] 具体方案如下(下面的步骤可以根据实际情况选用,组合):
[0064] 1)在信令中或其他地方加入对应内容的Available_Time和Asset_Size属性;
[0065] 2)客户终端通过IP网络内的相应方法,如通过发送ICMP报文段,得到当前宽带网络的单向延时t1与宽带网络的带宽Bandwidth;
[0066] 3)客户端通过解析信令(如MPT、CI)得到对应媒体内容的可获取时间(Available_Time),正常播放时间(begin)以及对应内容的大小(Asset_Size);
[0067] 4)若t1Threshold,则通过如下方法计算出终端发送请求的时间窗口和终端分配的缓存大小:
[0068] ①计算服务商传输一个内容单元所需要的时间:Data_Transfer_Time,此时间可由一个内容单元的大小和当前宽带环境下比特率来计算获取;
[0069] ②若Available_Time为"unknown"或CI中并无此属性,则不进行处理;若Available_Time为"anytime",则跳过此步骤进入③;若Available_Time为一个特定的UTC时间一个UTC时间的区间,则取最早的时间进行如下判断:
[0070] Available_Time+t1+Data_Transfer_Time
[0071] 若条件(1)不成立,则表明待传送的媒体内容可获取时间太晚,在当前网络的延时下不能及时到达终端,故丢弃此部分内容;若条件(1)成立,则表明当前网络延时带来的不同步问题可由提前缓存来解决,进行下一步计算;
[0072] ③计算终端请求提前发送媒体内容的时间区间:
[0073] 请求最早时间:
[0074] Earliest_Request_Time=Available_Time-t1  (2)
[0075] 请求最晚时间:
[0076] Latest_Request_Time=begin-2t1-Data_Transfer_Time  (3)
[0077] 实际请求的时间介于两个时间点之间:
[0078] Earliest_Request_Time
[0080] Receive_Time=Actual_Request_Time+2t1  (5)
[0081] 终端到begin时间点之前接收数据的时间为:
[0082] Δ t=begin-Receive_Time
[0083] (6)
[0084] ⑤如果CI中给出了Asset_Size属性,则终端分配的缓存窗口大小为:
[0085] Buffer_Size=min{Δt*bitrate,Asset_Size}  (7)
[0086] 若果CI中未给出Asset_Size属性,则终端分配的缓存窗口大小为:
[0087] Buffer_Size=Δt*bitrate  (8)
[0088] 计算流程图见附图2,方案中用到的变量及其含义总结如下表:
[0089]变量 含义及用途
begin 客户端正常播放特定内容的时间
Available_Time 待传送的内容在内容提供商处准备好并可以开始传输的时间Asset_Size 媒体内容的大小
t1 在宽带通道中的单向网络延时
Bandwidth 宽带网络的带宽
Threshold 用以判定当前延时是否会影响主辅视频的同步
Earliest_Request_Time 终端请求的最早时间
Latest_Request_Time 终端请求的最晚时间
Actual_Request_Time 终端实际请求的时间
Receive_Time 终端开始接受数据的时间
Buffer_Size 终端分配的缓存窗口大小
[0090] 下面给出一个实例:
[0091] 已知客户端在接收到对应信令时系统的当前状态如下,此处设定Threshold为0.1s,Data_Transfer_Time一般依据当时data大小和比特率,这里取3s
[0092]参数 取值
t1 10s
Bandwidth 10Mbps
Threshold 0.1s
[0093] 该信令包含的一个图像和音频的文件信息如下:
[0094]
[0095] 当前的网络延时为10s,远大于0.1s的Threshold,说明10s的宽带延时是不可接受的,需要提前请求内容的发送。
[0096] 对于Image.1,其可获取时间为北京时间4:59:50后的所有时间,但其可获取时间太靠后,不满足条件(1),即不能再播放时将内容发送至终端,故此内容丢弃。
[0097] 对于Audio.1,其可获取时间在北京时间4:59:20至4:59:50之间,其4:59:20满足条件(1),故可由式(2)和(3)得到请求发送的时间区间:
[0098] Earliest_Request_Time=2015-01-31T4:59:10+08:00
[0099] Latest_Request_Time=2015-01-31T4:59:37+08:00
[0100] 若取实际的请求时间为:
[0101] Actual_Request_Time=2015-01-31T4:59:30+08:00
[0102] 若当前比特率为200Kb/s,则可得各变量参数如下
[0103]Earliest_Request_Time 2015-01-31T4:59:10+08:00
Latest_Request_Time 2015-01-31T4:59:37+08:00
Actual_Request_Time 2015-01-31T4:59:30+08:00
Receive_Time 2015-01-31T4:59:50+08:00
Δt 20s
Δt*bitrate 4M
Buffer_Size 2Mb
[0104] 其中Buffer_Size取Δt*bitrate与Asset_Size的最小值,即2Mb。
[0105] 故在此实例中,Image.1因为Available_Time时间点给定较晚丢弃,Audio.1可由CI中给定的Available_Time和Asset_Size得到终端应该提前请求发送的时间和应该准备的缓存窗口大小。
[0106] 以上对本发明的具体实施例进行了描述。需要理解的是,本发明并不局限于上述特定实施方式,本领域技术人员可以在权利要求的范围内做出各种变形或修改,这并不影响本发明的实质内容。