[Icecast] Bandwidth Calculations

Fri Jul 5 10:24:44 UTC 2013

On 07/05/2013 09:26 AM, Scott Winterstein wrote:
> OK if I go with say HE-AAC or Opus, can I still encode as mp3? I am
> using Butt as my source encoding. Can Butt be configured to encode
> using these codecs instead of their codecs its defaulted to?

I'm not sure if BUTT supports Opus yet. If not someone should certainly
add it!
Depending which target operating system you use there are all sorts of
software packages available, including commercial ones like by Greg's
company.

> Still a bit unclear on the method to calculate a 128k stream with
> 6,000 GB available bandwidth over 30 days to give an estimated average
> user connections possible.

The math is really simple, you just need to make sure you don't confuse
bits and bytes.
128kbit/s = 15.625 kbyte/s
we multiply by 1.2 to account for any overhead: 18.75kbyte/s
So each listener consumes 18.75kbyte/s while connected.

maxVolume = 6000GByte = 6144000MByte = 6291456000KByte

maxVolume/bandwidth = 335544320s = 5592405.3min = 93206.76h = 3883.61d =
129.45mo
So you can feed 129.45 months of streaming from 6000GB.
Obviously that also means you can have an average of 129.45 listeners
per month, before you exceed your Volume limit.
Which conversely would mean egress traffic of about 16-17MBit/s 24/7.

How much a station really needs depends alone on how popular they are.
If larger Volume costs extra (it usually doesn't if you rent a whole
server), then starting small and seeing how you fare is probably a good
approach. One thing to note though. This does NOT mean that the station
should never exceed 130 listeners, actually I'd expect it to have spikes
around at least 300-500 listeners before you hit an AVERAGE of 130.

Cheers

Thomas

PS: I've oversimplified, especially on the overhead, but the ballpark
should be close enough.

> On Fri, Jul 5, 2013 at 11:05 AM, Greg Ogonowski <greg at indexcom.com> wrote:
>> Scott-
>> You are describing UDP multicast in your example. Icecast uses TCP and the ICY protocol, and the streams are all unicast. Every user consumes more bandwidth from the server. You might want to consider the use of a more efficient audio codec such as HE-AAC or Opus. That will reduce your bandwidth requirements.
>>
>> Greg
>> Orban
>>
>>
>>
>> On Jul 5, 2013, at 1:29, Scott Winterstein <0turn1 at gmail.com> wrote:
>>
>>> On 07/04/2013 07:49 PM, Scott Winterstein wrote:
>>>> How do I calculate bandwidth needs and processor, memory needs to find
>>>> possible user configurations of say 6GB Bandwidth a month 2.3 dual
>>>> proc 4gig memory for 128k stream feed?
>>> Fri, Jul 5, 2013 at 7:54 AM, Thomas B. Rücker answered:
>>>> With Icecast the basic rule is:
>>>> - you run out of bandwidth before anything else
>>>> The rest is fairly simple bandwidth math.
>>>> Just keep in mind:
>>>> 128kbit/s = 16kbytes/s
>>>> Also take into account TCP/IP/Ethernet overhead. I don't have a hard
>>>> number at hand, but I'd just multiply stream bandwidth by 1.1 or 1.2.
>>>>
>>>> I'm a bit surprised at the low monthly data volume of 6GB you state, as
>>>> that is unusually low for a hosting arrangement nowadays and translates
>>>> to 5500 broadcasting minutes (about 0.13 average listeners 24/7/30).
>>>>
>>>> Or did you mean something else than hosting an Icecast server?
>>> I mean 6,000GB sorry, but while your calculation answers the question,
>>> I dont see the math to it. I need a basic calculation that I can
>>> figure generally for different configs. like how do you get
>>> broadcasting minutes figure?
>>>
>>> Maybe you can answer this. I have been mucking around with encoding
>>> since 1999, and we were broadcasting video streams. I do not remember
>>> figuring each connection to the broadcast into bandwidth needs, as its
>>> a broadcasted stream, a single file played in a single instance, the
>>> only requirements were that the streams bandwidth and the users
>>> bandwidth were important to the playback quality, 128k video stream
>>> required a user to have that at minimum to be able to watch it
>>> correctly, like you said 128 + "overhead". Why now do you figure in
>>> also each connection? As I see it the server is just serving a single
>>> 128k up stream and taking up 128k up stream bandwidth, the user end
>>> connection is a mute point as they are downloading it using their
>>> bandwidth. Seems to me hosting services are double dipping charging
>>> the server end the up and down of the single 128k stream to make sense
>>> of the per user, or to me its not a true broadcast, its a truely
>>> separate instance of the stream to any connection. Maybe shed some
>>> light on this if possible.
>>>
>>> Mit freundlichen Grüßen
>>> Scott Winterstein
>>>
>>> EMAIL: 0turn1 at gmail.com
>>> PHONE: +49 0151 279 11519 Calls from USA +49 151 279 11519
>>> WEBSITE: http://www.scottsdesk.net
>>> FACEBOOK: http://www.facebook.com/scottsdesk
>>> DEVELOPMENT: http://www.dlradio.org
>>> _______________________________________________
>>> Icecast mailing list
>>> Icecast at xiph.org
>>> http://lists.xiph.org/mailman/listinfo/icecast
>>>
> _______________________________________________
> Icecast mailing list
> Icecast at xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast
>