stream-controller won't seek to live if seeking before the first fragment

[mfedderly]

This PR will...

Split out the logic that forces seeks to jump to live if they are too far behind the live point from the logic that constrains seeks to the beginning of the video.

Why is this Pull Request needed?

I've got an HLS chunklist where the first fragment starts at 2.5ish seconds instead of 0. We'd like to seek to the beginning of the video, so we try to seek to 0. Since this is before 2.5, HLS jumps to live. Instead I propose that we first clamp the seek to the start of the video, and then apply the check for maxLatency.

Are there any points in the code the reviewer needs to double check?

Resolves issues:

Checklist

• changes have been done against master branch, and PR does not conflict
• new unit / functional tests have been added (whenever applicable)
• API or design changes are documented in API.md

[johnBartos]

Can you try seeking to video.buffered.start(0) instead of 0? I don't think your use case is broad enough to warrant merging into master, and as this is a change in the existing API, it must be made in a major release.

Alternatively, you can get the fragments array from an event, and set Hls' start time to that fragment's start.

[mfedderly]

video.buffered.start(0) isn't necessarily the earliest part of the video that is seekable, depending on when you started the player. Is there a way to get access to the fragment data from outside of HLS code? If I can look up the start time and seek there instead, I wouldn't need this change.

[mfedderly]

video.seekable.start(0) also returns 0 so I can't use that.

[johnBartos]

@mfedderly Try listening to the LEVEL_PTS_UPDATED event:

`hls.on(Hls.Events.LEVEL_PTS_UPDATED, data => {
    video.currentTime = data.start;
});

Let me know if this works

[mfedderly]

LEVEL_PTS_UPDATED exposes the fragments, so its possible to get the information, just a little tricky to make sure we have a set of fragments after HLS has attempted to load the fragment for time offset 0. Going to go ahead and close this, but I'll probably keep using my forked version in the short term before attempting to use these events.

Thanks!