http Origin using Amazon CloudFront

Wowza Streaming Engine
1

Hi there … I’ve waited for this feature for a while. I’m wondering if you have any agreement with AWS for caching live streaming using a CloudFront CDN and Wowza instance as origin.

As http traffic, caching should work just setting it up as http download and using wowza as origing, but Cloudfront has specific ways of setting their CDN when you’ll do live streaming using Adobe Flash or IIS7 smooth streaming. They say it’s an improved pre-configuration they have created for better performance.

I’m wondering if something like this exists for Wowza

Thansk

2

We do not yet support Wowza on Cloudfront. However, we are in discussions with Amazon. I will follow up with you directly.

-Lisa

3

Hello Tavius,

I will send you an email regarding your Cloudfront questions/comments.

Kind regards,

Angela Han

Wowza Media Systems

4

There is not a work-around, because Wowza is not streaming to clients in this case. Wowza has no way of knowing what clients are playing from CF.

Richard

5

Thanks … looking forward to your contact.

Even though, it should work with Cloudfront anyway as it’s just http file delivery, just not optimized by them (am I right)?

I’ll be testing it anyway shortly

cheers

6

Just to add to the discussion, as I’ve kept working on this on my own

I have right now working HDS and HLS out of Wowza server into Cloudfront. As it’s HTTP streaming, which is based on files, it shouldn’t be much of a difference than caching any http object. It works conceptually, but performance is not good.

On Wowza, I can see there’s only one concurrent session even when there’s more than one user streaming. But, CF doesn’t perform very well as others CDNs. Most CDN, when it comes to http live streaming, they implement it in a different way than regular http object caching.

CF says they have an implementation for Smooth Streaming out of IIS and RTMP streaming out of Adobe Flash Server, developped to provide a reliable streaming experience (it involves the process of lighting up the server in paralell, etc).

I hope they work with Wowza to develop something similar. Meanwhile, I’m moving out of CF for my http streaming to other CDN. It’s convenient, but not reliable.

7

Hi there … actually, I’ve abandoned RTMP streaming a while ago. I’ve focused on HTTP streaming only, through Wowza or not

For what I know, RTMP using CF is only available when you use Adobe Flash Server. CF has a streamig service pre-defined for that (CF Streaming Distribution)

In general, my experience with CF for HLS is not good. Latency (as you say) is high in general, and I have performance issues in Europe (in North America is quite stable in terms of performance, but Europe is really bad)

I’m using Wowza for HLS and HDS. So, I’ve a couple of EC2 Wowza instances, running latest Wowza version that let you set Wowza as origin for CDN. Then, I’ve a couple of CF distributions for HTTP download pointing to Wowza servers as origin. Quite straight forward setting.

Again, CF performance is not good in general, so I’m testing other CDNs as I’m not happy with CF reliability for streaming

8

hi duxmedia … thanks for sharing your test. I had my setup similar to yours. Difference was my origins were in Sao Paulo. Streaming to North America throught CF distributions worked pretty well, but when I tested from Europe is when it failed. Not everywhen in Europe. For instance, it worked fine in UK and Germany, but badly in Spain and Italy. I tried to reach out to CF to understand how they distribute, what’s their transit, etc with no luck

We also checked we were being sent to right POP based on location, and we were. In Spain we were sent to Madrid’s POP. I’m in NA, so manually tweak my DNS to connect to the POPs where my testers were reporting as failing. And here’s the weird. From NA, connecting to Frankfurt POP, I had no problem streaming (neither testers in the area), but when connecting to Spain, I saw the fails right there.

Anyway, just wanted to share the long test we did before jumping out to another CDN

9

the idea of using Wowza as origin is not to load the users on it …so, yes, you lose granularity there. Being CDNs slow to generate reports based on logs, what we did was to generate our own connection analystics from the player.

10

Yes, it does use HTTP delivery. I have followed up with you via a Support ticket.

-Lisa

11

We do not yet have docs or support Cloudfront. We will post again when there is an update.

-Lisa

12

Thank you for sharing your feedback. Wowza on CloudFront is still not currently supported, however we are engaged with Amazon CloudFront team.

-Lisa

13

Hi Lisa… do you mean Wowza does not ‘officially’ support a Wowza origin setup server out of the box? Or is this a AWS issue that their templates are not ready?

