是否可以通过 HTTP/2 进行 HLS 流式传输，它是否会比通过 HTTP/1.1 更好地延迟？答案

【问题标题】：Is it possible to do HLS streaming over HTTP/2, and will it be better latency-wise than over HTTP/1.1?是否可以通过 HTTP/2 进行 HLS 流式传输，它是否会比通过 HTTP/1.1 更好地延迟？
【发布时间】：2019-05-10 23:51:26
【问题描述】：

由于 HTTP/2.0 利用请求多路复用，我一直想知道是否使用 HTTP/2.0 而不是 HTTP/1.1 进行 HLS 流传输。

我当前的 HLS 流似乎使用 HTTP/1.1，至少，这是我在网络选项卡中检查我的 Native HLS Playback Chrome 扩展时收集到的，所有媒体播放列表和 TS 块都通过 HTTP/1.1 传输.

此时，我没有找到有关 HLS over HTTP/2.0 的信息，但有一些有关 MPEG-DASH over HTTP/2.0 的信息，所以我想知道 HLS over HTTP/2.0 是否可行。如果是，我会在服务器和客户端设备之间获得更低的延迟吗？

相关问题：Exoplayer 是否支持 HLS over HTTP/2.0？

【问题讨论】：

如果您想要低延迟，请不要使用 DASH 或 HLS 等分段传输。通过一些技巧，您当然可以降低它们的延迟，但使用直接 HTTP 渐进式要简单得多。
这是在玩 websockets 吗？
如果数据只在一个方向流动，则不需要 Web 套接字。您可以让服务器组装一个流并按原样通过 HTTP 发送它。不需要额外的层。播放在一定程度上可以是一个简单的<video> 元素，但您需要使用 MSE 来控制缓冲等等。
这对浏览器来说可能很棒，但我的优先目标是带有Exoplayer 的Android 设备。虽然也许我可以用带有单个 <video> 元素的 WebView 替换它......
即使是普通的 MediaPlayer 也支持 HTTP Progressive...

标签： http video-streaming http-live-streaming http2 exoplayer

【解决方案1】：

是的，有可能，不，它不会减少延迟。

【讨论】：

我认为它可以，因为并行请求等等。顺便说一句，从 TS 迁移到 CMAF 会减少延迟吗？
这是一个复杂的问题。通常，TS 的延迟尽可能低。然而，低延迟 cmaf 可以匹配它（标准 cmaf 延迟较高）。由于其结构，mpd 可能低于 m3u8。但是 m3u8 有非标准的扩展，可以将其降低到 mpd 级别。通常，您的延迟将由播放器决定，而不是格式。
我正在使用Exoplayer，但我很困惑我还可以更改哪些内容（DefaultLoadControl 缓冲区参数除外）以确保将延迟降到最低。我应该只添加由 1 分配的服务器的初始段号吗？

【解决方案2】：

HLS 和 Dash 是 HTTP 之上的协议，例如根据 HTTP GET 请求定义。它们适用于 HTTP/1.1 和 HTTP/2。唯一的问题是客户端是否支持 HTTP/2，以及为流提供服务的服务器是否支持 HTTP/2。这些问题需要针对每个应用单独提出。

我的估计是 HTTP/2 支持不会为这些用例带来太多优势。 HTTP/2 最擅长在单个 TCP 连接上多路复用大量小请求，并避免创建新连接的开销。使用视频流，没有那么多并发的小请求 - 而是客户端逐个获取更大的块。这在 HTTP/1.1 连接上使用 keep-alive 应该可以很好地工作（每个请求也不需要新连接 - 它只是不支持并行请求）。

对于这种特殊用例，HTTP/1.1 可能比 HTTP/2 更有效，因为在 TCP 之上没有另一个流控制机制的开销。

【讨论】：

猜猜我必须坚持使用 HTTP/1.1。另外，HTTP/1.1 + 块传输编码呢？ CTE 是否已经成为 HLS 或 MPEG-DASH 软件包的一部分？如果没有，我应该启用它吗？
@Gensoukyou1337 一个很好的参考是this paper。 this one 展示了如何实现更低的延迟

【解决方案3】：

Apple 最近发布了低延迟规范。它包括对极低延迟的 HTTP/2 推送支持。

查看他们的规范here

它可能会将您的视频数据以与其他实时协议一样快的速度传输到 safari 和 iOS 中。 :)

【讨论】：