Recovery from failed/slow segment fetching?

[Feenposhleen]

Hi

We have been experiencing some issues possibly introduced in the later (1.4.0 & 1.4.1) releases. Whenever a live stream stops to buffer (because of network issues etc.), the player never resumes playback by itself, even though it eventually fills the required buffer. If you manually trigger the play method, playback resumes just fine.

This can be easily reproduced by throttling the network speed during playback until playback stops, and then stop throttling.

As a quick fix, we have considered to repeatedly call the play method during buffering pauses, but this is of course less than ideal.

Is this a known issue? Is there a way to find out when enough buffer is filled for playback to resume?

Thank you

[tdrews]

There is a bug. The Player exits the buffering state when the streams have re-buffered minBufferTime (MPD attribute) seconds of content. However, if minBufferTime > streamBufferSize (which defaults to 15) then the streams will never buffer enough content to exit the buffering state.

To rule out any other issues: is your minBufferTime set to something larger than 15 seconds or are you setting streamBufferSize explicitly?

[Feenposhleen]

Yes, we have a minBufferTime of 30, and have not touched the shaka setting. This bug is probably it.

I will reply again tomorrow after some experimentation.

[Feenposhleen]

Okay, so the issue is confirmed for our use case. Changing the encoders to deliver 12s minBufferTime solved it. Thanks a lot!

I'm gonna sneak in another question while I'm at it; what is the easiest way to modify the "safety padding" that Shaka applies to the live edge?

[tdrews]

Glad you were able to solve the issue. The master branch also includes a fix, which will be part of the v1.5.0 release.

I'm gonna sneak in another question while I'm at it; what is the easiest way to modify the "safety padding" that Shaka applies to the live edge?

So, we compute the stream start time differently depending on the MPD style,

• for SegmentTemplate + SegmentTimeline, the earliest possible start time is determined by the last segment(s) specified in the SegmentTimeline(s).
• for SegmentTemplate + @duration, the earliest possible start time is deduced from the current time, @availabilityStartTime, and several other variables (see https://github.com/google/shaka-player/blob/e74ad98eaad82fb60c4940a0ad4e661f8679e90a/lib/dash/dynamic_live_segment_index.js#L146).

However, for both MPD styles the VideoSource offsets the stream start time by @minBufferTime so the streams can buffer at least that amount of content... this is probably why you are seeing a large offset from the live-edge.

tl;dr; I suggest you use a larger streamBufferSize (see Player.configure) with a smaller @minBufferTime, this will reduce your offset from the live-edge at startup (and reduce startup latency) whilst also ensuring a large buffer during playback.

[joeyparrish]

minBufferTime is defined by the DASH spec as the time that must be buffered before playback begins in order to achieve no-rebuffer playback with the bandwidths specified in the manifest. So not only do we wait until minBufferTime to start up, it's not feasible to stream all the way to the live edge without accounting for minBufferTime.

streamBufferSize, on the other hand, defines how much data has to be in buffer before we stop fetching segments. It's the buffering goal during playback, so it makes sense to have this larger than minBufferTime.

Since you want low latency startup, you use small minBufferTime. Since you want to get ahead of the game to avoid transient network slowdowns, you use a larger streamBufferSize.

For live streams at the edge, when streamBufferSize is larger than minBufferTime, you won't ever be able to get a full streamBufferSize of data in buffer (because it's not available yet). But this setting will have an effect when you rewind and watch from behind the live edge.

[Feenposhleen]

Awesome responses. Very helpful. Thanks again!
Also major bonus points for RFC-esque ASCII diagrams in the source comments. =)