DASH video playback issues (massive buffering pauses, auto quality doesn't work properly)

[VitinhoCarneiro]

I've been experiencing a number of issues with DASH playback which make it completely unusable.

I'm on Firefox Quantum 67.0.4 (Linux). The issue happens in any video, and I've reproduced it in both invidio.us and dev.invidio.us. And I have no issues playing video over the same network in the official Youtube webpage or in other alternate clients such as NewPipe on my Android device.

First - DASH playback always starts at the lowest quality available and never switches automatically to a higher quality level.

Second - Trying to switch to a higher quality results in very frequent and massive buffering pauses - usually over 30 seconds for 1080p playback. On the network log, there are huge gaps between DASH fragment requests and the requests only seem to be made when the video buffer is almost empty and seem to take a very long time to be answered for no apparent reason.

[Perflyst]

invidio.us seems quite overloaded at the moment, does this also happen on another instance: https://github.com/omarroth/invidious/wiki/Invidious-Instances ?

[mark9064]

is there any way to see the current load on the site?

[VitinhoCarneiro]

For some reason, it does indeed seem to be less of a problem in certain instances, such as invidious.snopyta.org - but I'm still getting constant buffering pauses (though they're only a couple of seconds long) and the auto quality changer still gets stuck at the lowest quality.

Also, it doesn't make sense for the server load to affect the playback experience, since I'm not using proxy mode - in other words, video fragments are served directly from Youtube and not from the server instance. And this issue does not happen when DASH playback is disabled.

[Perflyst]

With dash proxy is also enabled. There is no dash without proxy

On July 1, 2019 11:44:39 PM UTC, VitinhoCarneiro notifications@github.com wrote:

For some reason, it does indeed seem to be less of a problem in certain instances, such as invidious.snopyta.org - but I'm still getting constant buffering pauses (though they're only a couple of seconds long) and the auto quality changer still gets stuck at the lowest quality.

Also, it doesn't make sense for the server load to affect the playback experience, since I'm not using proxy mode - in other words, video fragments are served directly from Youtube and not from the server instance.

-- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/omarroth/invidious/issues/616#issuecomment-507464186

[VitinhoCarneiro]

With dash proxy is also enabled. There is no dash without proxy

Why would you need a proxy to playback DASH content? This doesn't make sense to me... though that would explain the inconsistent performance.

Also, the network log shows requests being made directly to googlevideo.com servers and not to the particular Invidious instance.

[omarroth]

is there any way to see the current load on the site?

Not currently. I'm not aware of a good metric other than those currently provided in /api/v1/stats.

video fragments are served directly from Youtube and not from the server instance

DASH segments will always be proxied to bypass CORS, see here and here.

[mark9064]

Maybe you could install some load monitoring software such as netdata so the site load is visible

[Perflyst]

That probably does not really help with invidio.us because it is load balanced with haproxy and in the background are multiple servers

[mark9064]

netdata supports having multiple servers as data sources and 1 master dashboard where you can have data from all of them

[omarroth]

Suggestions for data sources and other statistics would be very welcome in #164. The host for https://invidio.us does already offer some metrics, although as @Perflyst mentioned I'm not sure how useful they would be in this case.

I've pushed a couple changes that should speed up DASH playback (e5fa5df7be38d60ce9e4835bae170d805482afc0 and 28df6881a7eade190236ace253947a52e3a2da32). From some testing on the main instance I am able to watch 1080p without issue. If you would like to test again @VitinhoCarneiro feedback would be appreciated.

[shakeyourbunny]

I can reproduce this exact behaviour with the "main" instance invidio.us, invidious.snopyta.org and my own one which is not accessible publically. This erratic behaviour is on the Youtube side (see below), as I could reproduce this with youtube-dl and/or appropriately constructed GET requests via curl.

According to the logs, the video fragments have wildly varying loading times, in the range of 2 - 20 seconds.

My general observation is that the Youtube server itself have only some "master" versions of videos itself and do much transcoding on the fly and only write the transcodes to disk if there is a certain threshold of demand and purge "old" transcodes after some time. This causes the pumping behaviour.

Some example video URLs where you can reproduce this (at least time of writing this post):

• https://www.youtube.com/watch?v=xeM1KD70_D4
• https://www.youtube.com/watch?v=ZbXDQ4LKJz0

I'd suggest this:

• a disk cache for fully rendered videos, configurable how big it can grow and how long the items are cached. With fully rendered I mean also storing the video codecs and quality used.
  • a cleanup task which purges old videos until the configured cache size / age of videos are met (and is currently not active).
  • an extra worker queue which accepts youtube video urls and gets the whole video for the cache.
  • on request, check if the video in the requested quality is already cached, if yes, play it from the cache (if proxying / DASH is enabled), otherwise queue the video in die worker queue and in paralell, do playback as usual (with tighter buffering).

[elypter]

sounds nice. i wonder how youtube gets around the buffering problems

[shakeyourbunny]

I think the issue lies in the JavaScript Videoplayer (assets/js/player.js) about here: https://github.com/omarroth/invidious/blob/059f50dad477daab63246314198ec7e274493ece/assets/js/player.js#L80

My guess is that this value is hand-tuned for the main invidio.us site (and even there it may not work). On my installation (is only accesible within my home LAN), according to my logs the requests talk in a range from 7,9 - 8,2 seconds with spikes up to 13 seconds. At least I experience on playing the video freezes at about every 8 sconds. No, my internet connection is not really at fault, latency to youtube.com is about 11-20ms and to googlevideo.com 10-15ms.

The player just re-requests data from the backend every 5 seconds (the 5000). Though this only is valid for video data, the timer for audio is somewhere else. If you modify it to another value the audio will get out of sync.

IMHO the "secret" sauce of the youtube video player is that there is no fixed interval when video data has to be re-requested, this is determined.

You really should fix this, it renders the whole point of the site useless. I appreciate your efforts, but adding some fluff functionality when the player itself is broken is a bit dumb.

[shakeyourbunny]

I was poking a bit in the source around (not being a JS programmer, but Python...), but I think the main problem is that the videojs package doesn't get fast enough DASH video frames though it should theoretically support this.

A possible alternative would be (untested): https://github.com/videojs/videojs-youtube

[stemy2]

I don't usez the dash player, but i have this problem anyway. Sometimes, the buffering is slow, if not nonexistent.

[yashendra2797]

I have an unmetered 500 Mbps fiber line. I can load 4K video from any site in a flash, but 1080p DASH on invidio.us is laggy as hell. Video will play for 2 minutes, then buffer for 2 minutes, then play again.

[github-actions[bot]]

This issue has been automatically marked as stale and will be closed in 30 days because it has not had recent activity and is much likely outdated. If you think this issue is still relevant and applicable, you just have to post a comment and it will be unmarked.