Results 1 to 4 of 4

Thread: Wowza/CloudFront Live HLS Startup Time and Latency

  1. #1

    Default Wowza/CloudFront Live HLS Startup Time and Latency

    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. #2
    Join Date
    Dec 2007
    Posts
    21,962

    Default

    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. #3

    Default

    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

  4. #4
    Join Date
    Dec 2007
    Posts
    21,962

    Default

    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

Similar Threads

  1. Experience and recommendations with EC2 and HDS/HLS with cloudfront
    By pperezs in forum Wowza Streaming Engine in the Cloud
    Replies: 2
    Last Post: 06-28-2014, 07:02 AM
  2. Encrypted HLS through Cloudfront
    By chris098 in forum Wowza Media Server 3 for Amazon EC2 Discussion
    Replies: 1
    Last Post: 01-30-2014, 01:04 PM
  3. Wowza server in AWS/Cloudfront HLS stream to VLC player not working
    By jdehart1 in forum Wowza Media Server 3 for Amazon EC2 Discussion
    Replies: 1
    Last Post: 10-18-2013, 01:06 AM
  4. Minimizing HLS latency
    By tdistler in forum Performance Tuning Discussion
    Replies: 8
    Last Post: 05-23-2013, 10:45 AM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •