Question

软件信息：

* ubuntu 16.04
* Nginx 1.15.1

所以最近我在nginx上阅读了有关HLS流的低延迟的信息，并在这里找到了解决方案：Reduce HLS latency from +30 seconds

这会将等待时间减少到〜7秒，但是我还想对流进行转码，因此等待时间并不重要（我只希望源是低等待时间，但是如果转码版本可以，它将额外），但是当我这样做时，源代码没有问题，但转码版本产生了问题，实际上，浏览器脚本将尝试播放已删除的片段的早期版本，从而导致404错误。那么如何解决该问题，以便可以使源达到约7秒的延迟，并使转码版本同时工作？

我当前的配置：

FFMPEG转码

-c:v copy -preset:v ultrafast -b:v 6000K -c:a copy -tune zerolatency -f flv rtmp://localhost/stream/$name_source
-c:v libx264 -preset ultrafast -s 852x480 -tune fastdecode -b:v 1000K -c:a copy -tune zerolatency -f flv rtmp://localhost/stream/$name_medium
-c:v libx264 -preset ultrafast -s 1280x720 -tune fastdecode -b:v 3500K -c:a copy -tune zerolatency -f flv rtmp://localhost/stream/$name_high
-c:v libx264 -preset ultrafast -s 426x240 -b:v 400K -c:a copy -tune fastdecode -tune zerolatency -f flv rtmp://localhost/stream/$name_low

HLS：

hls_fragment 1s;
hls_playlist_length 4s;
hls_variant _source BANDWIDTH=600000;
hls_variant _high BANDWIDTH=350000;
hls_variant _medium BANDWIDTH=100000;
hls_variant _low BANDWIDTH=40000;

Answer 1

当我将片段和播放列表的长度设置为相同的时间时，我就能使其正常工作。

hls_fragment 2s;
hls_playlist_length 2s;

以上是您必须进行转码的最低代码，这大约需要5-6秒的延迟，而转码的时间大约是13秒。

仍然不建议这样做，因为它可能会导致一些问题

降低的HLS延迟会导致转码后的播放列表问题

1 个答案: