YouTube buffering

[RJVB]

These days I often get buffering issues with playback of YouTube videos in 720p mode. I have a 200Mbs fibre connection (often a bit more in reality) but find myself obliged to downgrade to 480p mode because download speeds from YouTube are apparently so slow that I run out of buffer continuously. This causes playback to halt every few seconds.

Is there anything (youtube-dl arguments) that can I experiment with to try to address this?

[zaps166]

I also noticed it, I'll look at this.

[zaps166]

QMPlay2 plays 2 different streams: video and audio (2 URLS). Looks like audio stream has buffering issues (can freeze for a long time).

Is there anything (youtube-dl arguments) that can I experiment with to try to address this?

youtube-dl is dead, use: https://github.com/yt-dlp/yt-dlp/releases

Run ./yt-dlp -g "youtube_url"

Output will show URLs per stream (video, audio). You can play separately (just add URL to QMPlay2 playlist) or play both at once: select "FFmpeg" in "Add address" window, enter URLs [https://url1][https://url2] and add.

[RJVB]

Thanks, will test and let you know. I suppose that you'll switch to using this new fork if it solves the issue?

[zaps166]

I suppose that you'll switch to using this new fork if it solves the issue?

I switched today to yt-dlp, but this only extracts (temporary) URL to stream from website.

I have a 200Mbs fibre connection

I think Youtube sometimes doesn't allow to download faster from URL I get from yt-dlp... Or it's also audio stream issue which can be downloading at 0kbps from time to time.

Do you have problems when seeking a stream? Sometimes seek is very slow to me, sometimes fast and can help also with buffering (reconnect to the server sometimes makes download faster).

[RJVB]

I think Youtube sometimes doesn't allow to download faster from URL I get from yt-dlp... Or it's also audio stream issue which can be downloading at 0kbps from time to time.

What I find strange is that the bandwidth difference is so big (most of the time!) between 720p and 480p. The audio content in those two is usually the same as far as I can see so it shouldn't be an actual bandwidth issue, but more something like deliberate throttling?

Do you have problems when seeking a stream? Sometimes seek is very slow to me, sometimes fast and can help also with buffering (reconnect to the server sometimes makes download faster).

I'll have to look (QMPlay2 doesn't start on this machine ATM; I had to rebuild my Mesa without OpenCL because VLC crashed on that and now QMPlay2 hangs in the check for X11 and EGL...) Either way, yes, doing a seek usually helps whenever streaming stalls; I understand better why that is if it forces a server reconnect.

[RJVB]

Moving to yt-dlp may have improved things a tiny bit, but it can also just be a coincidence. This morning things work normally, even. I noticed that simple downloads aren't exactly fast either (the other day, not today). Which brings me back to the original question: isn't there something to do about this through buffering? I assume that the buffer is implemented in QMPlay2 rather than in, say, ffmpeg, given that there is a graphical indication of the buffered segment. I think that the old QuickTime player (or probably the underlying SDK) had a nice intelligent buffer feature, where it would determine the buffer duration based on download speed and content bitrate, so that you had to wait only once before playback (as far as possible). Not sure if it ever buffered more than about half the entire duration before starting playback but I can see if it will still eat the audio streams from YouTube and either way this is closed source so it won't exactly help for implementing something similar. It would be nice to have this, or possibly just an option to buffer an entire streamed clip (rather than downloading it and then having to delete it, and not just from YT). I find a wait at the start much less annoying than watching something in bits and pieces.

[formlessdao]

QMPlay2 plays 2 different streams: video and audio (2 URLS). Looks like audio stream has buffering issues (can freeze for a long time).

Is there anything (youtube-dl arguments) that can I experiment with to try to address this?

youtube-dl is dead, use: https://github.com/yt-dlp/yt-dlp/releases

Run ./yt-dlp -g "youtube_url"

