Questions about # of concurrent users and how Amazon measures bandwidth use
Hope this post isn't too long for a first post -- I have a ton of questions but am pretty excited about the prospects of starting to use Wowza.
Currently my site hosts H264-encoded MP4 files which people watch using JW Media Player (via progressive download). The files are hosted on Amazon S3. I'm investigating switching to a true-streaming method of delivering content using EC2+Wowza, but I'm trying to understand how bandwidth utilization is measured and whether or not we can reasonably expect Wowza to be a good solution for us.
Right now when a user wants to watch a video, the entire video (most are between 50 and 150mb) will load. Though they can scrub "ahead" on the timeline, they can only do this based on what they've downloaded, and can't click to a point that hasn't been downloaded yet. For our users, who often watch a video multiple times, this is a bit of an inefficiency in our downloading as it requires multiple full downloads from Amazon S3, and it also presents a challenge to users who have slower connections and can't download full videos quickly.
In making the switch to EC2+Wowza+true streaming, I'd like to figure out how much data is actually downloaded (and how much EC2 will charge us for) when a user begins streaming a video. For example, if a user clicks the "10min" mark on the timeline (for example, in a 45minute video) and it begins playing, will it download just the content that the user watches, starting at minute 10 and ending whenever they close the player, or will it download the entire video?
Additionally, are there any specific ways that H264 files need to be encoded to be supported? I had been using Mediacoder as a frontend to Mencoder to transcode our files into H264 (currently H264+HE-AAC though we'd like to use HE-AACv2 in the future), but we haven't been including hint tracks -- I can't tell if this is a necessity or not.
Sorry for the beginner questions, but I'm really excited about the possibility of running Wowza as a better solution for video hosting for our site. Are there any reasonable benchmarks I can look at as well, in terms of # users per instance, and what sort of instances are recommended? Our streams range from about 100kb/s (60+48) to 250kb/s (202+48) and I'd like to figure out how many concurrent connections can realistically be served on the various instances.
Last edited by EntityDC; 07-29-2008 at 09:29 AM.
With streaming only what is being watch is streamed to Flash. So if you seek to a location 45 minutes into the video the current stream location is dropped and the stream is restarted from the 45 minute mark. The charge from EC2 will only be for the actual video delivered to the Flash player. So you will only be charged for what is being watched.
Wowza Pro does not require hint tracks. We just need standard Quicktime formatted H.264/AAC-HE movie files. So you should be all set.
When you get ready to try EC2 take a look at this article.
It discusses a new feature of Amazon EC2 that you can leverage for storing your videos to deliver through Wowza Pro on Amazon EC2.
Thanks for the quick response charlie.
Do you guys have estimates for # of concurrent connections per EC2 instance, or any sort of calculation I can do to estimate it on my own?
I would base it on total bandwidth. We have found you can get about 150Mbps - 200Mbps if network throughput out of a single instance. So it is simple math. For example you can do about 300-400 simultaneous 512Kbps streams with a single EC2 instance.
This is for a small instance. I am not sure what you will get out of a large or xlarge instance.
I've found that network throughput is broadly the same for different instance types. I'd suggest the most cost effective way of scaling is multiple small instances
On paper that is true that more small instances seem to make more economical sense than fewer large or xlarge instance. In reality we have found that the available bandwidth to a small instance can very dramatically base on what is going on with other small instances sharing the same hardware/network resources. We have found that the large and xlarge instance provide much more consistent bandwidth and cpu resources. So it is left as an exercise to reader to determine which is best for their application.