Caching in Amazon CloudFront for HLS/HDS streaming with Wowza 3.5

Question

I am trying to quickly learn some of the underlying technology behind HDS and HLS live streaming.

I have set up Wowza Media server 3.5 on a Amazon WebServices instance in EC2 and distribute through CloudFront. I did my first live event and was watching my server load creep higher and higher. I was wondering if anyone could help me understand some of the underpinnings of HDS/HLS live streaming (and nDVR...):

• Wowza is the origin server for my cloudfront distribution
• HDS manifest file is set to cache for 2 seconds in CF (TTL time)
• I checked all the IPs hitting my Wowza Instance, they appeared in fact to be CF caching locations, or edge servers
• (assumption) Since all HDS traffic is over port 80, all video content ends up being cached at the edge locations (albeit for 2 secs)

Here's where my question comes about: how data is served for video content (here's my understanding, please set me straight!): - When a viewer requests a playlist or mainfest file, they get XML back which points the player to a chunk of video/audio (m4fa and m4fv within the DVR application instance?) data that they need to play next. Since this data is also delivered over port 80, it is cached as well.

If the above statements are correct, then does the following make sense for optimization for HDS and HLS:

Case 1: DVR service: I set the rules for caching in CloudFront as follows:

• anything ending with "f4m", "m3u8", and "?DVR" to cache for 2 seconds (the playlist/manifest files)
• the default for everything else should cache for longer (perhaps an hour, or 24 hours...?) This way, the DVR data remains cached but the playlist keeps updating every 2 seconds

Case 2: No DVR service (is this the better way to optimize?)

• I suspect we could optimize server load as well by killing the DVR service all together, this way all data distributed through CF is just the most recent audio/video packets - therefore all viewers should be requesting the same playlist and data files, and thusly a large amount of people requesting those files is no big deal since my server is only getting hit every 2 seconds from each edge location to update the manifest files).
• If this the media file chunks are given a longer caching time, would it matter if we killed the DVR service if the media remains cached?

Thanks for any insight you can offer!

Answer 1

Is there a way to configure a different sitename for the media? For DVR sessions, you want the m3u8 files to be served directly from your server (no CF, or 2 second CF), but the media files to be served though CloudFront with a really long expire time.

(For non-DVR sessions, it could all go thru CloudFront, since it's cachable.)

The usefulness of CloudFront really depends on how many popular (and unpopular) streams you have.

For example, let's say there are 20 CloudFront boxes in a particular POP. If 5 people view a stream, each one is likely to hit a different CF box, get a cache miss and need to hit your server anyway. You'd have to have 50 or 70 people viewing a stream from that POP before CloudFront stops hitting your server and serves everything from the cache. Because there are many POPs, you could have 100 people viewing a stream all over the world, but each hitting a different box in a different POP, and your server still gets 100 requests.