Skip to content
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

Can't have unbuffered seek to 0 when live stream starts #692

Closed
baconz opened this issue Feb 11, 2017 · 7 comments
Closed

Can't have unbuffered seek to 0 when live stream starts #692

baconz opened this issue Feb 11, 2017 · 7 comments
Assignees
Labels
status: archived Archived and locked; will not be updated type: bug Something isn't working correctly
Milestone

Comments

@baconz
Copy link
Contributor

baconz commented Feb 11, 2017

During live playback, the Playhead.reposition method prevents the user from scrubbing all the way back to 0 (AST). There's a comment in the code with a TODO to explain why, but no explanation is given.

Can you guys explain this?

@TheModMaker
Copy link
Contributor

When there is a seek, there are a number of cases that we may be in: Live/on-demand, buffered/unbuffered, in-range/out-of-range, etc.. That TODO is about explaining how the code handles all those cases in the way that we want. It is unrelated to your actual question.

In live streams, segments may not be available forever. Usually they are only kept around for a set amount of time. In DASH, this is specified using the timeShiftBufferDepth attribute. This specifies an "availability window" for how long a segment is available on the server. If the manifest only says segments will be available for 1 hour, then you can only seek backwards for 1 hour since older segments may have been deleted off the server.

You may want to look at shaka.media.PresentationTimeline, which defines which segments are available (Playhead enforces it). Specifically, getSegmentAvailabilityStart and getSegmentAvailabilityDuration.

@TheModMaker TheModMaker added the type: question A question from the community label Feb 13, 2017
@baconz
Copy link
Contributor Author

baconz commented Feb 14, 2017

Ah, sorry -- I should have been more specific.

For live playback the code calculates a safe starting point by taking the earliest start, adding 1 second and the rebuffering goal. Assuming that safe region is inside the available window, it will add another 2 seconds to the targetTime.

Imagine a live manifest where the timeShiftBufferDepth is greater than or equal to the duration of the segments that are presented -- that is, the buffer is expanding, and not rolling. In this case, the first period starts at 0, and all of its segments are always available for playback, so getEarliestStart() returns 0. If the minBufferTime is set to 8, given the calculation above, the earliest that the user will be able to scrub to is 11 (8 + 2 + 1) -- this doesn't seem right to me, since those first 11 seconds are available and playable.

My questions are:

  • Why add 1 and 2 to the safe buffer region?
  • Why add the rebufferingGoal to the safe region?

It seems to me that rolling, or not, the beginning of the buffer (getEarliestStart()) should always be available on the server (ideally with some padding managed by the server), and that this calculation is superfluous.

@TheModMaker
Copy link
Contributor

Ok. We could probably drop the 1, maybe the 2. I'll need to discuss with the rest of the team. Unfortunately the person that wrote it is no longer here and I'm a little fuzzy on the details of those. This also needs to be adjusted for our (relatively) new in-progress recording support.

The reason we add rebufferingGoal is because we are unbuffered and we assume the window is moving. So when we seek to that position, we will need to pause and wait for segments to be downloaded. This can cause us to "fall" outside the availability window while we buffer. To be safe, we add rebufferingGoal, which should be the amount of content that needs to be buffered to have seamless playback; therefore it should be a good approximation of the amount of time it will take to buffer enough.

@baconz
Copy link
Contributor Author

baconz commented Feb 14, 2017

Understood. I feel this conversation really comes down to getting a precise definition of timeShiftBufferDepth. My feeling is that liveEdge - TSB should represent the earliest possible time for which a segment request can start. If a segment falls outside of the TSB while a request for that segment is in progress, the server should not delete the segment.

On a more practical level, I guess I'm saying that the server should be responsible for making sure segments remain available for rebufferingGoal or at least segmentDuration after they expire. This does not feel like it should be the client's responsibility.

@TheModMaker
Copy link
Contributor

The expiration is calculated based on the end time of the segment. So if liveEdge - TSBD is in the middle of a segment, that segment is still available. It is only after liveEdge - TSBD passes the end time of the segment is that segment no longer available.

The problem on the client is that we have no way of knowing how long a segment remains available on the server, so it is the client's responsibility to enforce the availability window. Now, we could allow playing content that we have already downloaded (e.g. the case where we "fall" outside the availability window while buffering); however, this can cause confusion for the users (especially with the seekable range). This also breaks the intent of the TSBD, which is that the content is no longer available after that time, so we shouldn't play it.

We allow playing content that is near the earliest availability time, but so long as we are buffered so we don't fall outside the range while buffering.

@baconz
Copy link
Contributor Author

baconz commented Feb 14, 2017

Ok, I get where you're coming from here.

In the case where there is no duration (so this is not an IPR), but the back buffer is not (yet) rolling. It seems like we need to let the user scrub to the beginning in this case. What about adding a check to see if the overall availableDuration is less then the TSBD by more than the rebufferingGoal -- if that check passes, maybe we could just set safe = earliestStartTime?

@TheModMaker
Copy link
Contributor

You're right. The problem is we adjust the availability start to 0. After we adjust, we add rebufferingGoal. What we should be doing is calculating the availability start, subtract rebufferingGoal, and then adjust to 0. This will allow 0 to be considered "safe" so long as TSBD is far enough away.

@TheModMaker TheModMaker added type: bug Something isn't working correctly and removed type: question A question from the community labels Feb 15, 2017
@TheModMaker TheModMaker changed the title Explain Playhead.reposition_ Can't have unbuffered seek to 0 when live stream starts Feb 15, 2017
@TheModMaker TheModMaker added this to the v2.1.0 milestone Feb 15, 2017
@TheModMaker TheModMaker self-assigned this Feb 23, 2017
@shaka-project shaka-project locked and limited conversation to collaborators Mar 22, 2018
@shaka-bot shaka-bot added the status: archived Archived and locked; will not be updated label Apr 15, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
status: archived Archived and locked; will not be updated type: bug Something isn't working correctly
Projects
None yet
Development

No branches or pull requests

3 participants