[Bug] Long DASH Videos causes Page to Become Unresponsive

[arjpar]

Describe the bug Playing long (time-wise) videos on Firefox through DASH causes CPU usage to spike and the page to become unresponsive.

1. CPU usage spikes when initially loading the page, then subsides after initial loading is done.
2. Once the video is clicked on and is loading, CPU usage spikes again - the page also simultaneously becomes unresponsive.

Steps to Reproduce

1. Go to https://yewtu.be/watch?v=8jLOx1hD3_o on Firefox, ensure that DASH video quality is selected in Invidious preferences
2. Wait for the page to load and monitor CPU usage.
3. Once the page is loaded, click on the video and monitor CPU usage once again
4. Wait and observe the lack of responsiveness of the page

Logs N/A

Screenshots Firefox:

Chromium:

Additional context

As discussed on Matrix.

Tested on Firefox v102.0.1 w/ extensions disabled . Also tested on Chromium v103.0.5060.134 w/ extensions disabled which predictably did a bit better (in steps 1 and 2 above) but still had a spike in CPU usage and eventually became unresponsive (steps 3 and 4 above) .

Hopefully someone else can test this on Firefox and Chrom(e|ium) with extensions disabled and see if they can reproduce .

[NebulaOnion]

This bug is also reproducible by me on the latest invidious version (on same conditions).

(I'm willing to provide logs and information to fix this bug).

[joe27g]

Can confirm this bug has been happening as long as I've used Invidious. I regularly watch long videos... or at least try to. When it's unresponsive, strangely, it's pinning a single CPU core in Firefox but two cores in Chromium (Brave.) And notably, I couldn't get the example video above to load in Chromium at all, compared to it being slow but eventually working in Firefox.

In my experience, it works OK when you're starting from the beginning, but the further in you resume, the longer it takes to load. Typically when I try to resume a >10hr video from >4hrs in, it will take ~30s to start playing, then stop playing and become unresponsive for a few seconds 2 or 3 times, then the DASH player will decide the current environment can only handle 360p (and even that lags out sometimes :P) At that point, I usually give up and just download the video instead.

I tried this with the example video and seeking to about 10 hours in, and the result was that not only was the page unresponsive, but it produced so many warnings and /videoplaypack requests (which all returned 0 bytes) that even the devtools became unresponsive.

Using a shorter (~14h) video, I ran a performance test in Firefox to grab some info, so I'll attach a screenshot below. I tried to do the same in Chromium, but couldn't get anything useful. These function calls might indicate this is an issue with video.js, but I haven't had time to dig in deeper and see for sure.

[unixfox]

If you enable Save playback position in the preferences you can automatically get back to the video segment that you left before refreshing the page.

By the way I think this bug is related to the fact that a videostream given by Google has an expiration time and you are probably reaching it after around 4 hours, effectively loading an invalid URL. What you should look for is the network tab to see if you see any errors, especially 401 or 403 errors.

[ghost]

I'll try to see if there is something on the Firefox developer console.

[NebulaOnion]

This is the only log produced:

This page uses the non standard property “zoom”. Consider using calc() in the relevant property values, or using “transform” along with “transform-origin: 0 0”. watch
VIDEOJS: WARN: videojs.plugin() is deprecated; use videojs.registerPlugin() instead video.js:163:49
Specified “type” attribute of “application/dash+xml” is not supported. Load of media resource /api/manifest/dash/id/ZOAExL-xIDM?local=true&unique_res=1 failed. Trying to load from next <source> element. watch
Autoplay is only allowed when approved by the user, the site is activated by the user, or media is muted. video.js:24023:27
videojs-http-source-selector initialized! videojs-http-source-selector.js:209:13
player.techName_:Html5 videojs-http-source-selector.js:210:13
MouseEvent.mozPressure is deprecated. Use PointerEvent.pressure instead. video.js:2083:12
VIDEOJS: loadmetadata event video.js:163:49
player.videojs_http_source_selector_initialized == false videojs-http-source-selector.js:229:17
Source map error: Error: JSON.parse: unexpected character at line 1 column 1 of the JSON data
Resource URL: https://yewtu.be/videojs/videojs-markers/videojs-markers.js?v=0fd672d
Source Map URL: videojs-markers.js.map
Image corrupt or truncated. M74.jpg

[unixfox]

Don't check the console, check the network tab.

[joe27g]

If you enable Save playback position in the preferences you can automatically get back to the video segment that you left before refreshing the page.

Yep, I love this feature and use it all the time. It's also practically essential sometimes, since if you try to seek anywhere in a long video, this issue will usually cause it to fail, either initially or after seeking.

By the way I think this bug is related to the fact that a videostream given by Google has an expiration time and you are probably reaching it after around 4 hours, effectively loading an invalid URL. What you should look for is the network tab to see if you see any errors, especially 401 or 403 errors.

This seems correct, since I've seen this behavior with youtube-dl, but I haven't had an opportunity to check. Since I always have Invidious proxy the videos, I'm not sure if these errors would be passed through. The thing is, this wouldn't really matter if the unresponsive client issue didn't exist. Being forced to take a break every 4 hours is fine if you're confident the video will actually load when you come back :)

[NebulaOnion]

@unixfox I couldn't find anything interesting, just loads of videoplayback requests.

[syeopite]

I've recently encountered this and I don't believe its a problem with expiration times since Firefox becomes unresponsive on the initial load rather than playback.

You can reproduce it on this 160 hour video https://yewtu.be/watch?v=X0RK2jz5HOI

[SamantazFox]

@absidue Explained in the matrix chat that this is caused by VideoJS trying to fetch the video without any range headers on the first request (to validate the header). We'd have to patch http-streaming

https://github.com/videojs/http-streaming/blob/v2.16.1/src/dash-playlist-loader.js#L374 https://github.com/videojs/http-streaming/blob/v2.16.1/src/util/container-request.js#L15

Relevant discussion: https://matrix.to/#/%23invidious%3Amatrix.org/%24gOf-WCy0W-0TQ_RpTPBGPkVM5q3ErocrrrTWaZu-0WU?via=pussthecat.org&via=envs.net&via=matrix.org&via=libera.chat