Today, Nihar Bihani of the Amazon CloudFront team is back again, with another guest post.
-- Jeff;
Today, I’d like to tell you about two different ways we’ve improved our live streaming solution. But before I dive into what’s changing, I want to start by calling out some things that are staying the same. Our live streaming solution still uses the standard HTTP protocol to deliver your live video. The set-up is still simple and straightforward; an Amazon CloudFormation template helps you create your live streaming stack on AWS. You continue to have full control over the live streaming origin server – Adobe’s Flash Media Server running on Amazon EC2. And you still only pay for what you use. You told us you liked these things, so we left them alone. So, then, what’s changing? How is this better?
The first change is that our new solution now supports live streaming to Apple iOS devices by streaming in Apple’s HTTP Live Streaming (HLS) format. Our customers told us that their audience is increasingly using iOS devices to access live content. Apple’s HLS format works by breaking the overall stream into a sequence of small HTTP-based file downloads. With support for HTTP caching already available with CloudFront, what was required is an origin server that can produce your live stream in the Apple HLS format. That’s where Flash Media Server 4.5 comes in. In FMS 4.5, Adobe has added support for streaming on-demand and live content to Apple iOS devices using the HLS format. You only need to encode your live video once, and publish it to FMS’s live packager application on your origin server. Then, your origin server takes care of creating the live content fragments (.f4f and .ts) and the manifest files (.f4m and .m3u8) in real-time, so you can use CloudFront to deliver your live content to both Flash-based and Apple iOS devices from a single source.

While this may seem complex to set-up, we’ve made it super simple for you with the use of a CloudFormation template which asks you for a few basic parameters about your live event to get a live streaming stack set-up on AWS. After the stack is created, CloudFormation hands out all the URLs you’ll need to publish, stream, and manage (using the Adobe FMS Admin Console) your live event:

Our live streaming tutorial that walks you through the steps you’ll need to get this going in no time. Plus, if you are already familiar and comfortable with Adobe’s Flash Media Server, or wish to configure multi-bitrate live streaming, DVR functionality, or other features of FMS 4.5, you already have full access to your live streaming origin server (FMS 4.5 running on Amazon EC2). You can also modify the CloudFormation template to make it easier for you to reproduce your live event with your custom configuration settings.
The second change is that we’ve made it easier for you to deliver your live event to a world-wide audience without the need to scale your origin infrastructure. Our improved live streaming solution uses a feature CloudFront recently announced – lower minimum expiration period for files cached by our HTTP network. With this feature, you can set the expiration period on your frequently updated live manifest files (.f4m, .m3u8, etc.) to a short amount of time, e.g., 2 seconds, by setting the cache control header on your files in the origin. This way, clients do not need to go to the origin EC2 instance directly every few seconds to retrieve the updated manifest files. The good news is that your FMS origin server already sets the cache control header with a low expiration period on these manifest files, so there is no additional work needed on your part. The CloudFormation template is configured to hand out a CloudFront domain name for you to access both the live manifest files and the live video fragments directly from CloudFront.
Adobe’s Flash Media Server 4.5 is now available in all current AWS regions, so you can launch you CloudFormation stack in the region closest to your live event location for best possible performance when uploading your encoded live video to the FMS origin server running on Amazon EC2. And with CloudFront’s global edge location network (now in 28 locations), your viewers can get the best possible performance while viewing your live event.
We hope that our improved live streaming solution helps you offer your audience more choice in accessing your content, including access via multiple mobile platforms. We’d love to hear what types of live event you use this solution for and other cool things you do with full access to your Flash Media Server 4.5 origin server!
For another perspective on this launch, check out the new post by Adobe's Kevin Towes: Announcing Flash Media Server 4.5 on Amazon Web Services.
Finally, we’ll also be hosting a webinar on May 04, 2012 from 10am–11am PDT with speakers from both Amazon CloudFront and Adobe to explain how you can use this solution for your live streaming needs. Please register for this webinar here.
Nihar Bihani
Product Manager - Amazon CloudFront


This is great news and I look forward to testing it out this Sunday for our worship services.
Thanks!
Posted by: John C. Bland II | March 29, 2012 at 09:52 PM
I don't understand the need for $5 licensing fee and $5 monthly recurring fee.
It doesn't align with the AWS pay-per-use model.
We already pay $0.43 per hour for a large FMS instance compared to the usual $0.320.
http://www.adobe.com/products/amazon-web-services/pricing.html
Posted by: pablo | March 30, 2012 at 02:08 AM
Couple of key benefits of this solution in my viewpoint is the improved time to market (or deliver live content) , the business agility and the flexibility.
Live video is niche and when We are enabling a multi-channel ,Global rich media broadcast network with this in a matter of minutes, It is incredible.
Also, Gone would be the days and $$s one have to spend in creating their own origin-edge servers for Live streaming on a large scale.
Posted by: Sankar | March 30, 2012 at 08:48 AM
Only of value if data transfer from EC2/S3 to cloudfront was free. Currently, i reckon only inbound data to cloudfront is free we still end up paying for ec2/s3 outbound.
This would be a killer feature if S3/EC2 outbound only to cloudfront would be totally free. Then the client ends paying for s3storage + cloudfront edge outbound = Huge value and savings.
Posted by: Hareemca | March 30, 2012 at 07:08 PM
Congratulations, it was incredibly easy to setup!
It took about 15 minutes to be up and running from a FME origin. Cloudformation stack took 10 minutes.
Anyone out there knows how to push a Wowza stream fo FMS? Wowza addon pushplugin connects to Amazon FMS on the correct application and streamname but does not start streaming.
Posted by: Alvaro Antelo | April 02, 2012 at 04:01 PM
It would have been great if they upgraded the cloudfront servers from 3.5. to 4.5 and you could just make a cloudfront http streaming distribution.
Posted by: frank | April 04, 2012 at 03:27 PM
Aside from the benefits mentioned by Sankar, another advantage of this new live streaming system is that they can be viewed via iPhone and iPad. Thus, it will make the information-sharing process of web-streaming more mobile and portable.
Posted by: Rose Ector | April 21, 2012 at 11:53 AM
Can someone please confirm:
I'm looking to stream to a large audience of 10,000+ viewers. Will this solution automatically scale to cope with demand?
Do I need to setup additional edge servers or a new cloudformation template?
Thanks.
-
Bob
Posted by: Bob | April 27, 2012 at 05:09 AM
I'd just like to confirm we will be using a 'High-memory double extra large' or 'High-memory quadruple extra large' for our stream.
Any tips for how to prepare for large audiences and auto scaling?
Thanks + keep up the good work.
--
Igor
Posted by: Bob | April 27, 2012 at 05:16 AM
this is all great news :)
now can someone explain simply how we can PULL a stream from another RTMP server such as WOWZA?
Posted by: ben | November 01, 2012 at 04:58 PM