Latency in the context of live streaming is the delay (generally expressed in seconds or milliseconds) between a timestamp in a real-life event and the moment viewers are able to view this real-life event on their viewing device. While low-latency notion generally applies to live streaming, low-latency can also help with faster start-up time and seeking with on-demand streaming.
Most of the optimisations at this point in time have to be done on the DASH streaming server in order to reach low-latency streaming. Our player does already support CMAF for DASH streaming which allows for low-latency streaming.
The next step which we plan for 1st semester 2020 is to support Ultra-low-latency CMAF streaming using DASH.
Those are our recommendations for your DASH manifest to best support low-latency DASH streaming:
duration. This ensures that we don't need to do manifest updates to learn about future segments. The manifest will include info about all future segments.
SegmentList, set a low
minimumUpdatePeriod. The spec says 0 is valid, but we will override it with a minimum of 3 seconds between updates. If you use SegmentTemplate with duration, set this to a high value to avoid useless network activity.
minBufferTime. This allows faster recovery from stalls by allowing us to start playing with less content, at the cost of a higher chance of another stall.
suggestedPresentationDelay. If you don't set it, we will pick a default of 1.5 times
minBufferTime. This affects the delay between the calculated live edge and the one we use. A lower value will make us play closer to the real live edge, but we will stall more if the segments aren't available yet.
UTCTimingelement for clock-sync.
The only player setting that could affect latency would be
shakaStreamingRebufferingGoal. It is similar to
minBufferTime (set in DASH manifest), setting a smaller value for
shakaStreamingRebufferingGoal will allow our player to play with less content.