Refactor to derive live edge from list of segments
See original GitHub issueIn 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.
Issue Analytics
- State:
- Created 6 years ago
- Reactions:1
- Comments:13 (10 by maintainers)
Hi everyone,
I had plans to solve this as part of a larger refactor, which is described in #1339. I now think this should be solved in a simpler way, by just modifying the DASH parser. I still plan to refactor things in #1339, but there’s no reason this issue needs to be dependent on that.
@kuznetcoff777 I think this http://www.unified-streaming.com/blog/stop-numbering-underappreciated-power-dashs-segmenttimeline can help you understand how it is possible to signalize discontinuities in Dash.