For a very long time, the only good streaming tool for command line systems was shout. Shout had a lot of issues, it was a quick and dirty hack, it was buggy, it was sending data too fast or too slow, and it was just something no one wanted to fix. So we rewrote it from scratch, and the next generation streamer, 'ices', is here. 'ices' is short for 'icesource', a source for the icecast server. 'ices' should be pronounced 'isis' like the egyptian godess of fertility. For more information about icecast, I suggest you check out the icecast webpage at http://www.icecast.org/.
ices, armed with a list of mp3 files, sends a continuous stream of mp3 data to an icecast server. The server is then responsible for accepting client connections and feeding the mp3 stream to them. But the stream originates in the streamer, 'ices'. The terms 'encoder', 'streamer' and 'source' are used equivalently throughout this document, and throughout all the documentation in the streaming system.
The cue file holds information on the file that ices is currently feeding
to the server. This is neat for you people out there who like running scripts.
I myself, use the cue file in a tcl script, running from a eggdrop bot, on irc.
That way I can ask the bot what song is currently playing, how long it is, how
much of it has been played, and get information about the next songs on the
playlist.
The file currently has the following lines, (in this order).
If compiled with support for reencoding using liblame, and you supply
the -R command line option or set the Stream/Reencode to 1 in the
XML config file, then ices will start reencoding your files on the fly
to the bitrate you specified with the -b option or the Stream/Bitrate
tag.
If you are reencoding and ices was compiled with vorbis support, you
may also reencode Ogg Vorbis files as MP3 on the fly. This gives you
the opportunity to convert your source files to Ogg Vorbis at your
convenience while still supporting as many listeners as possible.
The sample rate, number of channels, etc, will be chosen on the fly by
lame itself, unless you specify something using the -H and -N options.
If you want to change it, I suggest you add support for this to ices
and mail me a patch.
I think you should be fine with whatever lame chooses though.
Also, please make sure that your files are ok before you start
reencoding them with ices. This is because the mpglib part of lame
(what does the decoding) is rather unstable and will call exit(0) when
errors are encountered.
This will make ices exit, which is kinda bad :)
You can feed the same playlist simultaneously to different mountpoints, by specifying multiple Stream sections in the config file or passing multiple -moptions on the command line. This is especially useful in conjunction with reencoding because you can stream the same music at a high bitrate for broadband listeners and simultaneously at a low bitrate for POTS listeners.
About 96% of all emails I got about shout was people asking me to add small
changes to shout playlist handling to suit their specific needs.
This is course is not how I want to spend my life :)
Shout had a feature to call an external program with a system() call, before
each song, and that could possibly modify the playlist.
This was rather ugly, but did the trick.
In ices, we take this a step further and include scripting support inside the
program. You can write your own playlist handler in perl or python, whatever
you prefer.
Your script module has to define at least a function named
ices_get_next, which should return a path to a file or FIFO
containing MP3 data.
In addition you may define the functions ices_init and
ices_shutdown which will be called by ices once before asking
for the first song and before shutting down, respectively.
You may also define ices_get_lineno, which specifies the line
number of the current track in the cue file. If you don't use the cue
file it is safe to omit this function.
Finally you can define ices_get_metadata to return a string
you want to use for title streaming. Ices will call this function once
per track after calling ices_get_next. If this function is
not defined or returns null, ices will use whatever it can get out of
the file itself, either tags or the file name.
I suggest you take a look in the distributed module files and just expand on
that.
ices can do everything shout could do, and more. It can be configured through hard coded defaults, a configfile, and command line options. The configfile is in XML, but don't get scared and run off. Just edit the distributed configfile and change the values you need. The command line options should be familiar to old shout users, although some options have been renamed.
Options:
Here's a sample configuration file. It's the same as the ices.conf.dist that is included in the ices distribution. You can specify multiple stream sections with different mountpoints, names, and reencoding options.
<?xml version="1.0"?> <ices:Configuration xmlns:ices="http://www.icecast.org/projects/ices"> <ices:Playlist> <ices:File>apan.txt</ices:File> <ices:Randomize>1</ices:Randomize> <ices:Type>builtin</ices:Type> <ices:Module>ices</ices:Module> </ices:Playlist> <ices:Server> <ices:Hostname>localhost</ices:Hostname> <ices:Port>8000</ices:Port> <ices:Password>letmein</ices:Password> <ices:Protocol>xaudiocast</ices:Protocol> </ices:Server> <ices:Execution> <ices:Background>0</ices:Background> <ices:Verbose>1</ices:Verbose> <ices:Base_Directory>/tmp</ices:Base_Directory> </ices:Execution> <ices:Stream> <ices:Name>Cool ices default name from XML</ices:Name> <ices:Genre>Cool ices genre from XML</ices:Genre> <ices:Description>Cool ices description from XML</ices:Description> <ices:URL>Cool ices URL from XML</ices:URL> <ices:Bitrate>128</ices:Bitrate> <ices:Public>1</ices:Public> <ices:Reencode>0</ices:Reencode> <ices:Samplerate>-1</ices:Samplerate> <ices:Channels>-1</ices:Channels> </ices:Stream> </ices:Configuration>
This describes all the different options in ices.
ices is licensed under the Gnu General Public License, and for more info about that I suggest you read the file named COPYING.
If you want to write your own streaming software, or perhaps a nice streaming mp3 client, go to developer.icecast.org.
This document is written by Alexander Haväng [eel@icecast.org].
Last modified: Sat Jun 23 18:44:50 EDT 2001