Scene player improvements

[DingDongSoLong4]

This is quite big, but all the changes are quite integrated at this point so I'm sending it all together here.

~This replaces the transcoding implementation to only use HTTP streaming formats (HLS for H264 and DASH for VP9), based off of #2322. The videojs player doesn't support VP9 with DASH natively, so videojs-contrib-dash (using dash.js) is needed.~

I've also refactored the videojs plugins and added type information for them so that most of the any casts in ScenePlayer are no longer needed. The markers plugin is also now a class and stores the markers itself, instead of using subtitles and cues stored in the player.

The scene player component itself has been overhauled. Autoplay and scene markers now work more consistently, and the spacebar always pauses/plays the video. Most of the multiple source logic in the player component has also been moved into the source-selector plugin.

The scrubber has also been overhauled and is now more consistent and responsive in general. I also moved the scrubber auto-hiding into the component instead of CSS, so that the scrubber isn't rendered at all when it isn't being displayed on mobile for example. The scrubber also now uses videojs-vtt.js (which is already a dependency of videojs itself) to parse the sprite VTT files instead of the 'gnarly' previous implementation.

I've also copied the videojs-vtt-thumbnails-freetube library into the project as suggested in #2793 and rewritten it in TypeScript, with a few tweaks and a fix for thumbnail scrubbing on mobile.

I've also updated a few dependencies, ~and fixed a circular dependency warning that Vite gives when building the UI~.

2bd64e7 removes the now unneeded chapters_vtt endpoint - I guess it's possible that some external plugin or application might need it for some reason but I think it's fine to remove.

Fixes #2877 Closes #2856 Fixes #2793 Closes #2771 Should fix #2476

[WithoutPants]

I'm seeing pretty significant jerkiness and slow performance when viewing wmv files using the default dash implementation. It's a definite step down in quality from the current implementation.

[DingDongSoLong4]

I haven't noticed any jerkiness, but my PC is relatively powerful so the buffer builds up quite quickly. I copied all the video transcode quality-related ffmpeg options straight through from before, so the actual quality and encoding performance should theoretically be similar.

