关才网络收音机使用的流媒体传输协议

发布于 2010-02-24 15:08:39 浏览：14827 订阅该版

9 个回答

bernard 2010-02-24

这家伙很懒，什么也没写！

inkfish 2010-02-24

这家伙很懒，什么也没写！

bernard 2010-02-24

这家伙很懒，什么也没写！

shoutcast协议：
**Intro**
Not much is available about how our streaming technology works, more specifically MP3 streaming. When you get right down to it, it is actually very simple to understand. You will especially understand it if you know anything about HTTP's Protocol, which is simply a communication method for a client to a server. This article is mainly geared for those hard core into this stuff or those who want to develop applications similar to those utilized at this site.

**Tools used**
The tools used for streaming are quite simple:
[list]
     Source (usually a dsp in a player)
    [/*:m] Server (dispatches the source's mp3 stream to the client)
    [/*:m] Client (is used to listen to the audio coming down from the server[/*:m][/list:u]

**Source to Server**
In order for a server to allow connections from a client, it needs a source. When a source connection is made then the server will pass the data along to the clients when they connect.

The dialog goes something like this (I will use SHOUTcast as the example)

1. The source makes a connection to the service port (shoutcast's is the port +1)
2. The source then sends the password like so password

3. If the password is correct, the server will reply with OK2
icy-caps:11

, this basically informs the source that the server has authorized the dsp to be the source and it is ready for data. If the password is incorrect, the server sends invalid password
.
4. If the source receives the OK2, it then begins sending information about the stream to the server. Usually in this form:

```

icy-name:Unnamed Server

icy-genre:Unknown Genre

icy-pub:1

icy-br:56

icy-url:http://www.shoutcast.com

icy-irc:%23shoutcast

icy-icq:0

icy-aim:N%2FA

```

Then The source will begin sending the mp3 encoded stream
[list]
 icy-name is the name of the stations[/*:m]
 icy-genre is the genre that the station resides in[/*:m]
 icy-pub is basically a switch to either allow the server to publish itself in the directory or not (1 meaning yes and 0 meaning no)[/*:m]
 icy-br is the bitrate of the stream[/*:m]
 icy-url is the homepage for the stream[/*:m]
 icy-irc is yp shoutcast specific (used for contact information)[/*:m]
 icy-icq is yp shoutcast specific (used for contact information)[/*:m]
 icy-aim is yp shoutcast specific (used for contact information)[/*:m][/list:u]

You can also pass this optional data:

```

content-type: mime/type

icy-reset: 1

icy-prebuffer: ??

```

content-type is the data type to expect from this stream. (HTTP spec header)
 icy-reset tells the server whether it should clear out the buffer. (necessary for NSV/NSA streams.
 icy-prebuffer, we aren't quite certain what this is for, how to use it or even whether it works, but it exists.

The optional params are not necessarily passed to the client, content-type is of course but as for the others it is not clear.

This is just a simple walk through of how the source communicates with the server. No other information is passed on this port as far as I am aware.

Title streaming from source to server
This is a simple one, the server receives the title of the song and the URL of the page simply by having the source make the URL call

```

http://www.host.com:portnumber/admin.cgi?pass=Server%20Password&mode=updinfo&song=Song%20Goes%20here&url=http://someurl.com

```

When this gets called by the source or a browser even, the title of the song changes in the clients which support shoutcast style title streaming. This communication always happens on the public port (by default 8000) never on the service port as it is used for strictly sending the stream to the server.

You also must make sure that when you make your HTTP calls that it comes from a browser or program that specifies the User-Agent: header as Mozilla.

**Client to Server**
The Client to Server communication is handle in a similar fashion to the way that a browser communicates with a webpage server. This is known as the HTTP protocol. However SHOUTcast and icecast do not handle in exactly the same manner, the headers are different. I have yet to pin point exactly what is so different. I think it may have something to do with the notification error, as it is HTTP/1.0 200 OK on all web servers using HTTP, this may confuse some clients and causes the headers to not exist.
1. The client connects to the server and sends information about itself, if it can handle title streaming it sends and extra field like so:

```

icy-metadata:1

```

In addition to the normal headers sent. This tag signifies that the client has the ability to stream the title streaming tags from the stream, therefore the server will send the extra title information, if this were not possible, some clients would hiccup when the title information is sent

2. The server then responds with

```

ICY 200 OK
 (signifying that the server was successful)

icy-notice1:<BR>This stream requires <a href="http://www.winamp.com/">Winamp</a><BR> (redundant notice)

icy-notice2:SHOUTcast Distributed Network Audio Server/posix v1.x.x<BR> (tells the client what server it is and version)SHOUTcast Specific

icy-name:Unnamed Server
 (Name of the server)

icy-genre:Unknown Genre
 (what genre the server falls under)

icy-url:http://www.shoutcast.com
 (homepage for the server)

Content-Type:audio/mpeg
 (Content type of the stream to follow)

icy-pub:1
 (whether the server is public or not)

icy-br:56
 (bitrate of the server)

icy-metaint:8192
 (if icy-metadata:1 was signified this was shown I will discuss this further later)

(end of header)

```

3. At this point the server begins sending the audio data.

SHOUTcast Meta Title Streaming
Earlier we discussed how the server gets the title of the song from the source, but we didn't quite get into how the client gets the title of the song.

When the client signifies that it is title streaming compatible, the shoutcast server adds an extra header tag set like so

```

icy-metaint:8192

```

this tells the client exactly how many bytes of data to read out of the stream before it can expect the beginning of the Meta-Data (which is where the title is stored) It also always starts counting at the beginning of the stream (not the header)
After this the client then reads 1 byte, this byte tells the client how large the Meta-Data Tag is divided by 16, so if the byte was 4 then the client would know that the meta-data tag was 64 bytes long. But, you ask, not all titles are going to equal 64 bytes or 48 bytes etc...? Well the simple answer is that SHOUTcast places blanks or "�" in the unused space until it equals the length, after that is read, then it is back to the mpeg data to start the process all over again.

Pretty simple huh?

In Closing
I am sure that this technology will change, and I will try my best to keep this article up to the specs as I know them. If you find anything incorrect in this article, or any oversights, then please email me

Feel free to leave a comment if you feel that I have missed something. Do not reply with questions. Questions should go in the Audio Streaming forum. Questions will be split from this thread and moved to appropriate forums.