Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Which protocol should I use for streaming audio (not live)? [closed]

I'm trying to write a Python server that streams one requested mp3 file from start to end. (No live streaming)
I'd like to have the functionality to play that stream with any media player (like VLC) and be able to change playback position.

I've heard a lot about HTTP Streaming, but after reading a few wikipedia articles it seems to me that 'HTTP Streaming' is just an umbrella term for different streaming protocols such as RTSP/RTCP/RTP.

Then I came across SHOUTcast which is a proprietary software (server!) for streaming media using its own protocol. Another existing server program which seems to offer similiar functionality is Icecast.
I'm not really sure on the relationship between SHOUTcast and Icecast, but there seems to be one.

I figured streaming one specific media file couldn't be that different from streaming a continuous stream like a web-radio so I googled the first webradio and downloaded a .pls or .m3u file.
Both basically were textfiles containing a url. So i started wireshark and pointed VLC to that url.
What I saw was essentially HTTP Traffic:

VLC:

GET /schizoid HTTP/1.1

VLC:

Host: <ip>:8000
User-Agent: VLC/2.0.5 LibVLC/2.0.5
Range: bytes=0-
Connection: close
Icy-MetaData: 1

Server responded:

HTTP/1.0 200 OK
Content-Type: audio/mpeg
icy-br:128
ice-audio-info: bitrate=128
icy-br:128
icy-description:PsyTrance 24x7
icy-genre:psytrance
icy-name:Radio Schizoid
icy-pub:1
icy-url:http://schizoid.in:8000/schizoid
Server: Icecast 2.3.2
Cache-Control: no-cache
icy-metaint:16000

Then the server begins sending raw data, which seems to be the mp3 stream.

According to Wikipedia this is the SHOUTcast protocol.
(Im not sure wether this is the same protocol that Icecast uses)

But I figured a closed (not documented) protocol couldn't possibly be the standard for streaming media.
So my Question is what's the best (easiest and best supported) way to integrate streaming (specific mp3 files) into a python server ?
Do I have to manually implement the SHOUTcast protocol or is something like RTP the way to go?
(I don't mind using a third-party library)

like image 987
Ansgar Avatar asked May 24 '13 20:05

Ansgar


People also ask

What is the best protocol to audio stream in?

HLS stands for HTTP Live Streaming, and today it is the most widely used streaming protocol on the internet.

Which communication protocol is used for streaming audio?

Real-time transport protocol (RTP) is one of these streaming protocols, which has been around a long time (its first draft was launched at 1996). RTP is a network protocol for delivering audio and video over IP networks.

Which protocol is used for live streaming?

Adaptive HTTP-Based Streaming Protocols Using adaptive bitrate streaming, HTTP-based protocols deliver the best video quality and viewer experience possible — no matter the connection, software, or device. Some of the most common HTTP-based protocols include MPEG-DASH and Apple's HLS.

Why is UDP used for live streaming?

UDP offers reduced latency over the TCP reliability. In case of time sensitive applications, UDP is faster protocol as it doesn't wait for acknowledgement from the client side and retransmission of lost packet.


1 Answers

The SHOUTcast client protocol is effectively the same as HTTP/1.0. The only relevant difference is the response status line:

ICY 200 OK

Instead of HTTP/1.0, you get ICY. That's really it! From there, it behaves the same. Web browsers, and most HTTP clients ignore this. Android chokes on it, and some browsers, but most are fine. Icecast's client stream behavior is the same as SHOUTcast's, except that it actually returns HTTP/1.0 200 OK for its status line.

Now, you have noticed in those response headers, there are some extra headers with stream information. All but one are just extra information that don't have any impact on the data you're getting back. If you request no metadata, then the server does nothing but take every byte sent to it from the source, and relay it on to each client (with a little server-side buffer as well).

If in your request headers, you specify Icy-MetaData: 1, then the behavior changes slightly. In the response, you will get Icy-MetaInt: 8192 or similar. This means that every 8,192 bytes, there will be a chunk of metadata. Sometimes that chunk is just 0x00 which means that there is no metadata update. Other times there will be a byte like 0x01. If you multiply that value by 16, you know that the next 16 bytes will be ASCII metadata, like StreamTitle: 'My Stream';StreamUrl='';, padded by 0x00. I've described the metadata in more detail in another post, if you are curious.

All of this to say is that the most popular streaming protocol is in fact HTTP, and SHOUTcast/Icecast/many other servers have added a request header where you can get metadata interleaved into the stream. HTTP clients that don't request that metadata will just get a regular MP3 stream, which a browser will think is just some file somewhere. Afterall, the browser doesn't care how you get the data.

Now, what should you be using? Your requirement:

I'm trying to write a Python server that streams one requested mp3 file from start to end. (No live streaming)

HTTP is all you need. In fact, no need to write some server for this. Apache/Nginx/whatever will work fine. Just a simple HTTP server! If you want to serve up files by ID, that's where your Python comes in. Write something that goes and fetches the appropriate resource from disk, based on that ID. I wouldn't bother with RTSP for this... that is way too much overhead for what you need, and you will be hurting client compatibility.

I'd like to have the functionality to play that stream with any media player (like VLC) and be able to change playback position.

For that requirement, just make sure your server supports range requests. The client will take care of the rest.

Summing this all up

  • SHOUTcast/Icecast servers are for "live" radio-like streams where all the clients get the same audio stream at (roughly) the same time
  • HTTP is the most compatible protocol for delivering anything to the client, streaming or not
  • RTSP/RTMP/RTP and all related protocols are not necessary unless you are streaming a long-running or live stream where variable bitrate based on client bandwidth availability is important. (There are other features of these protocols, but this seems to be the deciding factor for choosing them. I recommend reading up on each if you want more info.)
like image 88
Brad Avatar answered Sep 20 '22 12:09

Brad