merging audio/video causes crippling bandwidth on YouTube streams

[ghost]

Important Information

yt-dlp/youtude-dl streams have slower buffer / bandwidth speeds on reduced resolutions compared to direct stdin piping.

Provide following Information:

• mpv version

$[~]$ mpv --version
mpv 0.34.1-dirty Copyright © 2000-2021 mpv/MPlayer/mplayer2 projects
 built on UNKNOWN
FFmpeg library versions:
   libavutil       57.17.100 (runtime 57.28.100)
   libavcodec      59.18.100 (runtime 59.37.100)
   libavformat     59.16.100 (runtime 59.27.100)
   libswscale      6.4.100 (runtime 6.7.100)
   libavfilter     8.24.100 (runtime 8.44.100)
   libswresample   4.3.100 (runtime 4.7.100)
FFmpeg version: n5.1.2

• Platform and Version
  Linux arch 5.19.13-zen1-1-zen #1 ZEN SMP PREEMPT_DYNAMIC
• Source of the mpv binary
  https://archlinux.org/packages/community/x86_64/mpv/

If you're not using git master or the latest release, update.
Releases are listed here: https://github.com/mpv-player/mpv/releases

Reproduction steps

---

Try to reproduce your issue with --no-config first. If it isn't reproducible
with --no-config try to first find out which option or script causes your issue.

Describe the reproduction steps as precise as possible. It's very likely that
the bug you experience wasn't reproduced by the developer because the workflow
differs from your own.

---

Testing the popular example Costa Rica by Jacob + Katie Schwarz
Tried scenarios:
mpv 'https://www.youtube.com/watch?v=LXb3EKWsInQ' or
mpv --ytdl-format=bestaudio+bestvideo/best 'https://www.youtube.com/watch?v=LXb3EKWsInQ' or
mpv --ytdl-format=337 'https://www.youtube.com/watch?v=LXb3EKWsInQ'
Network downspeed: 50 mbps (ISP max speed utilized) at --ytdl-format=337 (4k 60fps, vp9.2) / 315 (4k 60fps, vp9)

Now the network downspeed results with different stream-id's :
--ytdl-format=336 : 34 mbps (1440p 60fps, vp9.2)
--ytdl-format=308 : 21 mbps (1440p 60fps, vp9)
--ytdl-format=335 : 14 mbps (1080p 60fps, vp9.2)
--ytdl-format=699 : 11 mbps (1080p 60fps, av01.0.09M.10)
--ytdl-format=303 : 7 mbps (1080p 60fps, vp9)
... & so on. Basically downspeed decreases gradually on lower quality streams. Same issue when audio combined (336+251, 308+251), & so on.

Tested direct stream download links too (youtube-dl has -g option that provides direct download links)
mpv $(yt-dlp -g -f 308 'https://www.youtube.com/watch?v=LXb3EKWsInQ')
Network downspeed: 21 mbps (same as above test cases)
Same issue with audio combined in this case.

TEMPORARY RESOLUTION (stdin piping) :
Direct downloading from yt-dlp has no downspeed issues. So I piped the output directly to mpv & had max downspeed bandwidth without any buffer restrictions.
yt-dlp -f <336/308/335/699/303... & so on> 'https://www.youtube.com/watch?v=LXb3EKWsInQ' -o - | mpv -
Network downspeed: 50 mbps (ISP max speed utilized)

