0

I'm going to make internet radio player program, but to do that, I need to know how the sound is streamed. I found on Wikipedia that UDP protocol can be used for streaming. I've also discovered that it's possible to use http, but I'm not sure if that is correct.

What are the commonly used methods/protocols to stream audio? And where can I check how the audio is streamed by internet radio station? ( http://radio17.pl/sluchaj )

Brad
  • 159,648
  • 54
  • 349
  • 530
sawim
  • 1,032
  • 8
  • 18
  • You very clearly did no searching here before posting, or you would have found [this question](http://stackoverflow.com/q/13624048/62576), which I found by simply looking at the list of *Related* questions on the right side of your question (beneath the job ads), and which would have been displayed to you as a possible duplicate while you were typing your question. – Ken White Apr 16 '16 at 22:32
  • @KenWhite Title aside, I think the specific questions asked here are different enough from what you linked to warrant a new post. – Brad Apr 17 '16 at 00:09

1 Answers1

0

I found on Wikipedia that UDP protocol can be used for streaming. I've also discovered that it's possible to use http

Yes, that's true. Traditional telephony applications used UDP because it reduces the network overhead a bit by avoiding the overhead of ensuring a reliable connection. Telephony requires low latency and efficient usage of bandwidth, but does not require that every bit sent over the wire be accurate. (If the sound of speech breaks up for a second, we can still understand what someone said as words are spread out over many audio frames. For longer corruption or drop-outs, we can still communicate due to context clues. It's far better to lower the latency than it is to ensure that the sound is reproduced 100% accurately.)

However, internet radio-style streaming does not require an extremely low latency. In fact, it's not uncommon for delays of 20 seconds or more between the encoder and playback for the end user, without the listeners noticing. It isn't a two-way conversation, so latency doesn't matter. Audio quality does.

Common music codecs like MP3 do not tolerate stream corruption all that well. In addition, we don't expect our music to drop out or have glitchy artifacts very often. TCP connections are best in this case, which ensure that all packets will be delivered in-order, and with a reasonable assurance that data corruption didn't happen along the way.

HTTP is a very common protocol that runs over TCP. It's generic enough that makes it well suited for carrying streaming data... just like any other one-way data. In the late 90s, the developers of Nullsoft implemented streaming over a hacked together somewhat-HTTP-compliant server called SHOUTcast. This became very popular, along with Icecast, an open source alternative. Developers found this a lot easier to deal with than the proprietary alternatives at the time, such as RealPlayer. I suspect that's one of the reasons SHOUTcast/Icecast caught on so well. These days there are many servers that are compatible with HTTP.

What are the commonly used methods/protocols to stream audio?

Most common are HTTP, RTMP, and HLS. We discussed HTTP above.

RTMP is a protocol that was developed for Flash, but is now implemented by many servers. RTMP provides more functionality for streaming, such as adaptive bitrate. These features come at the cost of complexity. In addition, browsers don't support RTMP natively. To play RTMP streams in browsers, you either need a Flash-based player or MediaSourceExtensions support where you can demux the audio stream from RTMP in JavaScript. (This is implemented in many off-the-shelf JavaScript players you can buy, but it limits browser compatibility when compared to HTTP.)

HLS (HTTP Live Streaming) isn't really a network protocol, but more of a schema for using HTTP. Instead of having a special streaming HTTP server, HLS works by recording chunks (say for 3 seconds at a time) and uploading them to a normal web server by any conventional means (SFTP for example). In addition to these chunks, there is a playlist file (in standard M3U8 format with some extra info in comments) that points at the latest chunks. The player just downloads these chunks like any other file, and plays them back end-to-end. The advantage of HLS is that you can use any HTTP CDN, and you automatically have a recording of your stream as you stream it. In addition, the client can choose a different bitrate mid-stream to adjust for changing network conditions, similar to RTMP's adaptive bitrate. The biggest disadvantage is the overhead. There is a lot of wasted data in the HTTP requests. Also, like RTMP, HLS is not natively playable by most browsers and must be hacked around with Flash or MediasourceExtensions.

And where can I check how the audio is streamed by internet radio station?

The easiest way is to fire up a tool like Fiddler that intercepts all requests between your browser and the server. You could use your browser development tools, but this isn't necessarily accurate if the site is using Flash. Fiddler will intercept HTTP and HLS requests.

To look at all request data, use a tool like Wireshark. This will show you all traffic sent over the wire. The downside is that decoding HTTPS is difficult, so you might miss some things. (Fortunately most streaming doesn't use HTTPS at the moment.)

Brad
  • 159,648
  • 54
  • 349
  • 530