Do you still get bad performance when using the stream.mpd link in something that can play DASH like mpv? (VLC doesn't seem to be able to from my testing) I hadn't tested WMV files very thoroughly, but playing one now I can see that there does seem to be some scrubbing issues (only for WMV files) at least when using the site player - mpv plays them perfectly. I'll see if I can figure out what's causing that.

It might be a good idea to make the HLS stream the first in the list anyway, as that is more widely supported and stable. VP9 encoding is still a lot more intensive than the H264 used for the HLS stream, at least at the current encoding settings. An option to change transcode quality is something I'll probably add as well, perhaps even something for hardware encoding which would speed everything up drastically.

[WithoutPants]

Both PCs (host and client) are pretty decent machines, so it shouldn't be a performance issue. I noticed that it's particularly bad at the start of a video. I'll do some more thorough testing later.

I think that it's worth splitting up this PR, because there are a number of very good improvements unrelated to the HLS/dash stuff. If you don't get to it first, I'll spend some time rebasing and opening up some separate PRs.

[DingDongSoLong4]

Thanks! I initially didn't split the HLS/DASH stuff out because the live.ts hackery wasn't playing nicely with the updated source-selector.ts, but that was quite early on so the version of source-selector that ended up here might actually work fine. I had reworked live.ts with types, less prototype hacking and into a class, but I just got rid of it after adding HLS/DASH, which in hindsight probably wasn't a good idea. I'll see if I can either find that version or just rewrite it.

[WithoutPants]

I tried to split and rebase, but I'm running into issues with the big button plugin. The buttons don't appear to be firing when clicked. I'll probably do the circular vite fix manually, but otherwise you might need to do the splitting for me.

[DingDongSoLong4]

Yeah the circular vite fix is just a one liner, can't say I understand why it gives that warning in the first place but that gets rid of it so all's good I guess. I should be able to get the splitting working, I'll check it out later today.

[DingDongSoLong4]

Alright I've split out all the transcoding stuff from here into a separate PR - let me know if you'd like me to split it up even further.

[cj12312021]

I just jumped on this branch to do some testing, and I'm also noticing some jerkiness with the playback compared to the previous version. I also noticed that play-progress bar disappears when transcoding to very low resolutions.

I tested subtitle support while transcoding, and it doesn't seem as accurate(the timing is off). My server is also currently committing a lot of resources to preview generation so that might also be playing a role. However, playback from on v0.17 release is still more stable under the same condition. I'll circle back once the server is under less load.

[DingDongSoLong4]

Is this on the version with the dash support or not? Both HLS and DASH split the transcode into 2 second segments for streaming which means that if the encoding can't keep up then playback will pause every 2 seconds - is that what you're seeing? The encoding settings are basically identical to before but the files have to be split and written to the filesystem before being streamed so that is probably adding a bit more overhead.

For the subtitle issue, what browser are you using? Everywhere I've tested them they seem to be working for me. I'm also unable to reproduce the progress bar disappearing issue.

[cj12312021]

Playback is more stable now that the server isn't under as much load. Captions also seem to be as accurate as they were before testing this change again. However, the progress bar still appears to be less responsive when transcoding. It disappears when selecting the webm option(shown 19 seconds in), and in some cases, it does not return when changing to other transcode resolutions(I was unable to capture this in the recording below). Also, skipping to different time intervals on this branch temporarily reset the progress bar position, which I don't see happening on the release build. Sometimes when skipping around to earlier time intervals, the progress bar position gets set to the end of the video which then completely stops playback.

https://user-images.githubusercontent.com/72030708/198896207-6f8fea6a-46a2-46c5-9dc6-096406f62041.mp4

Regarding https://github.com/stashapp/stash/issues/2476, Your change does address some of the hover issues. The big one being the preview image remaining visible. I still see that the hover glow on the progress bar sometimes persists. The big buttons are not very responsive on my phone with these changes as WP mentioned earlier. I have to mash the play, rewind, or fast-forward button for a while before the input is registered.

[DingDongSoLong4]

Fixed the big buttons and hover issue. The progress bar is part of videojs itself so I've just force-removed the hover glow to fix it. The disappearing progress bar issue is only happening on Chromium browsers, which is why I wasn't able to reproduce it originally. I can now vaguely remember that I was facing some kind of similar issue when I reworked live.ts the first time, so I should be able to find a solution.

[DingDongSoLong4]

Alright I think I've fixed those scrubbing issues now, thanks for the testing and feedback.

[cj12312021]

I can confirm that the big button and progress bar issues are gone. Thanks for pushing the fixes.

[WithoutPants]

When scrubbing a live-transcoded video, it's showing the cover image instead of a black screen while it loads. Is it possible to maintain this behaviour? New behaviour is a little jarring.

[WithoutPants]

This is looking close to complete. It seems to have broken Handy integration when clicking the seek buttons. I'll need some time to work out what the problem is.

[DingDongSoLong4]

I don't have a Handy so you'll need to test it, but I took a look at what player events get fired when scrubbing a transcoded stream vs a direct stream, and I've added a force trigger for the timeupdate and pause events which weren't being fired - hopefully that fixes the problem.

[WithoutPants]

I'll try to do some debugging, but my testing is with a direct streamed file. Clicking on the timeline or scrubbing any other way works fine. It's only when clicking on the seek back 10 seconds/seek forward 10 seconds buttons that it gets out of sync.

[WithoutPants]

I think I was able to fix this. The seeking event handler was removed, which I think ended up callling onplay as part of the call to player.play(). I re-added seeking back with the following code:

    function seeking(this: VideoJsPlayer) {
      if (!this.paused()) {
        if (scene?.interactive && interactiveReady.current) {
          interactiveClient.play(this.currentTime());
        }
      }
    }

And added player.on("seeking", seeking"); and the equivalent off call.