Description
In HLS, the live edge of a presentation seems to be derived from the list of segments. In DASH, the live edge is (currently, in our implementation) derived from the availabilityStartTime attribute and the current time.
But even in DASH, there are multiple ways one could compute the live edge. With <SegmentList> or <SegmentTemplate> + <SegmentTimeline>, we get an explicit list of segments, much like in HLS. Only in <SegmentTemplate> with the duration attribute do we lack this explicit list, in which case availabilityStartTime is the only option. So although our current model matches the DASH spec, it does not match the majority of what we see in practice.
In cases of encoder drift, the actual segments differ from the idealized live edge we compute based on availabilityStartTime. (This type of drift could occur in HLS, as well.) When this happens, we are limiting ourselves by only working with this ideal live edge, rather than the effective live edge based on the segments.
When we encounter drift in live DASH today, we see issues as soon as the drift is larger than presentationDelay. When that happens, the player can never reach the live edge. Playback can continue further back from the edge, but eventually, drift can also overtake timeShiftBufferDepth. When this happens, the actual segments are completely outside of the seek range, which leaves the player unable to play anything at all.
To improve our resilience in these scenarios, we should compute the live edge based on the list of segments. In this case, drift would cause occasional buffering events, but playback could recover indefinitely.