Icecast Streaming Media Server

[Anonymous]

Hi all,

I'm trying to come up to speed here quickly...I've read a bit, and have gotter the server running, but need some advice.

I have 3 radio stations that I need to forward to a provider for relay. I only want this connection, no local/outside connections to the encoder machine. Each stream will have its own port.

Encoding is being done on a single machine, containing 3 Orban PC1100 cards; each stations will have 2 streams, 1 Windows Media & 1 aac+, the latter being encoded by Orban's encoding software.

I got interested in icecast because it is able to run multiple streams - however, I read in another post that shoutcast compatibility does not allow this - is that correct? Is there any way around this, i.e. multiple instances (my initial approach was to run shoutcast x3 on the same machine, 1 for each station)?

Any suggestions on the approach are welcome - as I said, I'm trying to come up to speed quickly here. Thanks!

[EDIT: PC in question is a P4 2.8 GHz, 1 GB PC3200, running XP Pro SP2 - in case it matters. ]

[EDIT #2: I changed the thread title to be more relevant, in case anyone else wants to know.]

[karlH]

shoutcast style connections don't allow for mountpoints so they are limited to 1 stream per server. you can still run multiple icecasts on different ports to achieve what you want which means you won't get the fallback facility. I have some work in progress that allows for multiple ports to be defined in icecast that allows for multiple shoutcasts source client to connect at the same time, and fallback handling can occur but that is not in 2.3.1

karl.

[Anonymous]

Is there any particular benefit to running multiple icecast servers vs multiple shoutcast servers?

Also, I realize that it's hard to say about future plans, but is there any ETA at all for what you're talking about in the above post?

Thanks!

[karlH]

Having a biased opinion, I would say running multiple icecasts is better, if only because the context switching will be lower.

The multiple shoutcast source client changes seem to be working out well and isn't as disruptive as initially thought. If you want to try it out then by all means get the latest -kh branch from karl.mediacast1.com and define <shoutcast-mount> within the listen-socket. Note that while you don't need to define the second listen-socket section, a second port is implicitly defined and those 2 ports are used for a single source client, so with the following

<listen-socket>
<port>8000</port>
<shoutcast-mount>/stream1</shoutcast-mount>
</listen-socket>

<listen-socket>
<port>8010</port>
<shoutcast-mount>/stream2</shoutcast-mount>
</listen-socket>

ports 8000 and 8001 used by one sc source client
ports 8010 and 8011 used by another sc source client
listeners can connect on ports 8000 or 8010

karl.

[Anonymous]

Cool! I'll give it a try tomorrow afternoon & see how it goes.

[Anonymous]

Hey - would this be in the 7a testing version? (I'm running Windows)

[karlH]

The multiple sc source client feature has been in for some time, so the latest win32 exe packages have it. As a general rule don't bother with ones in testing unless I say as they tend to be specific builds to highlight certain cases. In this case you should be fine with 7a, when I get my development machine back running I'll reorganize it better.

karl

[Anonymous]

Hmm...I assumed that the testing branch was necessary, being a newer feature, but (if I understand you correctly) simply the current -kh release should be sufficient?

I should be able to have a go at it tomorrow, and I'll post the results when I do.

[karlH]

IIRC that particular version in testing was one with ssl support, so it won't affect whether you use multiple sc source clients or not. win32 uses a completely different build setup.

karl

[Anonymous]

OK, tested the above with the current Win32 KH build - edited my original working XML file, adding the additional listen sockets & shoutcast-mount points and removing the 2nd defined listen sockets (that should be implied, correct?) but I can't connect to the streams.

[Anonymous]

Whoops! OK, I'm an idiot.

It is working, with the implied 2nd port as well - I changed my Orban encoder settings to connect to icecast instead of shoutcast, and changed my .asx "listen" link:

<REF HREF="icyx://192.168.97.92:9932/Q99.aac">

And all is well.

It doesn't really seem to have had any impact on CPU usage, but that's not a biggie - altogether, I'm averaging between 30-35% usage either way I go (3 WME encoders via command line, 3 Opticodec instances, and icecast encoding 3 streams). But - I don't have to launch 3 shoutcast instances this way, which makes life easier.

If there's any further optimization possible for icecast (I'm running an edited version of the basic shoutcast-compat file included with the install) I'd love to hear about it - but so far, so good!

[Anonymous]

Ran into a snag: the stream would not relay through the provider, who expects a shoutcast stream. They do not know how to pick up an icecast stream for relay - any advice?

[karlH]

you are going to be limited when shoutcast is involved as there are no mountpoints in shoutcast (well there is but it's always /)

If you have a shoutcast server wanting to relay an icecast stream then you need to use an alias for / to map to the actual mountpoint. You can have per port aliases if need be.

karl.

[Anonymous]

OK - I assume you mean an alias in the .xml file...can you give me an example of how you would do this?

[karlH]

As taken from the example xml file we ship

<alias source="/" dest="/mystream"/>

you can also add a port= in there, which should work if you need to.

karl.