Thank you for asking this question on the AWS Elemental MdeiaLive forums, before we delve to deeply into the issue can you share with us what your current latency is looking like? It would be helpful to see what you are currently seeing as far as your latency and then see if we can shave some time off from that.
We managed to achieve 7 seconds latency with HLS.js player. Please refer to the screenshot:
There are two sides as far as you can see that:
- on the left: a stopwatch app - in our case just a bash script rendering current time to be captured, encoded, and upstreamed via RTMP PUSH to AWS Elemental MediaLive input,
- on the right: web app with integrated HLS.js player, which plays the media stream from the AWS Cloud (going thru MediaLive -> MediaStore -> CloudFront CDN)
It's important to mention that we forced the player to keep its buffer as tiny as possible - for sure it's not a production case as having this setup we do observe buffering issue quite frequently. In production, we will add few seconds to achieve better stability. But as of now, we are looking for EDGE glass-to-glass Latency - absolutely minimal latency that we can get with cloud-based streaming architecture.
Here are a couple areas that you can modify to shave some time off your latency, if you have not already done them, all of these settings will be located under the output video stream settings.
Look ahead Rate Control: Setting it to low will improve latency while reducing output quality for demanding scenes. Low works well mainly if there are no or few scene changes, though.
GOP parameters: It is recommended to use closed GOPs of 1 second duration that can be later on repackaged in 2 seconds segments if needed. Small GOPs without B Frames generally reduce video quality.
B Frames: The more B Frames used in a GOP, the higher the probability that encoding latency will be increased by a few frames for each B Frame added, as the encoding engine will look ahead to the next P Frames to construct the B frame. Using zero B Frames is possible to evacuate this latency impact, but it will require raising the encoding bitrate to keep the same quality level as when using B Frames.
Adaptive Quantization: Turning it off will reduce latency by a few frames. The other Adaptation Quantization options don’t impact latency.
Encoder Buffer Size: The default value is twice the video bitrate in bits, which generates a 2 second delay on the decoder. If set to 1x bitrate, it generates a 1 second delay and slightly impacts the video quality. For a very aggressive low latency target, the buffer size could be set to half of the bitrate, which results in half a GOP (1/2 second) of delay. Of course, the video quality will be more impacted; under 1/2x bitrate, the impact on video quality is more severe.
More information can be found here, it deals with Elemental Live but these settings are also available in MediaLive:
Edited by: Zacharyb-AWS on Apr 8, 2021 10:16 AM
Thanks, Zach for your help. Particularly thanks for the confirmation that encoding tuning in AWS MediaLive makes sense - we tried this and the mentioned 6 seconds latency we have - is in respect of this.
Could you please also advise if it's possible to utilize such a beneficial feature of CMAF with a cloud-based solution (MediaLive) like a "chunked delivery" that the on-premises Elemental Live solution does already provide?
It explained in a really good way in the article, so let me cite it here:
"How it works
The AWS Elemental Live ULL workflow utilizes Common Media Application Format (CMAF) media files with chunked delivery. The CMAF media files provide smaller addressable fragments of video than traditional HTTP-based file segmentation. These fragments can progress through the delivery chain to the next component before the entire file segment has been created. In traditional HTTP streaming, an entire file had to be completely written before the next component can request it. Other optimizations in the AWS Elemental Live encoder include manifest creation, CDN integration, and player capabilities, mostly based on CMAF and chunk delivery."
Best Regards and Many Thanks,
We can do Chunked Transfer when using HTTP Live Streaming HLS, it becomes available when you set your CDN Settings to HLS Webdav or HLS Akamai. However it is not supported when delivering to MediaPackage, when using HTTP Live Streaming MediaPackage the optimal settings are included but Chunked Tranfer is not supported by it.
Thanks, Zach for the insights. What you described makes sense to me.
Now I'm just wondering when we set CDN Setting to "HLS media store" (what we currently do in our setup), does media stream transfer work in a Chunked way?
I apologize, I just checked and when using the CDN Setting HLS to MediaStore it does not do chunked transfer.
Thank you very much, Zach, for all your help! Not sure if it's feasible at all with the current MediaLive service architecture and implementation, but an opportunity to reduce streaming latency with chunked transfer in MediaLive to MediaStore scenario - sounds good to me - please consider this as a feature suggestion :) (of course, if it's feasible).
In our current setup 1 sec segment size is used. So the understanding is - potential latency optimization due to potential "chunked transfer" feature utilization might be roughly up to 1 sec for us (potential 17% latency reduction in our case). Not bad :)
Best regards and many thanks,
4K Live Streaming Solution - How to get there?asked 7 months ago
IVS - live streaming issue - Starvation startasked 8 months ago
How to use Low-Latency HLS with MediaPackage?asked 4 months ago
Amazon IVS Latency 15 seconds on iOS web?asked 23 days ago
AWS S3: Live video streaming data storing into S3asked 2 months ago
Low Latency Live streaming with CMAFasked a year ago
IVS or Live Streaming?asked 2 years ago
AWS architecture for Low latency trading systemAccepted Answerasked 2 months ago
CloudFront Live Streaming - Active ViewersAccepted Answerasked 2 years ago
Kinesis streams for low-latency appsAccepted AnswerMODERATORasked 5 years ago