Best process for building a website displaying multiple live video streams?
May 23, 2011 6:45 AM Subscribe
Best process for building a website displaying multiple live video streams?
I'm researching this idea on behalf of someone else - the viability of the business model isn't a concern of mine, I'm only interested in the hardware and software that would be required.
The idea is: A website that displays live video streaming from businesses (subscribers) who pay to be included on the site. All streams would be live 5 hours per day (the same start and stop times for all). Each business would have a designated page, displaying text content along with the video. The website owner would be responsible for the on-site cam installation and configuration. The website owner would need to simply copy and paste some embed code into a template, enabling the streaming video.
The site would be built with Expression Engine as the CMS, using the Membrr module to handle subscriptions.
When a new subscriber signs-up, the website owner would need to:
1. Visit the business location, install and configure the cam.
2. Log in to the website, register the business and create a new business page (for the video and text content) from a template.
It's essentially only the cam, server and software configuration I need to understand. I'm guessing that handling bandwidth is the big issue, considering that within a best case scenario, a few hundred subscribers would all be streaming at the same time.
What options exist that would enable all this, in a relatively simple way?
I'm researching this idea on behalf of someone else - the viability of the business model isn't a concern of mine, I'm only interested in the hardware and software that would be required.
The idea is: A website that displays live video streaming from businesses (subscribers) who pay to be included on the site. All streams would be live 5 hours per day (the same start and stop times for all). Each business would have a designated page, displaying text content along with the video. The website owner would be responsible for the on-site cam installation and configuration. The website owner would need to simply copy and paste some embed code into a template, enabling the streaming video.
The site would be built with Expression Engine as the CMS, using the Membrr module to handle subscriptions.
When a new subscriber signs-up, the website owner would need to:
1. Visit the business location, install and configure the cam.
2. Log in to the website, register the business and create a new business page (for the video and text content) from a template.
It's essentially only the cam, server and software configuration I need to understand. I'm guessing that handling bandwidth is the big issue, considering that within a best case scenario, a few hundred subscribers would all be streaming at the same time.
What options exist that would enable all this, in a relatively simple way?
So if you have any concerns about bandwidth I'd probably go with something on Amazon, like a pre-configured Wowza instance. You're probably going to have to do this over rtmp using a flash player, something like Flowplayer gives you something to use that would be pretty easy. There may be pre-built video players for EE as well.
The one part I don't really know much about is the piece that would need to be installed at the business site and how it would upload video.
posted by bitdamaged at 8:20 AM on May 23, 2011
The one part I don't really know much about is the piece that would need to be installed at the business site and how it would upload video.
posted by bitdamaged at 8:20 AM on May 23, 2011
Apple's solution is proprietary, isn't really supported outside of Safari, and is frankly a bit of a kludge.
This just isn't true. HLS is an ietf standard and its getting wide support as the defacto standard for live streaming on a ton of embedded devices (mobile, connected TVs and boxes such as Roku - we built the UFC's channel on their using HLS). Its a bit of a kludge, but its a popular one considering even MS has their own (really) proprietary, minimally supported version that's pretty much the same thing.
Flash is still probably a better solution for this situation however.
posted by bitdamaged at 8:26 AM on May 23, 2011
This just isn't true. HLS is an ietf standard and its getting wide support as the defacto standard for live streaming on a ton of embedded devices (mobile, connected TVs and boxes such as Roku - we built the UFC's channel on their using HLS). Its a bit of a kludge, but its a popular one considering even MS has their own (really) proprietary, minimally supported version that's pretty much the same thing.
Flash is still probably a better solution for this situation however.
posted by bitdamaged at 8:26 AM on May 23, 2011
Oh, yeah. Our source material is 720p60. We cut that down to 15FPS, and cut the audio down to 22kHz sampling for streaming (this makes our video engineers cry). You can make little cuts all over the place to cut down on bandwidth. If you're severely restricted on bandwidth, you're going to need to cut framerate and resolution to get an acceptable-looking video.
I like the look of those preconfigured Wowza EC2 instances. That's gonna be a bit cheaper than UStream's option, and way cheaper than self-hosting. Be warned that streaming video does burn through bandwidth very quickly. If you want a decent-quality 500kbps stream, with an additional 64kbps for audio, that's a bit more than 250MB per hour per stream. Probably closer to 350 once you add in overhead.
posted by schmod at 8:28 AM on May 23, 2011
I like the look of those preconfigured Wowza EC2 instances. That's gonna be a bit cheaper than UStream's option, and way cheaper than self-hosting. Be warned that streaming video does burn through bandwidth very quickly. If you want a decent-quality 500kbps stream, with an additional 64kbps for audio, that's a bit more than 250MB per hour per stream. Probably closer to 350 once you add in overhead.
posted by schmod at 8:28 AM on May 23, 2011
This just isn't true. HLS is an ietf standard and its getting wide support as the defacto standard for live streaming on a ton of embedded devices (mobile, connected TVs and boxes such as Roku - we built the UFC's channel on their using HLS). Its a bit of a kludge, but its a popular one considering even MS has their own (really) proprietary, minimally supported version that's pretty much the same thing.
Let me rephrase that. Effectively proprietary. Apple pulled the standard out of thin air, opened the spec, asked the ITEF to adopt it, and proclaimed it as a "standard." It has not actually been adopted by the ITEF, and the number of non-apple devices actually supporting the standard is quite small. For instance, the vast majority of Android devices still don't support it, and as far as I know, neither do Chrome, IE, or Safari.
Other vendors reportedly had a hell of a time creating their own implementations, given the generally kludginess of the standard itself. It's still not entirely clear why Apple chose to create their own standard instead of implementing a non-flash-based RTMP client in WebKit. Flash is closed-source, but RTMP is every bit as open as Apple's weird HTTP Streaming protocol is. Frankly, it's impressive that HTTP live streaming works at all.
HTTP live streaming is a "standard" much in the same way that JPEG2000 is.
posted by schmod at 9:02 AM on May 23, 2011
Let me rephrase that. Effectively proprietary. Apple pulled the standard out of thin air, opened the spec, asked the ITEF to adopt it, and proclaimed it as a "standard." It has not actually been adopted by the ITEF, and the number of non-apple devices actually supporting the standard is quite small. For instance, the vast majority of Android devices still don't support it, and as far as I know, neither do Chrome, IE, or Safari.
Other vendors reportedly had a hell of a time creating their own implementations, given the generally kludginess of the standard itself. It's still not entirely clear why Apple chose to create their own standard instead of implementing a non-flash-based RTMP client in WebKit. Flash is closed-source, but RTMP is every bit as open as Apple's weird HTTP Streaming protocol is. Frankly, it's impressive that HTTP live streaming works at all.
HTTP live streaming is a "standard" much in the same way that JPEG2000 is.
posted by schmod at 9:02 AM on May 23, 2011
« Older please help balance & broaden my veggie teen's... | ID for evolution-themed '80s board game Newer »
This thread is closed to new comments.
On the cam side, you'll want to be using Flash Live Media Encoder. If you're doing HD, you'll need a fairly powerful machine and lots of bandwidth to run it.
On the server side, you'll probably want to be using one of Adobe's server products, or some other sort of RTMP streaming solution. Wowza is a popular, and somewhat more flexible alternative. I guess you might want to do this in the cloud, but cloud hosting isn't really my area of expertise...
On the client side, you'll probably want to use JW Player, which is fantastic for its simplicity and extensibility, and has wonderful documentation.
Adding iPhone (or non-flash) compatibility is actually quite difficult for live content. Although HTML5 Video is (sort of, but not really) standardized for static content, Flash (RTMP) and Apple's HTTP Live Streaming are really the only two names in the game. Apple's solution is proprietary, isn't really supported outside of Safari, and is frankly a bit of a kludge.
If you're self-hosting, you'd be surprised at how far you can squeeze your bandwidth down if you're willing to sacrifice quality. We primarily stream at 320x240, 100kbps (plus 24kbps for audio) using the VP6 codec. The quality is total crap, but still watchable, given that the quality of our source material is very high, and doesn't show a lot of movement. We use VP6 here, because H264 doesn't do well at such low bandwidth settings. Once you get into higher resolutions and 300k+ bitrates, H264 becomes clearly superior, especially for our content, which generally has very low motion. It sucks, but if you've got limited resources, it's indeed possible to ration those bits.
Is this too complicated? UStream sells a cloud-based turnkey service that does all this for you, and holds your hand along the way. It's not cheap, but might start looking attractive once you price out the development and operational costs for the rest of your business model. There are a bunch of other CDNs who do similar hosting packages, but UStream's Watershed is definitely the most complete turnkey solution that I've worked with.
posted by schmod at 8:20 AM on May 23, 2011