Icecast Streaming Media Server

[robertut]

Hi!

We serve with one instance of IceCast a lot of streams to thousands of users, several streams have the same content but in different formats. We stream both in AAC+ and MP3. We used to use ShoutCast before, by running a separate instance of it for each stream, but IceCast is way better: less memory and cpu usage.

We would like to encourage people to listen to AAC+, because it gives much better quality than MP3.

We create an m3u playlist files for each content channel, containing first the AAC+ stream, and then the MP3 stream. We rely on the player client, which, if it's not prepared to decode AAC+, will jump to the next track which is the MP3 stream.

Back when we were using Shoutcast, things went well with most players, including Windows Media Player. Unfortunately WMP can't decode AAC+ unless the Orban AAC Codec is installed. Without this, WMP just threw and error message box saying that it can't play the stream, and by clicking OK, it jumped to the next item in the list, which was the MP3 stream.

Since we moved to Icecast, using the same M3U strategy, WMP keeps hanging there, saying "Connecting..." forever, witout doing anything. It doesnt throw any error message, and it doesn't jump to the next track either.

Unfortunately we have thousands of users which are able to listen us only with WMP - this is true especially in corporate environments, where users have no administrative privileges, thus can't install any other players, and WMP, the only player they have, is not able to play the streamlist, as it hangs at the first item saying "Connecting..." forever.

I know this must be a WMP problem, as M$ has a strange way of dealing with things, but still, the problem appears only after installing IceCast. With Shoutcast and the others, it behaves as I described above - the user gets an error box, and after that jumps to the next. With Icecast streams, it doesn't.

It would be nice to let the user know that there is a situation on their side. I guess that Icecast uses different headers when sending the AAC+ stream, which WMP just can't do anything... but what does Shoutcast send then, that WMP gets aware that the stream can't be played?

Is there any solution to this? Is there any alternative anyone can recommend, considering all the above?

Thanks in advance.

[karlH]

Obviously we cannot comment on the state of wmp, but if you experience different behavior from shoutcast then I can only think of 2 differences that could trigger the difference. An m3u layout difference, if that is the case then placing a custom m3u in webroot should suffice. The only other difference I can think of is the large initial burst that shoutcast sends, it may cause wmp to faint on that stream, the burst on icecast is not as excessive but you can increase the burst-size to try that out.

Obviously we recommend using ogg vorbis

karl.

[robertut]

Icecast serves the streams on port 8080, while Shoutcast used to serve each stream on a different port between 8000 and 9000. In both cases, the custom m3u is being served by an apache server, on port 80. Apache's config (mime types and so) didn't change since the Shoutcast times.

Currently this is the limits section of Icecast:

[karlH]

hmm, if the m3u is the same then it won't be that. I can't see there being a port issue. Looks like you have a 128k burst from a 1Meg queue, I don't know what shoutcast uses for a burst but ou are probably talking of around 1Meg, now if you try that then don't forget to increase the queue size (eg 1.5Meg). Note that you can set burst and queue sizes per mount.

karl.

[robertut]

[karlH]

You don't want them to be the same, the burst effectively puts the listener behind, if the listener has trouble taking the burst then the tolerance before dropping off the end of the queue will be small. The queue will shrink if it's not required.

karl.

[robertut]

I changed to this, no success.

[karlH]

Other than trying a larger burst, I'm not sure what else to suggest. You could check the behavior on wmp against an existing shoutcast stream, to make sure it isn't a "fix" that has been supplied by MS but without more detail on the connection content it's hard to say. We don't fiddle with the AAC data and we don't have any wmp specifics so there should be no difference. I don't know whether wmp has issues with VBR for AAC but is also another thing to check.

karl.

[robertut]

We don't use VBR AAC. We use the same encoder source client we used before with Shoutcast, it's OddcastV3 (now edcast).

I'll do some more investigation...