Shaka-player: low latency live stream, recommended settings?

Created on 9 Feb 2018 · 3Comments · Source: google/shaka-player

i'd like to live-stream content with as little latency as possible, even if it causes occasional stutter or choppiness. what configuration options do you recommend?

archived question

Source

gabor

Most helpful comment

The important pieces for this kind of a steam would be in the manifest itself. If we're talking about DASH, I would suggest:

(highly recommended) Use SegmentTemplate with 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.
If you must use SegmentTimeline or 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.
Set a low 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.
Use short segment sizes. It is common to use 2 second segments for live streams. You could reduce that to 1 to reduce delay. But that will only help if we don't require manifest updates.
Set a value of 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.
Make sure you have a UTCTiming element for clock-sync.

You should look at the documentation of your packager to see how to set these values in your live stream.

The only real Player setting that would affect latency would be streaming.rebufferingGoal. It is similar to minBufferTime, setting a smaller value will allow us to play with less content.

TheModMaker on 9 Feb 2018

🎉1 👍1

All 3 comments

The important pieces for this kind of a steam would be in the manifest itself. If we're talking about DASH, I would suggest:

(highly recommended) Use SegmentTemplate with 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.
If you must use SegmentTimeline or 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.
Set a low 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.
Use short segment sizes. It is common to use 2 second segments for live streams. You could reduce that to 1 to reduce delay. But that will only help if we don't require manifest updates.
Set a value of 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.
Make sure you have a UTCTiming element for clock-sync.

You should look at the documentation of your packager to see how to set these values in your live stream.

The only real Player setting that would affect latency would be streaming.rebufferingGoal. It is similar to minBufferTime, setting a smaller value will allow us to play with less content.

TheModMaker on 9 Feb 2018

🎉1 👍1

@gabor does that help? Please let us know if there's anything else we can do for you! Otherwise we'll go ahead and close the issue.