stash
stash copied to clipboard
stashapp
HTTP streaming overhaul
This is the overhauled HLS/DASH streaming implementation split out from what was in #3020 originally.
From before:
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.
Fixes #2901 Should close #2831
Should fix #2688 Should fix #2609 Both of these relate to WebKit - while it doesn't support DASH, the HLS transcodes work for me.
Could fix #2934 - I tried one HEVC video and the resolution was correct.
As mentioned in #3020 i can also confirm more cpu usage both on server (running stash) and on client (using firefox in a debian linux distro) for the dash vp9 part . It seems that there is a measurable extra overhead from the file concatenation and chunk encoding in the server part and an extra overhead to the browser (at least for firefox, due to the extra js library for the dash support?). For reference i tried a few 1080p 29.970 fps (so that the fps are close to the now used 30 ) wmv files with and without forcing a 720p resize (via max live transcode option). The dash webm ends up with not as a smooth playback as the original plain webm version
Was there a reason to use dash with vp9 instead of dash and h264 (x264 with the veryfast preset is way faster and less resource heavy)? The extra overhead from the filesystem could be compensated by the lower cpu usage for the x264 encoding? HLS with mp4 seems to work fine
Also do we need to completely remove the non dash webm implementation? VP9/WEBM is a nice combination since it is streaming compatible and supported by many browsers natively (unlike dash with webm) with the only issue being that VP9 is slow when encoding even with the realtime option.
The reason (at least how I see it) for this whole DASH/HLS overhaul is to no longer need to use the hacky live.ts videojs plugin which more or less emulates scrubbing for the live transcodes as they are essentially livestreams. DASH is just needed to keep VP9 encoding as an option because HLS only supports H264 - HLS is much more widely supported, even natively in Safari and mobile browsers, in comparison to DASH which has more overhead and is completely unsupported in Safari.
If we ditch VP9 transcoding entirely then there would be no need to use DASH at all, but for those who have the hardware that can handle VP9 it should theoretically offer better quality.
I've just done a quick test on the difference in encoding time for a 5 minute wmv file and a 5 minute mp4 (both 23.976fps), and it seems to take around 10% longer on my PC (wmv 160s vs 174s, mp4 101s vs 114s). With a native 30fps mp4 file however both give identical results of 129s, so I think the overhead here is coming from the framerate conversion and not the splitting/filesystem. I'll look into avoiding that forced 30fps.
All the 30fps limits are now gone, and the encoding time after a quick test is now virtually identical to develop.
I also think I've figured out why the player was stuttering at the beginning of the video so I'll get to fixing that.
In the latest version I'm not seeing any of the stuttering at the start of the video. However, the dash implementation doesn't appear to have seamless segment splitting. As the file is playing it, there's definite gaps in the playback where it's skipping forward in the playback. I've also had issues where the video errors out or hangs. So far, I haven't seen any problems with HLS playback.
I've changed things up a bit, so segments are now queued for transcode. Playback should be more reliable now.
I see what skipping you're talking about, and it seems like that is happening because when the ffmpeg process is terminated (even gracefully with an interrupt) it doesn't finish writing the current segment and leaves a partial segment behind. The partial segment then means a bit of the video is missing which causes the player to skip. For HLS this isn't a problem because it writes to a temp file first which is then renamed, but the webm_chunk muxer doesn't have this option. The only real way I can think of which would fix this would be to have stash do the temp file renaming itself, which would probably involve directory watching and be rather complicated. Embedding the ffmpeg libraries and calling them directly would also allow for a fix, and would likely improve performance and be easier to work with later on, but would be very big and difficult to add so I don't know if that's a good idea or not. I'll probably end up trying to get the former working, but that might take a while.
Given that DASH isn't currently working smoothly. I think this should be split further, and we should not remove the live plugin just yet.
For the moment, I think we should split out the HLS overhaul and give that a thorough test. We can consider a second PR to preference HLS by default over the legacy live transcoding - and probably provide a setting to change the default behaviour.
DASH can be considered separately if it is necessary to replace the current VP9 implementation.