Most of your streaming audience wants something that just works reliably; they don’t care about the tech behind it.

Many audio streams currently in service fall short. However, it is up to the content providers to make it work. Streaming audio has now evolved past legacy protocols allowing reliable content delivery to mobile and connected car dashboards, where all the audience growth continues.

Currently, much live streaming audio is delivered using the popular SHOUTcast ICY protocol through a SHOUTcast or Icecast2 Streaming Server, or some proprietary derivation. Although these initial protocols served well (pun intended) initially, professional streaming requirements have changed in favor of a completely new approach using new streaming protocols that address new demands, provide performance increases, and lower deployment and operating cost. Standards-based HLS/DASH segmented streaming now provides all things necessary; however, it must be implemented correctly. Not all HLS/DASH found in the wild is equal or compatible.

Don’t Get Left Behind

Most video content providers have already upgraded their streaming technology to segmented streaming. It has made OTT video streaming commercially viable and has helped drive the cord-cutting trend.

If your audio stream provider and content distribution network do not support standards-based IETF Compliant HLS/DASH and do not closely follow the HLS/DASH specifications, make a change now before you are left behind in streaming technology. Be among the recognized video brands with streaming technology that is done the “write” way. Many developers and providers are unaware of these changes and are currently offering obsolete streaming technologies and services at very high costs.

To give listeners a good, reliable streaming experience and to keep them coming back, audio content providers need the same streaming technology changes that video has made. Great media should work, look, and sound the best it can, using the most up to date technology available on today’s computers and mobile devices. It is your product. You
owe this to yourself and your audience. Your revenue now depends upon it.

The Problem

The main problem with audio streaming has been the lack of any formal standards that professionals require.

Because of this, many existing streaming protocols have been modified and hacked to the point of becoming proprietary, leading to compatibility issues among streaming servers and player clients and devices.

This is NOT conducive to good business, frustrates users, and ultimately loses audience. AM/MW/FM transmitters all use standards-based protocols to transmit and receive, and have enjoyed huge success. As a result, any radio can receive any off-air signal. Compare this with the plethora of incompatible streaming players now in the hands of
consumers. Simply put, streaming practices need to change if streaming audio is to continue to be a major driving force for audio content delivery. Standards-based IETF-HLS/MPEG-DASH offers this opportunity, addressing all the features and opinions that professionals need.

RTSP/RTP was basically the first streaming protocol for the Internet and was described under several Internet RFC (Request For Comments) open standards. All approved Internet standards have a corresponding RFC for compatibility and interoperability. This is extremely important for applications such as broadcasting and netcasting to maximize audience reach.

If you stream using proprietary protocols, you limit your coverage and reduce your revenue opportunities. RTSP/RTP is very capable, being extensible in many ways. Unfortunately, that brought complexity to the protocol, and web browsers did not have direct support for RTSP/RTP. Furthermore, many developers didn’t understand it and all its available options. So to simplify audio streaming, SHOUTcast ICY using MP3 was created.

SHOUTcast ICY (I Can Yell) (no joke) was originally a proprietary streaming audio protocol developed in 1998 by Nullsoft, Stephen ‘Tag’ Loomis, Tom Pepper and Justin Frankel for use with a proprietary non-open-source streaming server, Nullsoft DNAS, which has very limited features and extensibility. This specific protocol never became an
Internet RFC, but was very similar to standard web HTTP with non-standard headers, yet different enough to cause browser incompatubilities. Traffic appeared as an infinite web page that would download continuously for the listening duration.

Around the same time, Icecast appeared. Developed by Jack Moffet and Barath Raghavan, it originally used the Audiocast protocol. In 2004 they moved to Icecast2 using the easily reverse-engineered SHOUTcast ICY protocol for MP3 and open-source Ogg-Vorbis codecs. (Unlike MP3, Ogg-Vorbis never achieved wide commercial acceptance.) Icecast2 provided an advanced open-source ICY protocol server that was mostly, but not
entirely, comparable with SHOUTcast.

For reliability both the SHOUTcast and Icecast2 ICY protocols require an encoder and decoder/player connection with a constant data stream, requiring perfect Internet service, which the Internet was never designed to deliver. Furthermore, they were not designed with much consideration for the professional content provider. These protocols only provide basic streaming with limited metadata capabilities. ICY does not scale easily for large audiences, since it can’t take advantage of standard cache configurations, and is therefore more costly to deliver. Unfortunately, despite all of its shortcomings, this is the most common live streaming protocol in use today, which has led to proprietary customization and caused further compatibility and reliability issues.

Find the full white paper here.