[Enhancement] Trying to use the latest video.js version

[unixfox]

Here are my findings at trying to make the latest video.js version working.

What I discovered:

• videojs-http-source-selector is completely broken, but that's because we are using the old method for initiating the video.js player. I submitted a fix here: rename hls to vhs in the player #2847

• when selecting another quality from the quality selector, video.js will sometimes try to use an unsupported codec, either we try to understand what's going on or we remove the codec from the available dash playlist:

• forcing a video quality in the preferences will result in a very low quality.

[SamantazFox]

We really need to dig into how all of that (HTML video playback, videoJS) works, or find someone who can do it. I'm going to be honnest: JS is my pet peeve, and video playback in a browser is quite new to me, so don't really count on me for that xD.

[unixfox]

I found why videojs-http-source-selector and the force to a specific quality are behaving strangely. The current video.js that we use don't support WEBm, but the latest one does, due to that it's conflicting somewhere. Omitting webm from the dash manifest fixes the bug.

The bug video append of seems to be fixed by:

• removing the audio codec mp4a.40.2 which doesn't seem to be compatible with firefox nor chrome.
• by setting overrideNative to false but it has the side effect of making the quality selector not working on chromium. Solution found in HLS error ("video append failed") on older Chrome/SmartTV videojs/video.js#7008 (comment)

[unixfox]

There seems to be a new algorithm in https://github.com/videojs/http-streaming that works better to retry again when the internet drop out or there is an issue with the server:

experimentalBufferBasedABR: true

cf https://github.com/videojs/http-streaming/search?q=experimentalBufferBasedABR

[unixfox]

Found a better quality selector from the authors of videojs : https://player.support.brightcove.com/plugins/quality-selection-plugin.html, but I don't know if it's legal to use a plugin with license UNLICENSED in it.

It's also a good idea to try this PR that may fix some bugs in videojs-http-source-selector: jfujita/videojs-http-source-selector#17

[ivancduran]

• Sorry for my english I'm writing this comment very fast but I hope to show my idea clearly

I think is a problem inside the VHS library an how the library manage the buffers, I'm using video.js for a personal project, and the problem still persist even with the brightcove plugin and the exprimental buffer enabled, off course its more stable but still crash randomly.

every time you chose another quality the vhs library cleans the buffer and start again from zero, and I think its very agressive for the player and network, and I think cleans the current buffer and the player dosen't have any chunk to playback.

Reviewing how jwplayer does the change and I see the change is more smoothly, they don't drop the current chunks, and also if you make a quality downgrade they dont clean the current chunks until the player gets the new quality.

I already test all the quality selectors on NPM and all of them uses: videojs-contrib-quality-levels,
Also I created an script to change the qualities every 10 seconds directly with quality-levels and the problem still happends, that is the reason why I think the issue is inside VHS.

The only workarround that works for me is don't use the VHS library and integrate shaka-player inside videojs with this library: https://github.com/davidjamesherzog/videojs-shaka, With shaka everyting works fine but its a little bit heavy becase I'm loading videojs and shaka libraries at the same time.

I hope the videojs team fix this in the future, please tell me if you find another alternative.

Thank you.

[ghost]

Any updates on this? videojs 8.1.1 uses vhs 3.0.2. This enables Low Latency HLS by default which should help tremendously for livestreams if not using webrtc. (Unsure if webrtc is in use).

[unixfox]

Any updates on this? videojs 8.1.1 uses vhs 3.0.2. This enables Low Latency HLS by default which should help tremendously for livestreams if not using webrtc. (Unsure if webrtc is in use).

Last update from #3011 (comment):

This PR bumps video.js to the latest version 7.12.1. The versions after that seems to have some issues with the videojs-http-source-selector plugin which is by the way unmaintained, we should look into removing it with another way to offer a quality selection.

[ghost]

here's a source selector fork being maintained by freetube
https://github.com/FreeTubeApp/videojs-http-source-selector

jfujita/videojs-http-source-selector@ea373f8

[unixfox]

We already know, I'm subscribed to this issue: jfujita/videojs-http-source-selector#69 (comment)

Anyway if you really want to have a newer videojs version then feel free to do some experimentation with the fork from freetube with a newer videojs version and get back to us if it works fine or not.

[unixfox]

From therealone2047 on matrix:

Hello. I noticed that you've been unable to update Videojs because of videojs-http-source-selector not being compatible with newer versions. I wanted you to be aware of a fork I found that did a rewrite for newer versions: https://github.com/OzetAkademi/videojs-http-source-selector
Relevant upstream issue: jfujita/videojs-http-source-selector#90

[unixfox]

From sadpanda800 on matrix:

Video.js now has an official quality selector. Works with both HLS and DASH.
https://github.com/videojs/videojs-contrib-quality-menu

From syeopite on matrix:

Some JS and CSS regarding the player needs to be rewritten but the plugin works great. I believe that the lack of a quality selector was one of the major blockers to VideoJS 8 along with browser support