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.
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.
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.
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.
I still listen to several of these types of stations (even ran one for a few years in the early/mid 2000's).
Mine was essentially just an unlicensed stream of whatever I'd put into a huge Winamp Playlist, but I also had some friends from an online forum and we would put together silly jingles and "station ID" clips to sprinkle throughout the day as well.
Hosting was provided by a friend who worked for a small ISP/hosting company and he just gave me free access, saying that nothing I could use would make a dent in their available bandwidth (and he would let me know if that changed).
It was pretty fun and I even went "live" on the mic occasionally if I knew there were people listening, but eventually I started looking into going "legit". For a while it was looking like I could actually afford the basic ASCAP/BMI/etc. license with hobby money but that changed when laws were changed to require you to pay royalties per-song-per-listener (unlike terrestrial radio).
Ran it unlicensed for a little while after that but eventually shut it off as it got to be a hassle and I had too many other things going on in life. Still, it was cool to get emails from people around the world thanking me for my stream.
At a time when friends were paying monthly subscriptions for XM radio, I plugged my little Palm Treo into the car stereo and had my own station to listen to all day. Before commercial streaming, there weren't many similar options but a good set of Shoutcast/Icecast bookmarks gave me the best radio dial I could imagine...without the subscription!
I still listen to several of these stations when I'm not listening to something in my own library or the local NPR affiliate. There's something to be said for real human-programmed playlists from people who love music. I know Spotify playlists serve this purpose for many folks, but I haven't really gotten into that since I have so many options.
"For a while it was looking like I could actually afford the basic ASCAP/BMI/etc. license with hobby money but that changed when laws were changed to require you to pay royalties per-song-per-listener (unlike terrestrial radio)."
^^^ This is what really killed hobby streaming. The fear of getting popular and reported had a serious chilling effect on this scene. Coupled with the rise of streaming services that changed the music paradigm from ownership to on-demand access.
Yes the platforms had a bit of a learning curve... hand editing icecast config.xml beyond basic settings could be daunting.
But I still run icecast and shoutcast servers on digitalocean for $10/month with an autodj randomly cycling through my mp3 collection... comes in handy when entertaining and need my own music etc.
As a side-note - Nullsoft (shoutcast developer) was purchased by AOL and languished. Recently a French company radionomy purchased shoutcast from AOL and has relaunched it. They have a pretty mature radio broadcasting platform built on it. (I don't work there just admire their product)
That was really cool to read and I appreciate the links. Can you talk more about your setup on DO? Why are both icecast and shoutcast servers needed? And did you transfer all of your music to DO? Thanks!
The Icecast/Shoutcast protocol is really simple, and supported on basically all platforms. I've made some fun things with implementations [0] and I know a few guys who have made a business of it.
If you want to set up a radio station which just shuffles a big playlist and takes listener requests (like my friends and I did), you will probably find my buddy's kawa project a better solution:
We started with icecast+liquidsoap and replaced it because whoo-ee is it crufty. Also check out our Python daemon for controlling it, indexing music, searching the database, and taking requests:
Nominate an open source project home page and challenge someone to find out the programming language.
The longest time or most traversed links wins. Sometimes you can read the whole site, understand the features, the architecture, the license, the supported platforms, the whole FAQ, how to contribute, the bug tracker, the mailing list, and even get to the main page of the github site, all without ever seeing a statement about the implementation language. The developers writing the site take it so much for granted, they never mention it.
However, the more obscure or fanboyish the language, the more likely it is to be mentioned early. Those developers are proud and delighted to be using that niche esoteric language. In some cases, they take more pride in using that language than actually implementing something useful.
Of course, in this case, one might suspect that media libraries would be in C/C++, but there are many other fun examples out there. Do you have any strong contenders for Lang Whack champion?
Slightly off topic, but there is an internet radio station I have set as my morning alarm, when my radio turns on or I switch to that station it always plays their intro track, then a song.
The intro is just a short ~3 second "Welcome to...".
It's the only station I've witnessed that does this but I like it, I wonder if icecast has a feature like that.
Even more off topic, the Korean live streaming site Afreeca does something similar, when you get the hls segments the first 3 you get are called "pre loading" I am not really sure why there are there. Though I suspect it is because they usually breaks players so you can not play it without doing something about it.
I have to say, for someone who doesn't really know how those kind of things work (i usually work on web stuff) I tried to help a friend who had a radio already setup, and I couldn't wrap my head around how anything works.
The documentation is extremely poor (when any) and I'm still confused at the difference between icecast and ezstream, which does what and such.
It's too bad, because as another comment mentions, it does seem pretty simple and powerful once you know how it works, but the lack of documentation (official or not, yes I tried googling stuff) makes it almost impossible to do anything if you don't know how it works already.
I had similar experience when I played around with it a decade ago. I actually resorted to the closed source shoutcast server back then, which was almost plug and play, even though it was already pretty much abandoned software at that time.
A pleasant Icecast-using website is n10as (pronounced "antennas") radio[0]. I'm a longtime listener.
Personally, I like to use Icecast alongside Mixxx[1], an open-source DJ software that I highly recommend, to do live mixes of dance music over the web. Mixxx comes with configuration settings for broadcasting live audio within the program itself without the need for any extra client.
Reminds me of the 90s when there was a plethora of independent net radio stations. We ran a icecast server at work (in the 90s) with a multiperson playlist, the test lab had speakers so it would be the same music playing in my office an the lab. Fun stuff.
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