减少 HLS 流式传输 FFMPEG 的延迟答案

【问题标题】：Reduce Latency For HLS Streaming FFMPEG减少 HLS 流式传输 FFMPEG 的延迟
【发布时间】：2017-09-20 03:20:30
【问题描述】：

我通过 ffmpeg 使用了 hls 流。
在开始流式传输延迟存在几秒钟。
当我想在非常延迟的情况下从流中的 4k 视频中进行流式传输时。
我能做什么？

【问题讨论】：

您是在谈论减少编码延迟到播放直播流，还是只是询问在播放视频之前所需的缓冲过程，这只会被高比特率视频延长，如4k 视频？
@Brad 我说的是减少编码延迟到直播流的播放。但是请帮我解决你问我的问题。我使用下面的代码进行流式传输。你有什么建议可以根据我的需要做得更好。 ffmpeg -re -i input.mp4 -s cga -f hls -hls_list_size 0 -g 48 -vcodec libx264 -c:a aac 200p/out.m3u8 -s nhd -f hls -hls_list_size 0 -g 48 -vcodec libx264 -c:a aac 360p/out.m3u8

标签： ffmpeg streaming video-streaming http-live-streaming

【解决方案1】：

现在有针对low latency HLS in ffmpeg 的特定选项。虽然目前支持“社区”低延迟 (LHLS)，但在主要 HLS 播放器之一 (hls.js) 中有 moves to deprecate 它支持 Apple 对其 Low Latency HLS 的最新演变。

【讨论】：

【解决方案2】：

4k 视频

...

流式传输开始时存在几秒钟的延迟

是的，当然可以。缓冲足够的数据以播放非常高的比特率需要时间。不仅如此，您的 HLS 播放器通常需要几个片段才能开始解码。正如@iangetz 所说，您可以减少段长度，但现在由于所有额外的 HTTP 请求，您将面临更多开销。

减少 HLS 流的延迟

不要使用 HLS。 HLS 和任何其他分段流协议（如 DASH）都针对低延迟进行了优化。它针对 HTTP CDN 的重复使用、可以在网络变化（例如从 WiFi 到 LTE 时）以及客户端可选（通常是动态）质量方面进行了优化。

分段协议的本质要求将相对较大的缓冲区分块，然后单独上传到服务器/CDN。这确实很有用，但如果您需要低延迟，这不是一个很好的折衷方案。

如果延迟对您很重要，您需要一种完全不同的技术。看看 WebRTC。使用这项技术，实时视频流，编解码器针对延迟而不是质量进行了优化，可靠性降低，有利于延迟。它还需要对配电基础设施进行大量投资。

我无法想象这样一种情况，即关心 4k 视频的人会认为降低质量值得以低延迟进行权衡。你不可能拥有你想要的一切……你必须选择对你来说真正重要的东西并从那里优化。如果您想要低延迟，您将不得不降低质量并在基础设施上花费大量金钱和时间来支持这项工作。如果您想要高质量和可靠的流，您可以在使用 DASH（或 HLS）在现有的基于 HTTP 的 CDN 上分发时保持良好的编码参数。

【讨论】：

谢谢，还有一个问题，我对这个链接一无所知https://trac.ffmpeg.org/wiki/HWAccelIntro，但我想知道是否可以帮助我降低 hls 直播的延迟？
@parsa 否。硬件加速只允许您将编码工作卸载到 GPU 上，而不是在 CPU 上运行。

【解决方案3】：

这可能是播放器在开始播放之前填充了足够的内容。

您可以使用“hls_time”来减小视频片段的大小，这样每个片段的下载速度都会更快，但这会向您的服务器产生更多的 HTTP 请求。此外，您可以使用 'hls_init_time' 减少第一段，并保持其他段不变。

http://ffmpeg.org/ffmpeg-all.html#hls-1

hls_init_time seconds 设置初始目标段长度秒。默认值为 0。段将在下一个关键帧上被剪切在此时间过后，第一个 m3u8 列表已通过。初始后播放列表已填充 ffmpeg 将在持续时间等于 hls_time

hls_time seconds 以秒为单位设置目标段长度。默认值为2。段将在此时间之后的下一个关键帧上被剪切已经过去了。

另一种选择是减少播放器开始播放前所需的缓冲量。我不确定你使用的是什么播放器，但大多数都有这个选项。

【讨论】：