<p>The problem you're facing is the high latency of HLS, which causes a longer delay for viewers to see new content when switching live content, such as changing cameras or restarting the stream. In simple terms: How to reduce the end-to-end latency of HLS.</p>
<p>Generally, HLS latency is around 30 seconds. This is because TS segments are typically set to 10 seconds per TS file, and the window (number of TS files) is set to 6, resulting in a total duration of 60 seconds for TS files in the M3U8 playlist. If the player starts requesting segments from the middle position, i.e., from the third-to-last segment, the latency will naturally be around 30 seconds.</p>
<p>You can reduce these two parameters, for example, by changing the TS file duration to 2 seconds, which will result in a latency of 6 to 8 seconds. Due to the HLS segment and window mechanism, it is difficult to optimize the latency to less than 8 seconds, as players may encounter network delays, segment loading failures, and retries, with different behaviors for different players. For more details, please refer to <a href="https://ossrs.io/lts/en-us/docs/v5/doc/hls#hls-low-latency" rel="nofollow noreferrer">SRS HLS Latency</a>. The config for SRS media server:</p>
<pre><code>vhost __defaultVhost__ {
    hls {
        enabled  on;
        hls_fragment 2;
        hls_window 10;
    }
}
</code></pre>
<p>If you want to reduce the latency to within 3 seconds, you need to change the streaming protocol to HTTP-FLV. For more information, please refer to <a href="https://ossrs.io/lts/en-us/docs/v5/doc/flv" rel="nofollow noreferrer">SRS FLV</a>. Since iOS Safari does not yet support <a href="https://caniuse.com/?search=MSE" rel="nofollow noreferrer">MSE</a>, you still need to use HLS or WebRTC protocol. The config for SRS media server:</p>
<pre><code>vhost __defaultVhost__ {
    http_remux {
        enabled on;
    }
}
</code></pre>
<p>If you want to reduce the latency to within 1 second or achieve low latency on iOS Safari, you can use the WebRTC protocol. For more information, please refer to <a href="https://ossrs.io/lts/en-us/docs/v5/doc/webrtc#rtmp-to-rtc" rel="nofollow noreferrer">SRS WebRTC</a>. The config for SRS media server:</p>
<pre><code>rtc_server {
    enabled on;
}
vhost __defaultVhost__ {
    rtc {
        enabled on;
        rtmp_to_rtc on;
    }
}
</code></pre>
<p>The root cause of this problem is not the Nginx distribution server, but the HLS segmentation mechanism and streaming protocol. It is recommended to switch to the SRS media server, which supports all these protocols and has the following workflow:</p>
<pre><code>OBS/FFmpeg --RTMP--&gt; SRS Media Server ---+--HTTP-FLV----&gt; Browser
                                         +--HLS/WebRTC--&gt; iOS Safari
</code></pre>
<blockquote>
<p>Note: WebRTC is generally used in the online conferencing field and is gradually being applied in low-latency broadcasting. The protocol used to push streams with WebRTC is called WHIP, similar to RTMP, and the protocol used to play streams with WebRTC is called WHEP, similar to HLS.</p>
</blockquote>

CC BY-SA 4.0
2023-10-21T23:58:55.587Z
2023-10-21T23:58:55.587Z
Winlin
<p>Any properly configured and performant web server is fine.  The choice of web server software has no direct bearing on HLS, any more or less than it does for any other kind of files.  That's the whole point of a segmented protocol... to re-use existing web infrastructure as streaming servers by turning a stream into a pile of files.</p>
<blockquote>
<p>Some times, changing the source of video takes more than usual time</p>
</blockquote>
<p>It's not clear specifically what you mean by this.  It really could be anything.  I'd assume that you're saying it is taking awhile to buffer video.  This probably has more to do with available bandwidth, latency from the client to the server, and perhaps encoding parameters as well.  None of that is directly related to your choice of web server.</p>
<p>If quick load times matter to you, consider using a CDN.</p>

CC BY-SA 4.0
2024-03-20T02:30:11.583Z
2024-03-20T02:30:11.583Z
Brad
<p>I'm working in a Live Streaming company in Singapore, and we use Nginx as the web server for HLS. Since Nginx is way better at processing static files. You never need to worry about the performance, nginx can utilize the 10G network card easily. </p>

CC BY-SA 4.0
2024-03-20T02:31:24.167Z
Nginx is great, but Apache can be performant too if you really want it to be.  The point being, HLS requires nothing particularly special of the server.
Brad
CC BY-SA 4.0
2018-07-02T03:11:34.703Z
2018-07-02T03:11:34.703Z
Michael Meepo
<p>I am trying to create a server that streams <strong>HLS</strong> to client. I created <strong>.m3u8</strong> file and for receive from client use <strong>Apache</strong> web server. Some times, changing the source of video takes more than usual time... I think that it refers to web server that responds to client with delay. Can anyone help me which web server is best to put <strong>m3u8</strong> file in that and get client stream from that? </p>

<p>My m3u8 file is :</p>

<pre><code>#EXTM3U
#EXT-X-VERSION:3
#EXT-X-TARGETDURATION:11
#EXT-X-MEDIA-SEQUENCE:11
#EXTINF:10.080000,
21.ts
#EXTINF:10.080000,
22.ts
#EXTINF:9.760000,
23.ts
#EXTINF:10.880000,
24.ts
#EXTINF:9.600000,
20.ts
</code></pre>

CC BY-SA 3.0
2016-03-02T09:39:31.997Z
It could also depend on the segment size. Depending on the implementation, the quality switch may only happen once the current segment is done playing. If your segments are really long, there can be a long delay depending on where in the segment you switched quality.
Matti Virkkunen
CC BY-SA 3.0
2016-03-02T09:43:08.807Z
@MattiVirkkunen i add my m3u8 file to question, duration is 11 second and apple recommend to set it around 10 sec, so i think it not refer to size, whats your opinion?
ALiS
CC BY-SA 3.0
2016-03-02T09:45:22.007Z
I don't understand what you mean by "i think it not refer to size". Does switching quality sometimes take longer than 10 seconds for you?
Matti Virkkunen
CC BY-SA 3.0
2016-03-02T09:46:13.523Z
no it take maximum 5 or 6 seccond
ALiS
CC BY-SA 3.0
2016-03-02T09:47:33.930Z
as you say if i set TARGETDURATION to lower value such as 2 second changing time is faster?
ALiS
CC BY-SA 3.0
2016-03-02T09:49:12.587Z
If it takes less than 10 seconds I don't think it's a problem with your web server. Either user a shorter segment size (this increases overhead though), or use a player that supports switching at the middle of a segment by redownloading a segment (there may be no point in doing this in practice). Personally I think <10 seconds is a perfectly reasonable delay.
Matti Virkkunen
CC BY-SA 3.0
2016-03-02T09:51:01.867Z
and its not refer to web server?
ALiS
CC BY-SA 3.0
2016-03-02T09:53:41.250Z
I have no idea what that means.
Matti Virkkunen
CC BY-SA 3.0
2016-03-07T14:41:26.707Z
Why is EXT-X-MEDIA-SEQUENCE set to 11?
avnr
CC BY-SA 3.0
2016-03-09T17:25:25.123Z
i think its not a important value... i test with value '5' but nothing change
ALiS
<streaming>
Which web server is better for HLS streaming?
ALiS
# Which web server is better for HLS streaming?

(Asked by: username_0 on 2016-03-02)

I am trying to create a server that streams HLS to client. I created .m3u8 file and for receive from client use Apache web server. Some times, changing the source of video takes more than usual time... I think that it refers to web server that responds to client with delay. Can anyone help me which web server is best to put m3u8 file in that and get client stream from that? 
My m3u8 file is :
#EXTM3U
#EXT-X-VERSION:3
#EXT-X-TARGETDURATION:11
#EXT-X-MEDIA-SEQUENCE:11
#EXTINF:10.080000,
21.ts
#EXTINF:10.080000,
22.ts
#EXTINF:9.760000,
23.ts
#EXTINF:10.880000,
24.ts
#EXTINF:9.600000,
20.ts

**Tags:** streaming

