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
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 >
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? 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. 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 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 >>