New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Refactor to derive live edge from list of segments #999

Closed
joeyparrish opened this Issue Aug 29, 2017 · 13 comments

Comments

7 participants
@joeyparrish
Member

joeyparrish commented Aug 29, 2017

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.

@joeyparrish joeyparrish added this to the v2.3.0 milestone Aug 29, 2017

@joeyparrish joeyparrish modified the milestones: v2.3.0, v2.4.0 Oct 3, 2017

@chrisfillmore

This comment has been minimized.

Show comment
Hide comment
@chrisfillmore

chrisfillmore Nov 14, 2017

Contributor

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.

Contributor

chrisfillmore commented Nov 14, 2017

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

This comment has been minimized.

Show comment
Hide comment
@joeyparrish

joeyparrish Nov 14, 2017

Member

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

Member

joeyparrish commented Nov 14, 2017

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

@chrisfillmore

This comment has been minimized.

Show comment
Hide comment
@chrisfillmore

chrisfillmore Nov 14, 2017

Contributor

Ok thanks Joey 👍

Contributor

chrisfillmore commented Nov 14, 2017

Ok thanks Joey 👍

shaka-bot pushed a commit that referenced this issue Nov 27, 2017

Allow Playhead to recover from drift
There are two ways Playhead should be able to recover from a drifting
stream:

1. Wait until the initial position is available
2. Seek to another position

Neither of these was working.  For one, we couldn't detect seeks
before content was loaded.  For another, we were constantly updating
the initial streaming position, so a drifted stream would never catch
up to our expectations.

This fixes both issues so that a drifting stream can at least recover.

Relates to issue #999 (drift tolerance)

Closes #1105

Change-Id: I8d2eedcff25b92b42ecd2e1f361d45ecbddd26ba

joeyparrish added a commit that referenced this issue Nov 27, 2017

Allow Playhead to recover from drift
There are two ways Playhead should be able to recover from a drifting
stream:

1. Wait until the initial position is available
2. Seek to another position

Neither of these was working.  For one, we couldn't detect seeks
before content was loaded.  For another, we were constantly updating
the initial streaming position, so a drifted stream would never catch
up to our expectations.

This fixes both issues so that a drifting stream can at least recover.

Relates to issue #999 (drift tolerance)

Closes #1105

Change-Id: I8d2eedcff25b92b42ecd2e1f361d45ecbddd26ba

@joeyparrish joeyparrish modified the milestones: v2.4.0, Backlog Dec 4, 2017

@joeyparrish joeyparrish modified the milestones: Backlog, v2.5 Mar 4, 2018

@joeyparrish joeyparrish moved this from To do to Blocked in Tracks & manifest refactor Mar 6, 2018

@vaage

This comment has been minimized.

Show comment
Hide comment
@vaage

vaage Apr 17, 2018

Member

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

Member

vaage commented Apr 17, 2018

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

This comment has been minimized.

Show comment
Hide comment
@chrisfillmore

chrisfillmore May 24, 2018

Contributor

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

Contributor

chrisfillmore commented May 24, 2018

@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

This comment has been minimized.

Show comment
Hide comment
@joeyparrish

joeyparrish May 24, 2018

Member

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

Member

joeyparrish commented May 24, 2018

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

@kuznetcoff777

This comment has been minimized.

Show comment
Hide comment
@kuznetcoff777

kuznetcoff777 Jul 22, 2018

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.

kuznetcoff777 commented Jul 22, 2018

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

This comment has been minimized.

Show comment
Hide comment
@leandromoreira

leandromoreira Jul 22, 2018

Contributor

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

Contributor

leandromoreira commented Jul 22, 2018

@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

This comment has been minimized.

Show comment
Hide comment
@joeyparrish

joeyparrish Jul 23, 2018

Member

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.

Member

joeyparrish commented Jul 23, 2018

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

This comment has been minimized.

Show comment
Hide comment
@jakubvojacek

jakubvojacek Jul 23, 2018

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

jakubvojacek commented Jul 23, 2018

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

@avelad

This comment has been minimized.

Show comment
Hide comment
@avelad

avelad Aug 8, 2018

@joeyparrish Is it possible include this change in 2.4.4?

avelad commented Aug 8, 2018

@joeyparrish Is it possible include this change in 2.4.4?

@joeyparrish joeyparrish reopened this Aug 16, 2018

Tracks & manifest refactor automation moved this from Done to In progress Aug 16, 2018

@joeyparrish

This comment has been minimized.

Show comment
Hide comment
@joeyparrish

joeyparrish Aug 16, 2018

Member

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.

Member

joeyparrish commented Aug 16, 2018

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

This comment has been minimized.

Show comment
Hide comment
@joeyparrish

joeyparrish Aug 16, 2018

Member

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.

Member

joeyparrish commented Aug 16, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment