Hacker News Reader

Comment by shittyadmin | Hacker News Reader

The chunk based solutions are rather high latency though, at least in typical implementations streaming sites relying on them are often 10-30 seconds behind live data.

IceCast is much faster than that at least - and not so problematic - typically the stream starts a bit before live data so you have a second or two in which you can reconnect and match up the current ending of the data.

EDIT: Both of these are abuses of HTTP though while they probably should be using a dedicated UDP-based streaming protocol which wouldn't suffer from any of these issues. WebRTC goes in the right direction by using RTP for this.

View on HN

In my [limited] experience, the latency [associated with chunked streaming like HLS] is often treated as a feature by at least radio stations. It gives them a window for dynamic ad insertion. As long as the stream is quality and resumable then the latency with regard to the live AM/FM broadcasts has been of negligible importance— at least not high on the priority list.

That's experience with one company owning a group of stations across the country. I don't know how other stations or groups work with it. These stations aren't typically critical data. Includes a couple of news stations, but a few seconds latency for a breaking story won't 'break' them.

There are a lot of work in the area of reducing this for segmented output too. Including solutions such as CMAF. BBC has a lot of information about their testing here: https://www.bbc.co.uk/rd/projects/low-latency-live-streaming...

I've seen solutions from Akamai that go down to a second or two even with this approach, so i think it's coming pretty close.

Depends on how you configure buffers, chunk sizes, key frames and other parameters. It is possible to get the same or better latency with chunked streaming compared to Icecast. With DASH the client knows the timestamps of available chunks and the server time, so it can deliberately play as close to the live edge as possible or keep a larger buffer depending on network conditions.

Edit: If you want really really low latencies (<100ms) you can use WebRTC for broadcast streaming to the browser. If the network has a hiccup it will instantly show in the stream though, so for robustness chunked HTTP streaming is a much better choice at the cost of a few seconds latency.

Also how your end user configures their router (buffer bloat would be compounded here I think)

Reply on news.ycombinator.com