If it's specifically on youtube links and some others, see #5806 and ytdl-org/youtube-dl#11476

If it's specifically on youtube links and some others, see #5806 and ytdl-org/youtube-dl#11476

The problem is youtube ,cr , viki.com etc... everything I tried has the same problem?

That's because those all use youtube-dl because they are not direct links?

That's because those all use youtube-dl because they are not direct links?

The problem is not youtube-dl it is with mpv!
Downloading separate with youtube-dl URL
I get 10MiB/s-12MiB/s but with mpv it is stuck with 600KiB-900KiB?

This is neither a youtube-dl nor an mpv issue.
youtube-dl has a mechanism to bypass bandwidth throttling, mpv (as in FFmpeg) doesn't.

If you use download through the same URL in FFmpeg as in mpv and FFmpeg is also throttled, the problem/feature request belongs in FFmpeg, not mpv, as already explained in the links I mentioned.

This is neither a youtube-dl nor an mpv issue.
youtube-dl has a mechanism to bypass bandwidth throttling, mpv (as in FFmpeg) doesn't.

I did a little research myself

ytdl-org/youtube-dl#15384 (comment)

https://github.com/yt-dlp/yt-dlp

and I don't know how much correct I am but with aria2 the download speed can be increased if I'm right with
--external-downloader aria2c --external-downloader-args:aria2c "-x 16 -s 16 -k 1M"

So if Im right?
How can make mpv use aria2?
And also how can I use the command above with mpv?
Do you maybe know? İs it with ytdl-raw-options= ?

Edit:

Would something like this work in the mpv.conf?
ytdl-raw-options=cookies="/storage/emulated/0/download/cookies.txt",external-downloader=aria2,external-downloader-args:aria2c="-x 16 -s 16 -k 1M"

you can't use an external downloaded with our youtube-dl lua script. youtube-dl returns an url to us and ffmpeg is doing the rest. it never downloads anything on disk.

if you want to use it you have to use youtube-dl on it's own and play the resulting file on the disk with mpv or pipe it to mpv.

you can't use an external downloaded with our youtube-dl lua script. youtube-dl returns an url to us and ffmpeg is doing the rest. it never downloads anything on disk.

if you want to use it you have to use youtube-dl on it's own and play the resulting file on the disk with mpv or pipe it to mpv.

İt would be great if mpv could use aria2c for sites like CR and viki.com since yt-dl does send ffmpeg to download and speed is really slow!

Could I make request like this? İs it possible?

i am not sure if this is something we want in our youtube-dl script. though that's not up to me.

like mentioned before and the other issues, this is something ffmpeg should add.

i am not sure if this is something we want in our youtube-dl script. though that's not up to me.

like mentioned before and the other issues, this is something ffmpeg should add.

I want to say all the things below for it just to be only idea or request. I hope that this maybe will happen someday.

I thank you for your help and understand it not only for you to decide but
I did look at the other issues dates saw that it is being more than 3-4 years and it looks like ffmpeg isn't doing anything about it☹️. so I thought it would be great actually if there was tentative solution with aria2c for now?
Cuz
Copy and paste url to mpv is more convient than separately downloading the file with yt-dl ffmpeg which download speed is slow.

There is this yt-dlc fork yt-dlp that does support aria2c as the external downloader for DASH(mpd) and HLS(m3u8) formats.
İt would be great if this was used for cr and viki.com for streaming directly with mpv.
This is what I was thinking and want to share it here.

https://github.com/yt-dlp/yt-dlp

youtube-dl literally has the same aria2c support. Those forks of it obviously have it too.
It still doesn't have anything to do with mpv.

It's also possible that mpv fills the cache quickly, and then it keeps downloading at a rate which matches the playback speed.

To test: play with --speed=2 and observe whether the speed stabilizes on twice than with normal speed.

To increase the cache, for instance to 1G (the default is 150M forward), use --demuxer-max-bytes=1G .

youtube-dl literally has the same aria2c support. Those forks of it obviously have it too.

But when I try to download CR with youtube-dl it isn't using aria2c it uses ffmpeg?

Are you sure that youtube-dl does support aria2c as the external downloader for DASH(mpd) and HLS(m3u8) formats?