Output will show URLs per stream (video, audio). You can play separately (just add URL to QMPlay2 playlist) or play both at once: select "FFmpeg" in "Add address" window, enter URLs [https://url1][https://url2] and add.

How do we install yt-dlp on Windows 10 and enable it with QMPlay?

[zaps166]

or possibly just an option to buffer an entire streamed clip

go to playback settings and increase network buffer size to maximum and apply - it should help

How do we install yt-dlp on Windows 10 and enable it with QMPlay?

it's not possible on current Windows release. It is available only on git sources. If you need it now, download it manually and replace current youtube-dl (with exactly the same file name) in %appdata%\QMPlay2.

[RJVB]

go to playback settings and increase network buffer size to maximum and apply - it should help

I swear I looked for buffering settings... I see there's even an option to determine when to start playback of a buffering stream :( Either way, my comments on having these values determined automatically stand, but if YouTube continues to behave as it used and I'm on a fast connection the feature is less urgent for me.

[zaps166]

I have problems with YouTube slow downloading on many applications including download via command line using yt-dlp, Firefox extensions, QMPlay2, etc. A few days ago I wanted to download a video stream from various applications, all with speed ~80 KiB/s.

It happens sometimes on some streams. Currently I don't have any problems, it works fast.

I want to add an option to choose default video codec, maybe more luck with speed for streams with other codecs?

[RJVB]

Or it's just a bandwidth problem, with YouTube giving priority to people using a browser (and/or whatever official app they still provide) during rush hours? Or, more understandably, giving priority to paying users? Have you ever checked streaming speed in a browser during a sluggish episode?

[zaps166]

I just tried a video with the same codecs settings on QMPlay2 (and the extracted video URL in wget and Firefox) vs official YouTube player on their website.

QMPlay2 usually loads 4-5 seconds of video and then server stops streaming for a while (the pause is much longer than 4-5 seconds), after a pause, it buffers more data. The same problem with buffering is when I paste extracted URL (yt-dlp is extracting the URL) into a Firefox.
On official YouTube player it works correct.

The curious thing is that the same video worked perfectly on QMPlay2 about an hour ago.

[zaps166]

NewPipe app on Android phone - the same codec settings, connected to the same network, the same video and exactly the same problem as in QMPlay2 (4 -5 sec and pause).

I play the video in 2560x1440 size and VP9 codec. When I switch to 1080p, it buffers immediately now.

[RJVB]

I play the video in 2560x1440 size and VP9 codec. When I switch to 1080p, it buffers immediately now.

1080p in MP4 or still VP9? Are there significant differences in the required bandwidth between those? I noticed some hiccups yesterday when watching videos on their site, using an Electron-based app, but that can just as well have been my system. Going fullscreen in that app is clearly painful, for instance. A thought: can this have anything to do with the, erm, missing ads?

[zaps166]

1080p in MP4 or still VP9? Are there significant differences in the required bandwidth between those?

Now still the same issue on the same video:

• VP9 1440p 60 FPS - 4 sec buffer and pause
• VP9 1080p 60 FPS - full video buffers immediately on my network
• VP9 720p 60 FPS - full video buffers immediately on my network
• VP9 720p 30 FPS - 2 sec buffer and pause
• H.264 1440p 60 FPS - 4 sec buffer and pause
• H.264 1080p 60 FPS - 4 sec buffer and pause
• H.264 720p 60 FPS - 4 sec buffer and pause
• H.264 720p 30 FPS - 1 sec buffer and pause

Looks like server bandwidth is limited for most streams, but the reason why it works better on YouTube website is unknown to me.

Best might be 1080p 60 FPS VP9 profile. But I think it depends on video.

A thought: can this have anything to do with the, erm, missing ads?

I don't know, but I'm blocking ads in Firefox and no problems on YouTube website.

[RJVB]

Now still the same issue on the same video:

What video is that? I could check if I get similar streaming performance. With a network like YouTubes we might be streaming off different servers (and certainly via different routes). The only other logical explanation I can think of is related to how content is stored: probably not in all codecs and resolutions, which would mean that streaming performance could be affected by on-the-fly transcoding, which in turn will depend on server load. You would see those effect much less on the website if you let the code figure out the best resolution (AFAIK you can't chose the codec at all). What is odd either way is that the initial buffer that is apparently available is shorter for choices requiring lower bandwidth. Maybe you should have tried 480 too. It's what I often fall back to.

[zaps166]

New tests done right now:

• 480p (VP9 and H264) - this is working properly

It depends also on video position, start of video buffers slowly, when I seek to half of the video, it buffers much faster.

[RJVB]

Where do you select the preferred codec for YouTube, in QMPlay2?? Is that something you can do only for videos that have multiple streams? FWIW, https://www.youtube.com/watch?v=R5tjHCqAFmg buffers just fine or me up to 1080p (its max res I think).

[zaps166]

Where do you select the preferred codec for YouTube, in QMPlay2?? Is that something you can do only for videos that have multiple streams?

It's new feature, git only.

[beew]

So I got yt-dlp and renamed it youtube-dl and place it in ~/.config/QMPlay2, streaming works but the videos are not 360 degree (flat videos), with youtube-dl 360 degree works but stream is throttled. What am I missing?

I am using appimage on Ubuntu 20.04.

P.S yt-dlp does solve the streaming problem for mpv. So the buffering problem is definitely due to youtube-dl not being up to date.

[zaps166]

but the videos are not 360 degree

I don't know, yt-dlp returns an URL to 360 video in different mapping. youtube-dl with my custom user agent returned URL to video with spherical image (this is supported by QMPlay2).

P.S yt-dlp does solve the streaming problem for mpv. So the buffering problem is definitely due to youtube-dl not being up to date.

With yt-dlp is much better, but not for all videos. Youtube throttles it intentionally, so workarounds are needed.