Refactor to derive live edge from list of segments

[joeyparrish]

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.

[chrisfillmore]

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.

This is an issue we may be running into in our application. I haven't done a complete investigation yet. But since I'm pretty sure someone will ask me -- May I ask, is this refactoring being worked on currently? Is there a (rough) estimate for when the work will be done? Thanks.

[joeyparrish]

We are not working on it yet, primarily because we aren't yet sure how best to do the refactoring.

[chrisfillmore]

Ok thanks Joey 👍

[vaage]

Hey @joeyparrish, once this is done, it looks like you may be able get rid of ManifestDB and all its associated types (StreamDB, SegmentDB, and SegmentDataDB.) and replace them with Manifest and its associated types (Stream, Segment, SegmentData).

[chrisfillmore]

@joeyparrish can you confirm, with this change, that Shaka would ignore device time for SegmentTemplate + SegmentTimeline, i.e. this would also resolve clock sync issues for such content?

[joeyparrish]

Yes. With this change, only SegmentTemplate+duration would need to use availabilityStartTime, device time, or clock sync.

[kuznetcoff777]

One thing i cannot understand, encoder makes stream in unstopable way (if some drift happens then it will not make segment less or more by time (for example if drift one second back, then segment will be any way for 5 seconds as configured))

In HLS there is a timestamp can be shown explicitly via #EXT-X-PROGRAM-DATE-TIME for every 5 seconds (when ts segments for 5 seconds for example) and if drift happens then this tag can be changed and player will use correct time.

In DASH if template is used, then i dont get how player will know that drift happened if segmetns still the same length in seconds? I thought that multi-period should help in this case.

[leandromoreira]

@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.

[joeyparrish]

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.

[jakubvojacek]

@joeyparrish perfect! cannot wait to see it & test it! 👍

[avelad]

@joeyparrish Is it possible include this change in 2.4.4?

[joeyparrish]

I found a bug in the implementation which needs to be corrected, so I'm reopening this issue.

@avelad, I won't include this in v2.4.4 because it's a major behavior change and comes with some amount of risk. I think the fact that I didn't get it right the first time supports this decision. :-)

I am planning to release a couple of betas for v2.5, though. If you're willing to try out a beta, you can have this feature before v2.5.0 is final.

[joeyparrish]

Oh, and I forgot to explain the bug I found: it only works for single-period content where the period starts at 0. The timestamps I'm using to compute the live edge are relative to the period, but they should have been relative to the presentation.