yt-dlp does indeed advertise having support for DASH and HLS downloads using an external, multi-threaded client like aria2c. But that's not the point of your initial question, which was most likely correctly answered by avih right above.

It's also possible that mpv fills the cache quickly, and then it keeps downloading at a rate which matches the playback speed.

To test: play with --speed=2 and observe whether the speed stabilizes on twice than with normal speed.

To increase the cache, for instance to 1G (the default is 150M forward), use --demuxer-max-bytes=1G .

This only work in the beginning later it goes down to slow speed again but thanks.

This issue reads like trying to walkthrough my mom in sending a WhatsApp text message: it goes nowhere.

This issue reads like trying to walkthrough my mom in sending a WhatsApp text message: it goes nowhere.

Sorry for my bad English I probably couldn't explained right.

@erickyun's solution with yt-dlp worked great for me, thank you!

@garoto if you could take some time from coming up with snarky zingers, you'd realize that the issue that actual users are having is that YouTube playback with MPV is unusable. To that end, @erickyun's solution works fine, unless the point is to strictly and pedantically adhere to "the point of the initial question", which, even then, I'm sure @erickyun is more qualified to speak on, as he was the one who asked the question.

Hi all!

Just want to share I have the same problem, can't play a youtube video with mpv. It's buffering all the time :/

