目录

沉浸式推流中应用层的优化


背景

大多数的 HAS 方案使用 HTTP/1.1 协议进行请求-回应的事务来取得需要的资源、缓冲取到的视频段并以线性的顺序播放。传统的 HAS 中,只需要 1 个 GET 请求来取得下一个视频的暂时的部分。只要视频段的持续时间比网络内的时延高,这种方法就可行。

在基于 VR 的 HAS 方案中,播放 1 条视频片段就需要取得多种资源:1 次 GET 请求需要同时请求基础的 tile 层和每个空间视频 tile。使用 4x4 的 tile 方案时,客户端需要发起不少于 17 次 GET 请求。使用 1 s 数量级的分段持续时间,即使是 20 ms 的微小网络延迟也会显着阻碍客户端和服务器之间的整体吞吐量,因此会导致较低的视频质量。

解决方案

使用多条持久的 TCP 连接

大多数的现代浏览器都支持同时建立并维持多达 6 条 TCP 连接来减少页面加载时间,并行地获取请求的资源。这允许增加整体吞吐量,并部分消除网络延迟引入的空闲 RTT 周期。

类似地,基于 VR 的 HAS 客户端可以使用多个 TCP 连接并行下载不同的 tile。

使用 HTTP/2 协议的服务端 push 特性

HTTP/2 协议引入了请求和相应的多路复用、头部压缩和请求优先级的特性,这可以减少页面加载时间。

服务端直接 push 短视频片段可以减少视频的启动时间和端到端延迟。

并且,服务端 push 特性可以应用在基于 tile 的 VR 视频推流中,客户端可以向服务器同时请求一条视频片段的所有 tile。

服务端可以使用特制的请求处理器,允许客户端为每个 tile 定义一系列质量等级。

因此可以将应用的启发式自适应的速率的决定传达给服务器,这允许客户端以期望的质量级别取得所有图块。