Comment by moreentropy | Hacker News Reader

Comment by moreentropy | Hacker News Reader

Parent Full thread

Icecast existed for ages. It's streaming protocol (about the same as the proprietary shoutcast) is basically an endless progressive HTTP download, which means you can simply put a stream URL into an audio tag in HTML and the stream plays in a browser or save a stream using wget/curl.

The protocol is/was directly supported by about any MP3 player software since the end of the 90s, including display of metadata updated (song/show title). One problem with Icecast streams is that content is streamed through a long lasting HTTP request. If the TCP connection breaks there is no way to recover without interrupting playback. Some Antivirus software will think the stream is a downloadable file, so it will withhold data from the browser while trying to download the whole stream. Using HTTPS for Icecast helps to keep most AV software from MITMing the stream.

If you implement A/V streaming to the web today, you most probably would want to use chunked streaming with modern protocols like HLS or DASH. ffmpeg can do this. The encoder will save a live a/v source into small fragments (like 2 seconds) on a webserver that the browser can download, reassemble and play one after the other. If one chunk download fails (because of a network change on the client side), the browser might be able to retry downloading chunks.

Caching/distribution also works using standard HTTP accelerators with chunked streaming while you need to chain multiple Icecast servers if you want to scale Icecast.

Edit and shameless self plug: I wrote an Icecast exporter a few years ago to get nice streaming stats in Prometheus: https://github.com/markuslindenberg/icecast_exporter

Additional benefit for chunked streaming: It continues working when switching networks (going from home wifi to mobile network etc.) and the client can switch to different quality based on bandwidth (especially for video)

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.

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)

A significant advantage of chunked (DASH, HLS) is bandwidth adaptation. This is done with substantial magic on the encode side to produce chunks of various bitrate all aligned. Then the client can move to a higher or lower bandwidth stream but without much fuss in maintaining the timeline continuity of the playback. It's been a while since I worked with media streaming, I'm interested to check in with ffmpeg to see how far it has progressed on this.

Pretty far in the current release. I'm using ffmpeg to encode to HLS/MPEG/AAC and DASH/WebM/OPUS w/ three different bitrates each. All necessary HLS Playlists and DASH Manifests are created and updated, old chunks are automatically deleted.

Reply on news.ycombinator.com