Now here comes the tricky issue.
Only video streams have been tested. Combining them with audio brings the same exact issue again.
yt-dlp -f 308+251 'https://www.youtube.com/watch?v=LXb3EKWsInQ' -o - | mpv -
Network downspeed: 21 mbps (same as above test cases)
Concat streaming through audio somehow borks streaming bandwidth down. There's being some weird issue with -f or --ytdl-format options in this regard.
One possible workaround I had, is to pipe both streams separated into mpv
mpv --audio-file=<(yt-dlp -f 251 https://www.youtube.com/watch?v=LXb3EKWsInQ -o -) <(yt-dlp -f 336/308/335 https://www.youtube.com/watch?v=LXb3EKWsInQ -o -)
Network downspeed: 50 mbps (ISP max speed utilized)
Issue with this workaround is that seeking is not possible with stdin piping case.

Expected behavior

mpv should stream youtube-dl/yt-dlp (<= 1080p) streams with the same speed as they provide on downloads.

Actual behavior

Instead, mpv cripples bandwidth when lowering stream quality.
I've came into a conclusion that there are no issues with neither youtube's servers, nor youtube-dl / yt-dlp projects. Both are working fine. It's the mpv's bug that causes these streaming speed drops.

Log file

https://0x0.st/ovJL.log

[guidocella]

#8655 (comment)

[ghost]

#8655 (comment)

YouTube doesn't. If you read my tests closely, the bandwidth from YouTube is perfect. Piping video & audio streams separately gives unlimited downspeed.

The fact is that YouTube itself works based on separated streams (except 360p & 720p)
Also, yt-dlp download speed is as fast as YouTube. Because when you look into the output files, it downloads them separately & merges together.

But MPV's way of handling streams is way fishy. It's trying to play them together synchronously.
It's the synchronous AV playback that makes the bandwidth drops.

Try
yt-dlp -f 251 'https://www.youtube.com/watch?v=LXb3EKWsInQ' -o $XDG_RUNTIME_DIR/ytaudio | yt-dlp -f 308 'https://www.youtube.com/watch?v=LXb3EKWsInQ' -o - | mpv --audio-file="$XDG_RUNTIME_DIR/ytaudio" -
& you never get the drops at all. All streams tested.

[christoph-heinrich]

YouTube doesn't. If you read my tests closely, the bandwidth from YouTube is perfect. Piping video & audio streams separately gives unlimited downspeed.

Please actually read the linked comment, it explains what's going on here.

YouTube throttles based on the bitrate of the stream, that's why you get slower download speeds at lower resolution.
You get faster download speeds with yt-dlp because it has a workaround for the throttling.

[ghost]

It's the synchronous AV playback that makes the bandwidth drops.

Please actually read the linked comment, it explains what's going on here.

YouTube throttles based on the bit rate of the stream, that's why you get slower download speeds at lower resolution. You get faster download speeds with yt-dlp because it has a workaround for the throttling.

That's not the case.
Try my commands. All streams work perfectly at all resolutions with your full ISP speed. You just need to separate audio from your playback & re-concatenate yourself.

The lower the resolution you request the more you are throttled, so lowering the resolution doesn't let you download faster

This statement is not true, if you test both streams separately.

[christoph-heinrich]

That's not the case. Try my commands. All streams work perfectly at all resolutions with your full ISP speed. You just need to separate audio from your playback & re-concatenate yourself.

Oh yeah?

Now the network downspeed results with different stream-id's :
--ytdl-format=336 : 34 mbps (1440p 60fps, vp9.2)
--ytdl-format=308 : 21 mbps (1440p 60fps, vp9)
--ytdl-format=335 : 14 mbps (1080p 60fps, vp9.2)
--ytdl-format=699 : 11 mbps (1080p 60fps, av01.0.09M.10)
--ytdl-format=303 : 7 mbps (1080p 60fps, vp9)

Sure looks to me like your download speed is also decreasing when you only download the video stream without audio.

The only weird thing I see is that yt-dlp -f 308+251 'https://www.youtube.com/watch?v=LXb3EKWsInQ' -o - | mpv - also shows reduced download speed even though it should be downloaded through yt-dlp, but that seems more like a problem on the yt-dlp side then in mpv.

I currently can't test it myself, but I'll give it a try later.

[ghost]

Sure looks to me like your download speed is also decreasing when you only download the video stream without audio.

That's failure case. Read the "Temporary Resolution" part that I've wrote after that.

also shows reduced download speed even though it should be downloaded through yt-dlp, but that seems more like a problem on the yt-dlp side then in mpv.

Nop. It's actually faster, caz yt-dlp downloads them separately & merges streams later. It's the issue in playback.
I need clarification for this :
yt-dlp -f 303 'https://www.youtube.com/watch?v=LXb3EKWsInQ'
Network bandwidth : Max ISP speed
mpv --ytdl-format=303 'https://www.youtube.com/watch?v=LXb3EKWsInQ'
Network bandwidth : 7 mbps
Why is this the case then ?
There's something going on behind --ytdl-format option & mpv's stream pickup from yt-dlp ingeneral.

303 is 1080p 60fps. This, & 137 (1080p 30fps) are the most common streams of YouTube, that also affected by this.

My analogy is that direct download of streams doesn't support seeking, which is the reason mpv utilizes some form of workaround that allows seeking which kinda defeats the faster bandwidths.

[christoph-heinrich]

I need clarification for this :
yt-dlp -f 303 'https://www.youtube.com/watch?v=LXb3EKWsInQ'
Network bandwidth : Max ISP speed
mpv --ytdl-format=303 'https://www.youtube.com/watch?v=LXb3EKWsInQ'

This is because of the throttling from YouTube, as explained in the linked comment. yt-dlp has a workaround, mpv does not.

[ghost]

Although I'm quite not sure it's a workaround. The direct links are fast enough even inside a browser. Afaik, there's no youtube-dl parameters in the url.
https://rr4---sn-5jucgv5qc5oq-itqy.googlevideo.com/videoplayback?expire=1665778750&ei=3m9JY4LoBpTNpgeesY2oBg&ip=<ip-addr>&id=o-AJyWKXSWXt2oAzy27CiyD7HxXH1ZLwvET_ipxg4I_g8l&itag=303&source=youtube&requiressl=yes&mh=df&mm=31%2C26&mn=sn-5jucgv5qc5oq-itqy%2Csn-cvh7knzz&ms=au%2Conr&mv=m&mvi=4&pl=22&initcwndbps=1186250&spc=yR2vp5SBO9Drh98Ib2qidwbzUcvpfsc&vprv=1&svpuc=1&mime=video%2Fwebm&gir=yes&clen=52730817&dur=657.550&lmt=1665690334965473&mt=1665756811&fvip=1&keepalive=yes&fexp=24001373%2C24007246&c=ANDROID&txp=5437434&sparams=expire%2Cei%2Cip%2Cid%2Citag%2Csource%2Crequiressl%2Cspc%2Cvprv%2Csvpuc%2Cmime%2Cgir%2Cclen%2Cdur%2Clmt&sig=AOq0QJ8wRgIhAIg_uohbqteH5fKrxq3kTXsVPxHiD9I4PRk0192dtsCIAiEAgWKYhyyknzqOfBhSjWEdMIfWhdoxpYBv0XDz3TbsYvY%3D&lsparams=mh%2Cmm%2Cmn%2Cms%2Cmv%2Cmvi%2Cpl%2Cinitcwndbps&lsig=AG3C_xAwRgIhAOYeinWl9Ml_c-2WD2ooDmSSpLJ7djOqRvPTzIXGHFO4AiEA7cRx2Lxyiy_ZVMYHly8ri4ggdf5RKrXUH040rRXwWTg%3D
Youtube-dl injects nothing in it. It's just straight up google generated session link. I don't think there's throttle anywhere (which is why piping individual streams are faster).
Just try generating direct link using yt-dlp -f bestvideo -g <yt link> & use it in browser.

As you suggested me to check the linked comment

You can let yt-dlp do the downloading with yt-dlp -o - https://... | mpv -, but this breaks seeking to timestamps that haven't been cached yet, and doesn't set the media title, the chapter list or subtitles.

I think this is where mpv's doing something to retrieve those metadata as well as leaving up some bandwidth away because of some workaround mpv did.

Personally I would prefer piping over full metadata retrieval, because I constantly hit +10 forward in my daily content consumption. Seeking might be affected, but it wouldn't matter as I watch the whole stream anyways.

[guidocella]

The range headers are what makes yt-dlp faster. You can easily see it by making HTTP requests directly:

curl -r 0-10000000 -o /dev/null $(yt-dlp -gf 'bestvideo[height=1080]' https://www.youtube.com/watch?v=LXb3EKWsInQ)

90MB/s on a VPS

curl -r 0-12000000 -o /dev/null $(yt-dlp -gf 'bestvideo[height=1080]' https://www.youtube.com/watch?v=LXb3EKWsInQ)

1.6MB/s

And mpv doesn't have any network code, it's ffmpeg that downloads streams, and it doesn't support downloading in chunks like yt-dlp yet.

yt-dlp -f 251 'https://www.youtube.com/watch?v=LXb3EKWsInQ' -o $XDG_RUNTIME_DIR/ytaudio | yt-dlp -f 308 'https://www.youtube.com/watch?v=LXb3EKWsInQ' -o - | mpv --audio-file="$XDG_RUNTIME_DIR/ytaudio" -

Why are you piping the output of the first yt-dlp command if it downloads to a file?

[ghost]

Why are you piping the output of the first yt-dlp command if it downloads to a file?

Just to get separated audio stream & use it with piped "video only". Do you know how to pipe audio too in conjunction with video, instead of downloading right away ? I think that command can be shortened a little more.

And mpv doesn't have any network code, it's ffmpeg that downloads streams

FFmpeg might be getting stream links, but the direct links from yt-dlp -f bestvideo -g <yt link> in browser actually have blazing fast playback (including seeking).
Checked bandwidth too. A direct link of a 1080p stream on browser, pulls it at 32 mbps, meanwhile MPV pulls it at 2 mbps. A browser is also sort of a video player right...

The range headers are what makes yt-dlp faster. You can easily see it by making HTTP requests directly:
curl -r 0-10000000 -o /dev/null $(yt-dlp -gf 'bestvideo[height=1080]' https://www.youtube.com/watch?v=LXb3EKWsInQ)
90MB/s on a VPS
curl -r 0-12000000 -o /dev/null $(yt-dlp -gf 'bestvideo[height=1080]' https://www.youtube.com/watch?v=LXb3EKWsInQ)

That's strange. Both headers have same faster speeds here (38 mbps). And why VPS btw ? Any important role of it in playback ?

[guidocella]

Just to get separated audio stream & use it with piped "video only".

Why would that require piping the first command? Why not use yt-dlp -f 251 'https://www.youtube.com/watch?v=LXb3EKWsInQ' -o $XDG_RUNTIME_DIR/ytaudio; yt-dlp -f 308 'https://www.youtube.com/watch?v=LXb3EKWsInQ' -o - | mpv --audio-file="$XDG_RUNTIME_DIR/ytaudio" -?

Do you know how to pipe audio too in conjunction with video, instead of downloading right away ?

yt-dlp -f 308 'https://www.youtube.com/watch?v=LXb3EKWsInQ' -o - | mpv --audio-file=<(yt-dlp -f 251 'https://www.youtube.com/watch?v=LXb3EKWsInQ' -o -) -

FFmpeg might be getting stream links, but the direct links from yt-dlp -f bestvideo -g in browser actually have blazing fast playback (including seeking).
Checked bandwidth too. A direct link of a 1080p stream on browser, pulls it at 32 mbps, meanwhile MPV pulls it at 2 mbps. A browser is also sort of a video player right...

To have fast download speed with mpv and 1080p+ youtube videos someone needs to implement downloading in chunks in ffmpeg. That is already known.
I don't know about the download speed in browsers because my internet connection is slow to notice a difference, but if I play yt-dlp -gf bestvideo https://www.youtube.com/watch?v=LXb3EKWsInQ in a browser and copy as curl from the devtools and run it in a VPS I just get 7MB/s.

And why VPS btw ?

Just so I can test with a faster connection.

[ghost]

yt-dlp -f 308 'https://www.youtube.com/watch?v=LXb3EKWsInQ' -o - | mpv --audio-file=<(yt-dlp -f 251 'https://www.youtube.com/watch?v=LXb3EKWsInQ' -o -) -

Tq. I'm just learning bash scripting & few gnu tools, so I'm kinda newbie in this case.

I just get 7MB/s.

Hold on. That mega bytes right? (which is faster caz do x8 for bits). I've just expressed it as bits before. Bits for Internet & bytes for storage.

[guidocella]

Hold on. That mega bytes right? (which is faster caz do x8 for bits). I've just expressed it as bits before. Bits for Internet & bytes for storage.

Yes, curl shows the megabytes.

[ghost]

I do have resource monitor in my status bar showing megabits/sec, so it's cleaner.
I wanna know how browser is able to play with ease, whereas mpv struggle in this sense. Chromium/Firefox are ofcourse open source, so might be viable to lookup into their sources what making them play faster.

[paulguy]

Most of my issues with buffering with ytdl in mpv is when the beginning of a video has a higher ABR than the overall ABR, which is common because a lot of videos will have more going on during an intro than the rest of the video overall. I don't know what causes this but it can often be bad enough that it requires downloading the entire video then watching it, which isn't a huge deal, but it would be nice if it wasn't broken in that way. I dunno if this is related to the issue here or not.

[ghost]

Hmm. You sure it's a bitrate issue? Caz I don't think that's the case. As resolutions scale down, bitrates of the streams would also. So you should technically get even faster buffers as of your ISP speeds.

To have fast download speed with mpv and 1080p+ youtube videos someone needs to implement downloading in chunks in ffmpeg.

1080p+ streams have higher bitrates so their speeds are naturally scaling in the increased order. There must be some fetching issues in the codebase itself. Caz that's not how direct streams behave under browser right.

I think it comes down to DRM issue. Browsers allow DRM playback, but MPV is a local media player so it doesn't (& just relies on partially buffered streams through https).

[guidocella]

Hmm. You sure it's a bitrate issue? Caz I don't think that's the case. As resolutions scale down, bitrates of the streams would also. So you should technically get even faster buffers as of your ISP speeds.

They download slower because youtube chose to the throttle them like that.

1080p+ streams have higher bitrates so their speeds are naturally scaling in the increased order. There must be some fetching issues in the codebase itself. Caz that's not how direct streams behave under browser right.

There is no fetching issue in ffmpeg because you can reproduce the same throttling with curl or wget as long as you don't set a < 10MB range, while you can avoid the throttling with aria2 which lets you download in chunks. We already tested this on #mpv many months ago. Why else would yt-dlp have implemented the http-chunk-size?

I think it comes down to DRM issue. Browsers allow DRM playback, but MPV is a local media player so it doesn't (& just relies on partially buffered streams through https).

Youtube videos don't have DRM, or they wouldn't play at all.

[ghost]

Youtube videos don't have DRM, or they wouldn't play at all.

I thought that might be the case, although it doesn't have DRM. Because browsers support it. I thought that hiding direct stream links of YouTube is some sort of DRM policy. I'm wrong though.

We already tested this on #mpv many months ago. Why else would yt-dlp have implemented the http-chunk-size?

That's great btw. So if aria2 chunk playback is tested already ?

[guidocella]

That's great btw. So if aria2 chunk playback is tested already ?

I meant using aria2 from the command line. It doesn't have mpv integration. yt-dlp --downloader aria2c is fast while yt-dlp --downloader curl/ffmpeg is slow, because yt-dlp calls aria2c -x16 -j16 -s16, which is meant to let you download parts of a single url in parallel, but this also happens to bypass the throttling.

Also it's worth noticing that on my previous curl example it was a 100MB range that toggled the throttling, so it may increase with the video resolution. Still that doesn't change that implementing the chunking in ffmpeg is what's needed to increase the download speed.

[stumpedatwork]

I believe YouTube bandwidth throttling and seeking to be two different issues.

I have a proxy server script that breaks up a large HTTP request into multiple small HTTP requests and it greatly speeds up my YouTube speed with mpv.

However, I find I still have issues with seeking.

Say when I am watching a a YouTube video that has separated video and audio streams. When I try to seek, mpv will disconnect one of the streams from my proxy server and reconnect it with its new range. Video playing will stalls when this happens. Only after some quite noticeable delay, will mpv disconnect the other stream from my proxy server and reconnect it with its new range. Video playing finally resumes.

Update: I found a bug in my script and fixing it fixed the AV sync issue I had. Everything works quite nicely with mpv+YouTube now

[ghost]

When I try to seek, mpv will disconnect one of the streams from my proxy server and reconnect it with its new range. Video playing will stalls when this happens.

This exact thing also happens when I pipe stream both audio & video separately. It's more of an av sync issue than the throttling itself.

[Roliga]

I have a proxy server script that breaks up a large HTTP request into multiple small HTTP requests and it greatly speeds up my YouTube speed with mpv.

@stumpedatwork could you share some details on how you set up this proxy?

[stumpedatwork]

@Roliga I have a mitmproxy addon that redirects googlevideo.com urls to a nodejs web server script that does the actual work of breaking up requests. So you basically ends up running two servers. Breaking up HTTP requests is just messing around with the range and content-range http headers.

[CrossRoast]

I tried dynamically updating the http-header-fields and stream-lavf-o options with a lua script, but it seems that only the intial value for the option is used, even if the connection times out. Would it be possible to make mpv use the updated http-header-fields/stream-lavf-o?

youtube-cache.txt

[GunGunGun]

I believe YouTube bandwidth throttling and seeking to be two different issues.

I have a proxy server script that breaks up a large HTTP request into multiple small HTTP requests and it greatly speeds up my YouTube speed with mpv.

However, I find I still have issues with seeking.

Say when I am watching a a YouTube video that has separated video and audio streams. When I try to seek, mpv will disconnect one of the streams from my proxy server and reconnect it with its new range. Video playing will stalls when this happens. Only after some quite noticeable delay, will mpv disconnect the other stream from my proxy server and reconnect it with its new range. Video playing finally resumes.

Update: I found a bug in my script and fixing it fixed the AV sync issue I had. Everything works quite nicely with mpv+YouTube now

Hi, can you share your proxy script, it'll help a lot of users who are struggling with Youtube throttle ?

Thanks!

[gunir]

I believe YouTube bandwidth throttling and seeking to be two different issues.

I have a proxy server script that breaks up a large HTTP request into multiple small HTTP requests and it greatly speeds up my YouTube speed with mpv.

However, I find I still have issues with seeking.

Say when I am watching a a YouTube video that has separated video and audio streams. When I try to seek, mpv will disconnect one of the streams from my proxy server and reconnect it with its new range. Video playing will stalls when this happens. Only after some quite noticeable delay, will mpv disconnect the other stream from my proxy server and reconnect it with its new range. Video playing finally resumes.

Update: I found a bug in my script and fixing it fixed the AV sync issue I had. Everything works quite nicely with mpv+YouTube now

Hello, can you share your NodeJS fetch script ? Thanks!

[memories169]

I believe YouTube bandwidth throttling and seeking to be two different issues.

I have a proxy server script that breaks up a large HTTP request into multiple small HTTP requests and it greatly speeds up my YouTube speed with mpv.

However, I find I still have issues with seeking.

Say when I am watching a a YouTube video that has separated video and audio streams. When I try to seek, mpv will disconnect one of the streams from my proxy server and reconnect it with its new range. Video playing will stalls when this happens. Only after some quite noticeable delay, will mpv disconnect the other stream from my proxy server and reconnect it with its new range. Video playing finally resumes.

Update: I found a bug in my script and fixing it fixed the AV sync issue I had. Everything works quite nicely with mpv+YouTube now

Can you share the script?