Implement live VTT subtitle loading

[johnBartos]

This PR will...

• Start and stop subtitle loading in sync with startLoad()/stopLoad() API calls
• Compute sliding & merge subtitle playlists during live playback
• Fix shared references between subtitle-track-controller and subtitle-stream-controller
• Refactoring:
  • Extend subtitle-stream-controller from base-stream-controller
  • Move more shared logic into base-stream-controller
  • Move live reload interval calculation into a shared function & import into subtitle-track-controller
  • Remove the trackId from subtitle fragments, and refer to them by their level property
  • Several other minor refactorings (flipped conditionals, destructuring args, organizing functions)
• Add a bunch of unit tests

Why is this Pull Request needed?

Live subtitle playback is not functioning correctly - on first glance, it appears that sliding isn't being calculated between live refreshes. This is true, but in the course of fixing it I noticed that the live VTT implementation was incomplete and had several unhandled edge cases.

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

We (JW) QA tested this and shipped it in our 8.7.6 release. It would be good to double-check that any code specific to the JW fork didn't make it in. This was our test criteria:

• When live captions are enabled, cues should appear within 1 segment duration
• When VOD captions are enabled, cues should appear immediately
• Cues should appear at the expected times for as long as captions are enabled
• When the live stream is paused/stopped captions loading must stop
• When captions are disabled, no cues or captions manifest should load

Test streams:

• https://wowzaec2demo.streamlock.net/vod-multitrack/_definst_/smil:ElephantsDream/elephantsdream2.smil/playlist.m3u
• https://liveaffect.cdn01.live.rd.insyscd.net/vtt-test-live/live.m3u8

[johnBartos]

Once this is merged into master I'll cherry pick it onto the 0.12.3 branch

[mtoczko]

I see an issue when stream(vtt) have pdt. In the loop loads segments n+1. And player loading segments when is paused.

[johnBartos]

@mtoczko Can you give me a test stream please?

[michaelcunningham19]

Diff looks good to me 👍

I am curious about the above mentioned issue w/ PDT though

[mtoczko]

@johnBartos
pdt: https://mtoczko.github.io/hls-test-streams/test-vtt-pdt/playlist.m3u8
whiteout pdt: https://mtoczko.github.io/hls-test-streams/test-vtt-pdt/playlist2.m3u8

Easy way to reproduce this issue is use jwplayer.

{ 
playlist: [{
                file: 'https://mtoczko.github.io/hls-test-streams/test-vtt-pdt/playlist.m3u8',
            }],
  preload: 'auto',
  autostart: false
}

Start stream, turn on subtitle and reload page.

HLS.JS
Start stream, seek to 60, turn on subtitle, seek to 50.

[itsjamie]

Couple of bits and bobs of changes that could be done, but nothing that has to be imo. I got through most of the PR, and if none of the small changes got caught as incorrect behaviour by unit tests then 👍 given the manual QA that's happened.

[itsjamie]

This is slightly different in the implementation that was here before.

Previously the max was taken between the rounded result in reloadInterval and minReloadInterval, now it's the max of the unrounded reloadInterval and minReloadInterval.

I don't see this resulting in any meaningful impact though. It could lead up to if I recall Javascript rounding right, a reload interval that occurs up to 0.49s early?

[itsjamie]

Hm. One thing I have noticed is that during live playback that cues are missed if you are right at the live edge (within a single SD from the end).

[itsjamie]

Also, it doesn't backfill old buffer that is outside of the current window. So if you had captions disabled on the first go around, and that is captions file is out of window now, it doesn't go fetch it.

To implement this we would have to break:

• When captions are disabled, no cues or captions manifest should load

Possible change. If done, the biggest we could spec compliantly get away with is fetching the segment once it's elapsed a full sliding window.

In that, if the window is thirty seconds, the segment should be available on the origin for AT LEAST a full minute according to spec, so we could backfill to that limit, but we would have to be constantly fetching the manifest to do so.

I think we wait for folks to request this behaviour, since it's code we would never get rid of, its a lot of network requests, and most folks don't enable captions and then seek whole windows back in their buffer. I'm struggling to think of a site that has a sliding window, but allows seekback into local MSE buffer.

[mtoczko]

LGTM

[johnBartos]

Glad to have your approval 😄

…

On Fri, Mar 8, 2019 at 19:04 Marcin Toczko ***@***.***> wrote: ***@***.**** approved this pull request. LGTM — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2148 (review)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEzwZLEg6GqtYhpj2jVUDwEqcAKX7DoQks5vUvqNgaJpZM4bO2HS> .

[michaelcunningham19]

👍