In any case, I was much intrigued by Tavius’ success but her comment on CF being not reliable also got me thinking. So here is what we did.

We set up a Wowza pre-built AMI (c1.xlarge), pushed a 3mbps 720p stream to it, used the transcoder to split it into 6 diff bitrates and tested the link on our iOS device.

http://{ec2-Server}/{applicatonName}/ngrp:{streamname}_all/playlist.m3u8

It worked superbly!!! We did an ‘in-studio’ streaming test for 4-5 hours continuously on 5 diff machines playing this link in JWplayer 6. Again it worked like a charm!

Then we setup a CF download distribution with a TTL of 2 secs. pointed it to a ELB which in turn had the Wowza instance under it. And there you had it… Wowza origin with a CF dist. delivering live adaptive bitrate streams to desktops and iOS devices (droids and berrys are not covered in this discussion).

Now here is a word of caution… if you decided to stop the encoder or the connection breaks for any reason, this CF distribution will go for a toss and the stream will break. Workaround… have multiple CF dist. and update file to diff CF dist when one fails (we had 1 pri and 2 as backup). Also remember that the original CF dist needs 20-30 mins to “set itself right (cache clearing)” and can be used again.

We used the Singapore region for all our testing and delivery… and we are very interested in understanding how CF behaves in other regions.

14

Smooth Streaming is just HTTP as well.

Is this really a question of how to use CloudFront to cache RTMP? Is that what Amazon and Wowza need to work on together?

Is there anything that needs to be done for HTTP caching specific for CF?

15

I have been playing around with this setup (Wowza HTTP origin and CF distribution) in the North America region and so far works great. The one thing i am having problems with is figuring out a new way to monitor connection counts. When you configure Wowza for HTTP origin, the :8086/connectioncounts page no longer reports accurately (even when you do not use CND) Cloudfront logs usually show up about an hour after the live stream chunks were downloaded and not much help for determining how many people are watching live.

Has anyone else noticed this before or have any suggestions\workarounds?

16

Thanks Tavius, I will give that a shot.

17

Could you please include me also in the updates - I am anxious to leverage Smooth Streaming, HLS and RTMP through Cloudfront. Ideally with timed-signed URLs if possible.

18

Just to add to the discussion, as I’ve kept working on this on my own

I have right now working HDS and HLS out of Wowza server into Cloudfront. As it’s HTTP streaming, which is based on files, it shouldn’t be much of a difference than caching any http object. It works conceptually, but performance is not good.

On Wowza, I can see there’s only one concurrent session even when there’s more than one user streaming. But, CF doesn’t perform very well as others CDNs. Most CDN, when it comes to http live streaming, they implement it in a different way than regular http object caching.

CF says they have an implementation for Smooth Streaming out of IIS and RTMP streaming out of Adobe Flash Server, developped to provide a reliable streaming experience (it involves the process of lighting up the server in paralell, etc).

I hope they work with Wowza to develop something similar. Meanwhile, I’m moving out of CF for my http streaming to other CDN. It’s convenient, but not reliable.

Can you share how you’ve setup Wowza with Cloudfront?

RTMP = Wowza running on an EC2 instance - I am unable to open port 1935 in CF. I assume I have to use RTMPT (tunneling) through port 80 but not sure how to go about this.

RTMPS (RTMP over SSL) = not clear if this is possible.

RTMP via CF Streaming distribution (no Wowza) = Initial single user latency seems high.

RTMPE via CF Streaming distribution (no Wowza) = Initial single user latency seems high. Not clear what the Encryption is adding here as according to Wikipedia it’s proprietary and “fundamentally flawed”.

HLS = I generated static HLS segments using MediaFileSegmenter and stored them on S3. A CF Download distribution seems to work but single-user latency tends to vary.

HLS = I generated static HLS segments using MediaFileSegmenter and stored them on S3. Accessing S3 directly works and latency seems a little lower than CF.

I’d love to be able to test Wowza with CF but it looks like this no longer is an option for RTMP - correct me if I’ve wrong. And please share how you’ve configured Wowza with CF for HLS. Thanks in advance.

-fs

19

I would also like to chime in and say im interested in setting up Wowza to work with Cloudfront. (Pushing from an Origin server outside of EC2 to CF)