Please Help Design Our Sever(s)? - Live Video Streaming - Project In Planning - Knowledgebase

Portal Home > Knowledgebase > Articles Database > Please Help Design Our Sever(s)? - Live Video Streaming - Project In Planning

Please Help Design Our Sever(s)? - Live Video Streaming - Project In Planning

Posted by nekon, 01-11-2010, 03:54 PM
Hello, long time lurker, and newly registered member. I'm currently in the planning stages of a big project. I've been trying to research streaming server builds and related info but I'm starting to get a headache. I'm trying to figure out a budget for this project I'm working on. The site focus is on live adult video chat (streaming live video). The problems I'm having and figuring out which steps would best suit out needs. I'm a hardware guy, and I think it's best to focus of performance and scalability. In the back of my mind I keep getting this nagging feeling I should be speaking with a software engineer first. I have collected bits of information but have no real experience with any of it to fill in the blanks. I'm posting this here because I've seen what the WHT community is capable of. Thanks in advance for any time you choose to contribute to this thread. Bandwidth This is one of the hardest aspects of our project to estimate. I'd like to broadcast the stream in DV spec 720x480 @ 15FPS with audio at 32kbps. The issue here is that would require roughly 2140kbps using my math. Using the chart at Adobe linked below they estimate a stream in D1 spec 720x486 and 32kbps audio at 800kpbs. http://www.adobe.com/devnet/flashmed...able1_live.jpg As you can tell we have more research to do in this department. Honestly I don't know how current industry leaders advertise HD content.. But that's for another discussion on another forum. As a point of reference current industry standards are very low. We were only able to utilize .46% of a GigE port with 10 live streams onscreen. Server(s) Like I said early on, I'm a hardware guy. In my mind the ideal situation is to lay out the hardware requirements to provide a superior stream first. Then afterward allow the software engineer to fill in the blanks and make it all work well. I strongly feel the software design should be dictated by the hardware. We plan on utilizing either Wowza or Red5 as our streaming solution and Flash Media Live Encoding 3 as our encoder. I have no idea if we'll require one or two boxes or if we can get awau with a single dedicated server. Maybe it'll be more like a SQL/Streaming box and a Web server/Encoding box? I don't know if each component will require it's own box or if there is an ideal way to combine them and cut prices. My scope goes as far is which components are more demanding and what they'll require to run individually. * Please note, we are only starting out now. I'd really like to see how extreme things can get for our application but at this point we need to keep initial prices and overhead down. Host When it comes to choosing a host we have very strict requirements. To begin we'll need a host who is rich media streaming friendly/capable. We'll need a host who can scale with our project as it grows in popularity. As with any business need to start small and efficiently to keep initial prices down. In turn, we need to focus on where we plan to be in the future. I'm thinking 100% SLA by either way of hardware redundancy or some host solution (non-synthetic), unmetered/dedicated ports, and ideally a CDN solution in-house or some way to provide high performance rich media streaming on a world-wide level. CDN As with most websites the world will be our potential customer base. The issue here is the prices associated with such a resource. We're currently researching if a CDN will be necessary at a later stage.
Posted by nekon, 01-12-2010, 09:16 PM
Is it that I posted in the wrong forum or what I'm asking is very specific? I'm don't think any one person would have all the answers I'm looking for, but I'd appreciate any contribution. A simple opinion on the matter or even a push in the right direction .
Posted by alanzkorner, 01-12-2010, 10:47 PM
Hi NEkon, I have a test server on which I runs Red5 server ..It s not a high end one but a Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz , and 4 GB RAM . What I have observered is this that the load becomes in 2 -4 Range while Red5 server is ON along with few video chats. Higher the server config lesser the load be . Streaming quality is and professional look is good with Red5 .But Still do good research on this .. You may refer to boonex.com . They provide An interface for video and chat e.t.c integration .. it is a License per domain basis .. But good for a start ..
Posted by nekon, 01-14-2010, 12:45 AM
I've been testing with Red5 as well, it seems to get the job done. My only concern would be security if we go that route. I'll have to keep tweaking it, I'm not seeing the picture quality we're looking for. I'm reading really good things about Wowza, I think I'll try that this weekend. Thanks for the tip on Boonex, with the right modules that might get the job done for less. We were/are planning on having software developed from the ground up.
Posted by luki, 01-14-2010, 02:18 AM
This is an educated guess, so don't take it with a grain of salt. 1) I don't know where your 2140kbps is coming from. If you stream at 800kbps per stream, you need 8 Mbps to stream to 10 users, 80 Mbps to stream to 100 users. Simple. So that would be 8% of a 100 Mbit or 0.8% of a Gbit connection (for 10 users). 2) Transcoding is CPU intensive, streaming is not. Since you are streaming live content, your task will not be disk I/O heavy, but additional RAM may be useful to buffer data for various stream connections. 3) If you are starting out, have one SQL/web server and one transcoding/streaming server. I don't think it makes sense chasing the bits from one box to another (SQL<->web and transcode<->stream). In the future you may want to separate SQL and web, and even later transcoding and streaming, perhaps even have multiple streaming servers. By the looks of it, bandwidth will be your biggest expense so try to get a good deal on it. CPU cycles and memory are, relatively speaking, in lower demand.