> **Comments:**
> **username_1**: It could also depend on the segment size. Depending on the implementation, the quality switch may only happen once the current segment is done playing. If your segments are really long, there can be a long delay depending on where in the segment you switched quality.  
> **username_0**: @MattiVirkkunen i add my m3u8 file to question, duration is 11 second and apple recommend to set it around 10 sec, so i think it not refer to size, whats your opinion?  
> **username_1**: I don't understand what you mean by "i think it not refer to size". Does switching quality sometimes take longer than 10 seconds for you?  
> **username_0**: no it take maximum 5 or 6 seccond  
> **username_0**: as you say if i set TARGETDURATION to lower value such as 2 second changing time is faster?  
> **username_1**: If it takes less than 10 seconds I don't think it's a problem with your web server. Either user a shorter segment size (this increases overhead though), or use a player that supports switching at the middle of a segment by redownloading a segment (there may be no point in doing this in practice). Personally I think <10 seconds is a perfectly reasonable delay.  
> **username_0**: and its not refer to web server?  
> **username_1**: I have no idea what that means.  
> **username_2**: Why is EXT-X-MEDIA-SEQUENCE set to 11?  
> **username_0**: i think its not a important value... i test with value '5' but nothing change  

---

## 3 answers

### Answer by username_3 on 2023-10-21. Score: 0

The problem you're facing is the high latency of HLS, which causes a longer delay for viewers to see new content when switching live content, such as changing cameras or restarting the stream. In simple terms: How to reduce the end-to-end latency of HLS.
Generally, HLS latency is around 30 seconds. This is because TS segments are typically set to 10 seconds per TS file, and the window (number of TS files) is set to 6, resulting in a total duration of 60 seconds for TS files in the M3U8 playlist. If the player starts requesting segments from the middle position, i.e., from the third-to-last segment, the latency will naturally be around 30 seconds.
You can reduce these two parameters, for example, by changing the TS file duration to 2 seconds, which will result in a latency of 6 to 8 seconds. Due to the HLS segment and window mechanism, it is difficult to optimize the latency to less than 8 seconds, as players may encounter network delays, segment loading failures, and retries, with different behaviors for different players. For more details, please refer to SRS HLS Latency. The config for SRS media server:
vhost __defaultVhost__ {
    hls {
        enabled  on;
        hls_fragment 2;
        hls_window 10;
    }
}

If you want to reduce the latency to within 3 seconds, you need to change the streaming protocol to HTTP-FLV. For more information, please refer to SRS FLV. Since iOS Safari does not yet support MSE, you still need to use HLS or WebRTC protocol. The config for SRS media server:
vhost __defaultVhost__ {
    http_remux {
        enabled on;
    }
}

If you want to reduce the latency to within 1 second or achieve low latency on iOS Safari, you can use the WebRTC protocol. For more information, please refer to SRS WebRTC. The config for SRS media server:
rtc_server {
    enabled on;
}
vhost __defaultVhost__ {
    rtc {
        enabled on;
        rtmp_to_rtc on;
    }
}

The root cause of this problem is not the Nginx distribution server, but the HLS segmentation mechanism and streaming protocol. It is recommended to switch to the SRS media server, which supports all these protocols and has the following workflow:
OBS/FFmpeg --RTMP--> SRS Media Server ---+--HTTP-FLV----> Browser
                                         +--HLS/WebRTC--> iOS Safari


Note: WebRTC is generally used in the online conferencing field and is gradually being applied in low-latency broadcasting. The protocol used to push streams with WebRTC is called WHIP, similar to RTMP, and the protocol used to play streams with WebRTC is called WHEP, similar to HLS.


---

### Answer by username_4 on 2024-03-20. Score: 0

Any properly configured and performant web server is fine. The choice of web server software has no direct bearing on HLS, any more or less than it does for any other kind of files. That's the whole point of a segmented protocol... to re-use existing web infrastructure as streaming servers by turning a stream into a pile of files.

> Some times, changing the source of video takes more than usual time

It's not clear specifically what you mean by this. It really could be anything. I'd assume that you're saying it is taking awhile to buffer video. This probably has more to do with available bandwidth, latency from the client to the server, and perhaps encoding parameters as well. None of that is directly related to your choice of web server.

If quick load times matter to you, consider using a CDN.


---

### Answer by username_5 on 2018-07-02. Score: -2

I'm working in a Live Streaming company in Singapore, and we use Nginx as the web server for HLS. Since Nginx is way better at processing static files. You never need to worry about the performance, nginx can utilize the 10G network card easily.

> **Comments:**
> **username_4**: Nginx is great, but Apache can be performant too if you really want it to be.  The point being, HLS requires nothing particularly special of the server.  

---

