[Icecast] Bandwidth Calculations

[Greg Ogonowski]

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
>