近年来，动态HTTP流媒体技术广泛应用于网络实时视频流媒体系统的开发与应用。许多服务商推出了与自身平台相关的DASH解决方案，如ADOBE-HDS，APPLE-HLS，MicroSoft-MSS等等[5-7]。同时，许多网络视频点播服务公司也开发了属于自己的DASH系统，如Netflix，Comcast等等。但是以上DASH系统或解决方案均是基于HTTP1。x协议开发的，不支持全双工模式。73792

动态HTTP流媒体技术支持点播和直播两种应用场景。动态直播HTTP流媒体技术即为动态HTTP流媒体技术在直播场景下的应用。在动态HTTP直播流媒体系统中，直播延迟主要由以下部分组成[8]：(1)切片延迟：媒体服务器端打包时以媒体片段为基本单元的，因此只有当一个片段完全生成后，才能进行打包并发送，该部分引入的延迟依赖于媒体片段的时长；(2)异步获取延迟：在DASH中，客户端无法获得服务器端关于媒体片段准备好的同步信号，客户端只能采用异步的POLL方式。同时，由于片段的时长会存在误差，即客户端根据MPD所计算的片段最早可访问时间并不一定代表在该时间后对应的媒体片段可以访问，这样就会引入轮询等待延迟；(3)HTTP下载延迟：片段下载时间由片段时长和可用带宽决定。通常情况下，片段下载时间与片段时长近似相等；(4)客户端缓存延迟：为了通过平滑的播放效果，客户端需维持一定时长的缓存。综上，在动态HTTP直播流媒体系统中，直播延迟通常为数个片段的时长，即与片段时长成正相关。为获得低的直播延迟，就需要降低片段的时长，而这会带来请求报文数量的迅速膨胀，导致客户端开销、服务器开销以及网络开销的迅速增加。

与传统的流媒体传输协议相比，DASH协议基于HTTP的特性增加了其异步获取延迟的问题。HTTP协议本质为PULL模式的，服务器需要等待客户端请求内容才能将对应的内容传送给客户端，而客户端只能通过轮询的方式来探测内容的可用性，即每隔固定时间间隔向服务器发送一个报文首部请求。相比客户端，服务器则对视频内容片段的可访问属性更为了解。为了解决上述异步获取延迟问题，相关研究人员提出了利用HTTPLongPolling机制替代广泛使用的轮询机制。在HTTPLongPolling中，客户端发送视频片段的请求，服务器接收到请求后，若该视频片段已存在，则向客户端发送相应的片段响应；若视频片段尚未准备好，则挂起请求，等待内容准备好后，再向客户端发送相应的片段响应。该方法可以在一定程度上解决轮询等待延迟，但无法解决在请求报文数量膨胀的问题，为解决该问题，相关研究人员又提出了利用分片传输编码的技术方案[9]。

为解决传统动态HTTP直播技术中，直播延迟与片段时长的依赖关系，文献[9]提出了基于分块传输编码的动态HTTP流媒体技术。[10]将该技术应用于超低延迟直播场景，将延迟降低至240ms，为动态HTTP流媒体技术在交互式直播场景的应用创造了可能，如视频会议、互动直播等。论文网

如图1。1所示，媒体片段进一步切分为多个子片段，客户端请求一个媒体片段，服务器依次发送生成的子片段，最后发送一个空子片段代表当前媒体片段结束。客户端可以不用维持缓存，收到子片段即解码播放，适用于超低延迟交互直播的应用场景。分块传输编码技术的实质就是，将一个片段进一步切分为数个子片段，每个子片段包含数帧或数十帧视频内容，子片段可进行独立传输和解码播放，该子片段即可以在HTTP/1。1中用Chunked-Transfer进行传输，也可以在HTTP/2中利用ServerPush机制进行传输。因此，采用分块传输编码机制要求片段采用如TS的自描述编码格式，类似于采用ISOBasemedia格式编码的DASH传输框架则不适用，因此导致了兼容性的问题。除了兼容性问题外，分块传输编码技术应用于直播场景还存在的码率调整力度无法动态调整的问题。一方面，若媒体片段时长过小，会造成报文膨胀；另一方面，若媒体片段时长过大，则会造成码率切换粒度过大，对带宽变化反应迟滞，易于出现缓存耗尽，播放卡顿。 动态HTTP流媒体技术研究现状:http://www.youerw.com/yanjiu/lunwen_83493.html