最近看的论文一些笔记汇总
1 背景介绍
DASH具有分散性和client-pull的特性–>service providers控制较少=>无法提供高质量服务
DASH基本的分散和客户驱动的特性也有一些缺点。服务提供商不一定能控制客户端的行为。因此,很难提供一致或优质的服务。有许多情况下,体验质量会受到影响。在网络故障或重新配置后,MPD中公布的资源可能会过时,从而导致客户机错误地请求DASH段,并且不成功。当a mobile hand-over或缓存未命中被解释为带宽减少时,DASH客户端可能会错误地切换到质量较低的段。在内容交付网络(CDN)中,大量的实时数据流可能导致缓存未命中的级联。A DASH client可能不必要地启动较低质量segments的视频流,并且只有在获得了基于多个初始段的带宽信息后,才可以增加带宽。多个DASH客户端可能会争夺一个共享带宽,从而导致不必要的交互和可能的振荡。因此,服务提供商可能无法保证DASH的预服务质量,即使在 managed networks中,常规DASH客户端也无法充分利用所提供的服务质量特性。
DASH中QoE退化的主要原因及解决思路
- 流启动期间向最佳质量的缓慢收敛
客户端不仅会等待开始播放,直到其缓冲区达到一定的大小,而且还会从最低的视频质量开始,慢慢地向上倾斜,以找到最优的点。 - 当用户切换到不同的流(例如,信道更改)或同一流中的另一个点(例如,seeking)时,都会导致流会话重启动)
解决
讨论阻碍传递DASH内容的HTTP服务器与DASH客户端之间合作的主要问题。
专家们得出的结论是,通过网络交换客户端和服务器端的信息将减轻MPEG-DASH的客户端驱动理念中固有的一些问题。
例如,服务提供商对DASH客户端的决策几乎没有控制权。让DASH客户端了解服务器故障转移或其他类型的交付相关事件,可以减轻它们对最终用户体验质量的负面影响。另一方面