I was googling around and ended up in youtube-viewer (https://github.com/trizen/youtube-viewer). I tested it and I can play a 1080p video without problems, so it's not a problem of my laptop or internet connection.

Writing this so that people are aware the problem is ongoing.

It's buffering all the time

#8779 (comment)

TL;DR: use yt-dlp instead of youtube-dl.

Hello,

After reading this thread, i want to do a summary, to check if i understand things correctly:

• mpv uses ytdl (or any of its forks) just to get the video url
• mpv uses ffmpeg to download/stream the videos (from youtube, or other video platforms) and not ytdl
• ffmpeg has issues with slow downloads/buffering of youtube videos
• yt-dlp has (mostly? well, completely for me) solved the issue with youtube throttling/buffering, which yt-dl has not (at the time of writing at least)
• ffmpeg has not implemented the same fixes that yt-dlp has implemented to assure fast downloads from youtube

Is my understanding correct?

In order to not have issues with buffering, we were suggested to 1. download a video fully using yt-dlp, 2. open that video file in mpv 3. watch without buffering.

My next question is: is there a possibility to instruct mpv to download via yt-dlp directly, and not via ffmpeg, and somehow pass the "download in progress" video stream from yt-dlp to ffmpeg or to mpv to do the rest of the processing? Basically, what i'm saying is: can we sidestep ffmpeg from downloading the video and leave this task to yt-dlp instead?

For the record, i have 1 GBps up and down, and when i download with yt-dlp (.\yt-dlp.exe https://youtu.be/CJbP71RI-V4 - no extra config), i get 100-150Mbps, while when i look at the same video in mpv (.\mpvnet.com https://youtu.be/CJbP71RI-V4) i get ~500kbps, as viewed by pressing t + 3 in the mpv window.

Youtube now throttles requests of more than 10MB at a time, yt-dlp works around it by making many requests of 10MB using Range HTTP headers (yt-dlp calls it the http-chunk-size), but ffmpeg which does the downloading for mpv doesn't support that yet.

Selecting HLS streams with --ytdl-format='bestvideo[protocol^=m3u8]+bestaudio[protocol^=m3u8]/bestvideo+bestaudio/best' reduces the throttling, but it breaks seeking to timestamps that haven't been cached in >= 1440p streams, and doesn't select 4320p streams.

You can also let yt-dlp do the downloading by piping its standard output to mpv, e.g. with this zsh script:

yt-dlp --get-title --get-url $1 | IFS=$'\n' read -d '' title video audio
mpv --force-media-title=$title --audio-file=<(yt-dlp --http-chunk-size 10M -o - $audio) <(yt-dlp --http-chunk-size 10M -o - $video)

But this breaks seeking to timestamps that haven't been cached yet, and doesn't set the chapter list or subtitles.

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

You can also try the files with contain both video and audio which are throttled less

Thank you for this advice. I always watched 720p60 with ~600kB speed. But after switching to 720p30 stream that contains both video and audio the speed is now ~5mB (max speed of my wifi connection)

Try this to unlock full ISP speeds
yt-dlp -f 251 'video-link' -o $XDG_RUNTIME_DIR/ytaudio | yt-dlp -f bestvideo 'video-link' -o - | mpv --audio-file="$XDG_RUNTIME_DIR/ytaudio" -
Although seeking would be an issue (I donno why).

Thanks! My old options were ytdl-format=bestvideo[height<=?720][fps<=?30][vcodec!=?vp9]+bestaudio/best I relied on this comment. I guess bestvideo+bestaudio/best was the problem.

Just a small update for the script by @pc00per

#!/bin/bash
yt-dlp -N 8 --no-part -f "bestaudio" "$1" -o /tmp/ytaudio | yt-dlp -f "bestvideo" "$1" -o - | mpv --audio-file="/tmp/ytaudio" -
rm -rf /tmp/ytaudio

No seeking or chapters but it utilizes the network max speed.

@piyushgarg btw I bash aliased all those commands

pp='fun(){
	rm $XDG_RUNTIME_DIR/yta >/dev/null
	yt-dlp -N $(nproc) --no-part -f "wa[acodec~=opus]/ba" $@ -o $XDG_RUNTIME_DIR/yta
	yt-dlp -f bv $@ -o - |\
	mpv --audio-file=$XDG_RUNTIME_DIR/yta -
	}; fun'

pp 'link'
I used worst audio for least initial waiting time. And it's opus, so the audio quality is very transparent & close to the source even with 54 kbps.

Try this to unlock full ISP speeds

Is it possible to use it in mpv.conf for playing youtube videos? I watch some videos at speed x4.

Really hope ffmpeg is updated to support this eventually.

#12254
I have a problem not only with youtube, but also with other video services.
Download and launch is not applicable to streaming and live broadcasts.
Why can't caching be hung on yt-dlp or make its own layer for that before ffmpeg?
Does the ffmpeg upstream know about the problem?

I realize that this sounds definitely not like an ffmpeg problem, since ffmpeg's job is encoding and decoding, not splitting requests into pieces to bypass video service limitations.
Maybe there is a layer in ffmpeg to take over the downloading, leaving ffmpeg only decoding?

That's such a crutch...

u="video_url" && n="`yt-dlp -Otitle $u`" && f="/tmp/$n" && yt-dlp --max-filesize 1.8G --sub-langs 'en,ru' --embed-subs --embed-chapters --no-part -f'bestvideo[height<=1080][fps<=?60][vcodec^=?avc]+bestaudio/best[height<=1080][fps<=?60][vcodec^=?avc]' -o"$f" "$u" && mpv --slang=ru "$f"* && rm "$f"*

But in any case for streaming broadcasts neither this option nor the option with separate audio stream loading is not suitable and mpv should load via yt-dlp instead of ffmpeg itself by default!

FFmpeg feature request: https://trac.ffmpeg.org/ticket/10381

Made a simple program to act as a proxy and modify Range header before it gets to ffmpeg: https://gist.github.com/ftk/253347b2c9a53bbd6087f086970106b6
There are some issues with the way I launch the proxy from lua script but overall youtube works very fast now. Been using it for an year or so.

Is it really true that this has to be implemented in ffmpeg?
There are already a start_offset and end_offset libavformat options, you can try them out with eg. mpv --stream-lavf-o=end_offset=10485760 and they change the Range header as in @ftk script.

For the first request you just set end_offset=chunk_size, then on seeking or when the chunk is fully consumed, recompute the offsets as start_offset=current_bytes; end_offset=current_bytes + chunk_size and make another request.

Is it really true that this has to be implemented in ffmpeg? There are already a start_offset and end_offset libavformat options, you can try them out with eg. mpv --stream-lavf-o=end_offset=10485760 and they change the Range header as in @ftk script.

For the first request you just set end_offset=chunk_size, then on seeking or when the chunk is fully consumed, recompute the offsets as start_offset=current_bytes; end_offset=current_bytes + chunk_size and make another request.

I tried --stream-lavf-o=end_offset=10485760 and it does significantly improve the loading speed, however the video won't load beyond a couple of minutes. I'm assuming this is because it has reached the end_offset.

How would you detect the chunks in an mpv script? If that was possible I assume the offsets could be updated with set-property

FFmpeg feature request: https://trac.ffmpeg.org/ticket/10381

I'm not holding my breath as ffmpeg is very slow to evolve nowadays, could takes another century not even joking.

Honestly we would rather do our own implement instead.

Made a simple program to act as a proxy and modify Range header before it gets to ffmpeg: https://gist.github.com/ftk/253347b2c9a53bbd6087f086970106b6 There are some issues with the way I launch the proxy from lua script but overall youtube works very fast now. Been using it for an year or so.

This is the best solution honestly, I take this over ffmpeg unforesee fixes any day. Thanks for sharing!

FFmpeg feature request: https://trac.ffmpeg.org/ticket/10381

I'm not holding my breath as ffmpeg is very slow to evolve nowadays, could takes another century not even joking.

Honestly we would rather do our own implement instead.

Ok coomer.

How would you detect the chunks in an mpv script? If that was possible I assume the offsets could be updated with set-property

I don't know how to do this in mpv, but ffmpeg already exposes everything you need to implement ranged requests, so in principle it's possible. It would be of help if any mpv developers could comment on this.

FFmpeg feature request: https://trac.ffmpeg.org/ticket/10381

13 months passed, no response.

I would love to believe or even believe in ffmpeg.

How would you detect the chunks in an mpv script? If that was possible I assume the offsets could be updated with set-property

I don't know how to do this in mpv, but ffmpeg already exposes everything you need to implement ranged requests, so in principle it's possible. It would be of help if any mpv developers could comment on this.

I'm not sure if it's possible with lua ? Because unless you heavily modify mpv's lua capability, it can't send/recv network requests, you have to install LuaRocks' LuaSocket which most users can't, unless mpv decices to make LuaSocket built-in, honestly this ain't a bad idea, like at all who care about small non-existence security issues for people who install script carelessly ?

it can't send/recv network requests, you have to install LuaRocks' LuaSocket which most users can't, unless mpv decices to make LuaSocket built-in, honestly this ain't a bad idea, like at all who care about small non-existence security issues for people who install script carelessly ?

mpv doesn't have to do any network-related operation: as I said, it's enough to set the start_offset and end_offset lavf options from mpv, let ffmpeg download the chunk, play it and when done go to the next chunk. The only complication is computing the offset and dealing with seeking.

it can't send/recv network requests, you have to install LuaRocks' LuaSocket which most users can't, unless mpv decices to make LuaSocket built-in, honestly this ain't a bad idea, like at all who care about small non-existence security issues for people who install script carelessly ?

mpv doesn't have to do any network-related operation: as I said, it's enough to set the start_offset and end_offset lavf options from mpv, let ffmpeg download the chunk, play it and when done go to the next chunk. The only complication is computing the offset and dealing with seeking.

I still don't understand, using loadfile with start_offset and end_offset to download chunk by chunk kinda work, but we're giving up seeking ? Because loadfile will create a whole new file.

Or I misunderstand your idea ? Are we going to write a new feature for mpv or are we going to write a plugin ?

I don't know what loadfile is or whether you can do this from the lua plugin, only in principle I think you can implement splitting the file into chuncks and streaming them using only ffmpeg. Seeking would require computing which chunk you're jumping into and making a new request.
But again, I have no idea how mpv works (don't mind my contributor flair, I only did a minor PR years ago), so that's why I'm asking whether this is feasible.

Made a simple program to act as a proxy and modify Range header before it gets to ffmpeg: https://gist.github.com/ftk/253347b2c9a53bbd6087f086970106b6 There are some issues with the way I launch the proxy from lua script but overall youtube works very fast now. Been using it for an year or so.

Good working solution after many-long-unfortunate googling and ffmpeg/mpv tweaking. This should get more recognition.

Thanks very much for making mpv+yt streaming painless finally.

Хорошее рабочее решение после долгого и неудачного поиска в Google и настройки ffmpeg/mpv. Это должно получить больше признания.

Тоже пришел по такому пути. Как это использовать?