Wowza/CloudFront Live HLS Startup Time and Latency

Wowza Streaming Engine
1

Hi,

My target is 6-second latency to stream live content from a single Wowza instance to an end user using HLS. If I use CloudFront to distribute the live stream, instead of end-users connecting directly to Wowza, how much additional latency is added to the live stream? I understand it will vary based on distance between the origin and the edge location. I’m looking for a rough estimate of:

  • How much time does it take the stream to become available in CloudFront versus directly from the Wowza origin.

  • When the live stream is available from CloudFront and viewed by the end user, how much behind real time is the stream.

  • In my setup, streams are dynamic - they start, run for a few minutes and then stop. They are only consumed by 1 viewer. Is CloudFront a poor fit for this application, should I be looking at the liverepeater origin/edge configuration instead? My main goal is to make streams available across AWS regional boundaries using origin/edge locations in each AWS region. (ie. Wowza origin in each region feeding CloudFront for edge distribution versus Wowza origin/edge/edgeorigin in each region pulling streams across regions only when necessary).

Thanks,

Dan

2

Dan,

Starting with your 3rd bullet, yes, CloudFront seems unnecessary for your application. For short live streams only ever consumed by just 1 viewer, I don’t think Live Steam Repeater (origin/edge) is necessary either.

For lowest latency live streams to HLS clients, you want the source to have a short key frame frequency of 1 or 2 seconds and a corresponding cupertinoChunkDurationTarget as shown in this guide

Richard

3

Dan,

So the advantage is all in the Amazon internal network between origin and edge. That might be significant. I think you should test and compare.

Richard

4

Thanks Richard.

In my application, the encoders are either Flash-based webcam recorders (RTMP) or IP cameras (RTSP). I want to achieve the lowest latency and most reliable channel between an encoder and a viewer - the viewer may be in a different EC2 region. If the viewer is in a different EC2 region, I suspect that the best performance will be achieved by connecting the encoder to the closest Wowza instance, then pulling this stream over Amazon’s internal network and the WOWZ protocol to a Wowza edge server in a different region (where chunking into HLS will be done). I was also considering trying CloudFront for this, but it seems like that may add too much latency or too much startup delay.

Is this reasonable, or do you think similar performance would be achieved by simply connecting the viewer across the Internet to a potentially distant Wowza server?

Thanks,

Dan