Initial segment seeking

[shaharmor]

General question:
In a LIVE stream, When loading a segment with a duration 10s that took 2s to download, will playback start at 0s of the segment or at 2s (due to the time it took to download)?

If 2s, what happens when the time it takes to download the first segment is longer then its duration?

[TheModMaker]

Buffering and seeking logic is the same for live and on-demand content. So if this were on-demand, we would start playback at 0s. Initially, there is no content in the <video> element, so we cannot play anything. We will wait in a buffering state until we have enough content buffered, then start playback.

Where we start playback is a little different for live vs on-demand. On-demand content starts at 0s, unless you specify a start time. Live starts close to the "live-edge". We look at the manifest and determine where "now" is in the stream and start playback there. This may be in the middle of a segment, but has nothing to do with how long it took to download the segment. We don't adjust start time based on how long it took to download: we pick a time to start at, buffer starting from there, and start playback once we have downloaded enough.

If the segments are 2s and it takes longer than 2s to download, we should adapt to a lower bitrate (if there is one). It should always take less time to download than to play; otherwise playback will stutter because we will be buffering a lot.

[shaharmor]

So what happens if you decide that you need to start playback at time +4s, but it took you to get that segment 6s? You are now 2s behind where you wanted to be at.

Also, what you're saying can cause an issue that if I have 10s segments and minBufferTime of 6s, if ShakaPlayer decides to start playing at the middle of a segment, it will need 2 segments to start playing instead of 1 (because it will only have 5s in the buffer, even that it downloaded 10s of buffer).

I really think this messes things up, and should at least be configureable (And off by default).

[TheModMaker]

We have no way of knowing how fast the internet connection is initially, so we don't know how long a download will take. So we just start playback at "now" and we will be close to the live edge. If you want to be right at the live edge, you can just seek after we have buffered up to it. We could add an option to automatically seek to the live edge once we have buffered, but it should be easy for your app to do this: once we leave the buffering state (you should get a buffering event) then seek to the end of the seek range.

The minBufferTime specifies the minimum amount of time that needs to be buffered to have smooth playback. This means, according to DASH, we shouldn't start playback until we have at least that amount buffered. With a segment taking 6s to download, the minBufferTime would need to be at least 6s, otherwise we won't get smooth playback. If you start at 7s in a segment: we would start playback, play for 3s, then enter another buffering state because we haven't finished downloading the next segment yet.

For live streams, you should really have a shorter segment duration. This allows segments to be downloaded faster and can help with startup time.

[shaharmor]

@TheModMaker I appreciate your response.
I understand that your decision on where to start playback is not related to the download time.

My concern is, that if I set my segments to 10s, and the minBufferTime to 6s, I expect that playback will start once the user downloads 1 segment, and not 2.
But if ShakaPlayer decides that it starts playback somewhere in the middle of that 1st segment, it will have less than the required minBufferTime of 6s in the buffer and thus require another segment download, which will then cause more loading time to start playback.

I think that it should be configurable on whether to start playback "now" (as you said), or at the beginning of the segment that "now" is in. And honestly I think that the default should be at the beginning of the segment.

I have seen situations where "now" was set to 9s inside a 10s segment, which caused Shaka to download a whole 10s segment just for that 1s of buffer, which seems to be a really odd decision.
It makes playback loading time unpredictable because it depends not only on your download speed, but also on what time you started watching the stream.

[TheModMaker]

Ok, so you want a configuration option to start at a segment boundary. We can do that.

[TheModMaker]

It is possible for a manifest to not be accurate, meaning that the times in the manifest are not the same as the times in the media segments. To account for this, we will actually start downloading segments before the time we want. So even with a 6s minBufferTime and 10s segments, we will download two segments, up to three, to buffer enough.

For example: if the times in the manifest are behind the times in the media and we start playing at the beginning of the segment. We would download that exact segment which would start after where the playhead is and be left with a gap. This is why we unconditionally download the segment before the time we want.

Also note that audio and video streams may not be aligned. So a "segment boundary" may not be exactly at the start of the segment.