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

[baconz]

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]

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.

[baconz]

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]

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]

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]

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]

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]

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.