Skip to content
By using AWS re:Post, you agree to the AWS re:Post Terms of Use
AWS re:Postre:Post
About re:Post

Cross-continental 4k DASH Livestream is buffering

0

Hi,

I am currently facing challenges with offering a smooth DASH livestream from Germany to West America. The stream, which is already encoded in 4k 50fps HEVC, is uploaded to an S3 bucket. My setup involves S3 combined with a CDN, but this configuration leads to frequent buffering and does not perform well in America, although it works fine for me in Germany. The stream is accessed by only 1-2 devices in America.

Initially, I did not enable caching in the CDN, as I understood that it might not provide any benefits for such a low number of viewers. In my research, I came across solutions like "pre-warming" the CDN and Cross-Region Replication (CRR) for S3, but I believe these might not be the right solutions for my case.

What would be a good approach to ensure a smooth streaming experience in West America? Are there specific AWS services or configurations that could help improve the performance of my preencoded stream?

Thanks!

Topics
StorageNetworking & Content DeliveryMedia Services
Tags
Amazon CloudFrontLive Video StreamingCachingAmazon Simple Storage Service
Language
English
asked 2 years ago808 views
2 Answers
1

Is your encoder on premises sending the DASH encoded stream to the S3 bucket? Are you able to use services like MediaConnect and MediaLive? You can contribute to the cloud your 4K Live stream, encode the stream in ABR using MediaLive and send the ABR stream into two different regions. Allowing this way your CDN to request the content to the correct origin based on client device geographic location. Setup caching at the CDN since most CDN's have a layered caching approach at the region level before actually requesting content from the origin

AWS
answered 2 years ago
  • Quental, Nuno
    2 years ago

    if you do not want to have buckets in two regions, another way is to reduce the segment/fragment size of your 4K renditions so the amount of date being transferred from the origin to the CDN and to the end device player is lower. This of course as benefits on the latency/buffering but it has drawbacks on the encoding efficiency/quality

  • khj
    2 years ago

    Yes, the encoder is on premise sending to an S3 bucket and that's why I can't use MediaLive to encode the stream. I havn't considered MediaConnect yet, would this have an advantage compared to my current setup? With my question, I want to make sure that I am using the correct AWS setup with the correct settings (like caching) for my application. If yes, then I have to optimize the encoder settings like segment length or similar

  • Quental, Nuno
    2 years ago

    Using your on-premises encoder you can contribute a high resolution/bitrate to the cloud using MediaConnect. From there you can use MediaLive to create your ABR ladders and send the HLS ABR to MediaPackage in two different regions (EU and US). In MediaPackage you can setup CMAF/DASH endpoints in two regions and distribute the content to your viewers in Germany and west US thru the CDN. The use of MediaPackage is needed because MediaLive currently does not output DASH outputs. For further information on creating DASH Endpoints, please see the following documentation: https://docs.aws.amazon.com/mediapackage/latest/userguide/endpoints-settings.html

0

I'm not a specialist in streaming, but if you have control of the player settings, you could try increasing the amount of data/time to buffer on the client side. Bandwidth shouldn't be a factor as such, but if the client only pulls a small amount of data at a time, it might not be able to keep up with the stream due to the relatively long response time pulling the next tiny chunk all the way across mainland US and the Atlantic.

Caching in CloudFront or another CDN should have a similar effect, albeit with a different mechanism. The CDN would buffer an appropriately large chunk of data from the S3 origin, and because the network round-trip times between the clients in US west and the nearby CDN node would be relatively short, the presumably small buffer on the client might be able to keep up, because the CDN node would probably buffer a larger amount of data and possibly the whole file, allowing the client to receive the next tiny block quickly.

EXPERT
answered 2 years ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Relevant content