search

mpv-player / mpv

🎥 Command line video player
https://mpv.io
Other
27.74k stars 2.86k forks source link

mpv caps download speed when streaming from sftp server #8961

Closed siferati closed 3 years ago

siferati commented 3 years ago

Important Information

Provide following Information:

Reproduction steps

mpv sftp://user:pass@domain/file.mkv

Expected behavior

Video is streamed from sftp server at max bandwidth capacity.

Actual behavior

Video stream is capped at ~18 Mbps.

Additional Context

If I download the file from the sftp server, the network bandwidth is fully used. But when streaming the file through mpv, it only uses ~18Mpbs. Why is mpv capping the download speed when streaming and how can I fix it?

Log file

output.txt

avih commented 3 years ago

The actual network access is performed by ffmpeg, and mpv doesn't try limit the rate (I don't know if ffmpeg has an API for that), however, mpv does have a limited prefetch buffer size, so if that buffer gets filled, then mpv will not request ffmpeg to fetch more (except for the amound equal to discarded old data as playback continues).

Does it still happen with --demuxer-max-bytes=4G ? (this will increase the buffer size from 200M to 4G).

siferati commented 3 years ago

Does it still happen with --demuxer-max-bytes=4G ? (this will increase the buffer size from 200M to 4G).

Yup, the problem remains.

avih commented 3 years ago

it only uses ~18Mpbs

What IS the maximum bandwidth you expect?

siferati commented 3 years ago

What IS the maximum bandwidth you expect?

I'm expecting mpv to stream at whatever speed I get when downloading directly from the sftp server (in this case, around ~50Mbps). It's the same file, being downloaded from the same place, to the same place, by the same protocol. Why wouldn't the download speeds be the same? But streaming through mpv is not even giving me half of the download speed I get when downloading directly from the sftp server.

avih commented 3 years ago

Why wouldn't the download speeds be the same?

Assuming it's not limited by mpv buffers (since you reported that --demuxer-max-bytes=4G didn't help), then It's possible that the sftp protocol implementation used by ffmpeg is limited in some ways. I don't have ideas other than this.

streaming through mpv is not even giving me half of the download speed I get when downloading directly from the sftp server.

Out of curiosity, why does that matter to you? Is playback stuttering? Does mpv pause due to buffering?

siferati commented 3 years ago

Out of curiosity, why does that matter to you? Is playback stuttering? Does mpv pause due to buffering?

Yup, that's exactly my problem -- constant buffering because of the slow streaming speed.

avih commented 3 years ago

Yup, that's exactly my problem -- constant buffering because of the slow streaming speed.

Assuming the file does play without stuttering if you first download it to local storage and then play it locally in mpv (please do confirm that is indeed the case), then it sounds to me like an ffmpeg issue, and I don't think mpv can do anything about it...

siferati commented 3 years ago

Assuming the file does play without stuttering if you first download it to local storage and then play it locally in mpv (please do confirm that is indeed the case), then it sounds to me like an ffmpeg issue, and I don't think mpv can do anything about it...

Yeah that's the case. Also, if I wait a bit before playing in order to give time for the cache to build up then mpv plays fine (until it eventually catches up to the cache).

avih commented 3 years ago

Yeah that's the case. Also, if I wait a bit before playing in order to give time for the cache to build up then mpv plays fine (until it eventually catches up to the cache).

Right, then so far it does sound to me like either an sftp issue in ffmpeg, or a specific file issue which requires ffmpeg to seek to the end of the file before playback can begin (or periodically), or maybe an sftp server issue with seeking to an arbitrary position at the file, or maybe just a combination of the specific file (which needs seeking) and the protocol - not sure if the [s]ftp protocol (or specific server) supports seeking, unlike most http servers for instance.

Also, is the log you attached initially taken where such issues happen? As far as I can tell this log doesn't show buffering or other playback issues.

It does seem to take long to start (11 s), possibly because ffmpeg needs to seek to the end of the file (1.8G) to read some attachment (fonts?), but then until you quit (around 22 s), I don't think I can recognize any playback issues...

Can you try with other players (e.g. vlc) which support sftp? Can you try with an http server (which supports partial download) instead of [s]ftp?

avih commented 3 years ago

Also, where did you get that 18Mbps number from? observing network usage with some network monitor?

And how did you accomplish 50Mbps with the same file on the same ftp server? Is it possible you downloaded it with some program which supports "download acceleration"? (requests different parts of the file in parallel)? If yes, can you limit it to just one part and try again? (ffmpeg doesn't do parallel download).

avih commented 3 years ago

At this stage though, I'm quite convinced the issue is outside the control of mpv, and it's some combination of general network issues and/or specific-file issues and/or sftp server issues and/or ffmpeg sftp issues.

Regardless, it would still be nice to figure out the discrepencies.

siferati commented 3 years ago

Also, is the log you attached initially taken where such issues happen? As far as I can tell this log doesn't show buffering or other playback issues.

The log I attached does have the bandwidth cap, but there is no buffering -- the ~18Mbps are enough to play this specific file. When I tried on a different network the cap was lower than 18Mbps and it buffered a lot, to the point where it was unplayable (even though the direct sftp download was fine). I'll get you a log of that network and the buffering issues later today.

read some attachment (fonts?)

The mkv file does have a lot of font attachments.

Also, where did you get that 18Mbps number from? observing network usage with some network monitor?

I used Windows's built-in Resource Monitor to measure network usage when using mpv and when using sftp.

And how did you accomplish 50Mbps with the same file on the same ftp server?

Using OpenSSH client for Windows 10:

  1. > sftp user@domain
  2. type password
  3. > get file.mkv
avih commented 3 years ago

the ~18Mbps are enough to play this specific file. When I tried on a different network the cap was lower than 18Mbps and it buffered a lot

Is it the same file? With this different network, does downloading outside of mpv still achieves 50Mbps? Please attach a log where the (playback) issues actually happen.

siferati commented 3 years ago

Can you try with other players (e.g. vlc) which support sftp?

I tried with VLC and the problem does not happen -- VLC uses the whole bandwidth unlike mpv.

Is it the same file? With this different network, does downloading outside of mpv still achieves 50Mbps?

Yes and yes.

Please attach a log where the (playback) issues actually happen.

I'll do that in a few hours once I have access to that network.

avih commented 3 years ago

It seems that ffmpeg uses libssh for sftp - https://ffmpeg.org/ffmpeg-protocols.html#libssh

And your build - from shinchiro does build and use libssh - https://github.com/shinchiro/mpv-winbuild-cmake/blob/master/packages/libssh.cmake

So I would say the issue is probably at libssh. It does look like libssh had sftp performance issues - https://bugs.libssh.org/T89 but I don't know if that's still the case currently.

Either way, it looks to be an issue at libssh or between ffmpg and libssh, and definitely outside the control of mpv.

I'll close this issue now, but you can still post further logs or info, and we can re-open it in case it does turn out to be an mpv issue.

garoto commented 3 years ago

My solution to streaming media with mpv and the ssh protocol on Windows is to install sshfs-win and then mount a network share via e.g. net use P: "\\sshfs\root@192.168.1.250", and then mess with --stream-buffer-size= values, because by default the thoughput will be equally as bad as the libssh+ffmpeg implementation, specially with high latency connections (~210ms in my case).

Edit to add that m-ab-s already disabled building ffmpeg with libssh because apparently it cannot be staticaly built anymore. Shinchiro toolkit is still able to do it because for reasons I can't quite fully don't understand, it still builds v0.8.90. I managed to build a shared v0.9.5 libssh and link mpv against it after much tinkering, but speeds were still laughably bad and same as before (~100KB/s).

siferati commented 3 years ago

My solution to streaming media with mpv and the ssh protocol on Windows is to install sshfs-win and then mount a network share via e.g. net use P: "\\sshfs\root@192.168.1.250", and then mess with --stream-buffer-size= values, because by default the thoughput will be equally as bad as the libssh+ffmpeg implementation, specially with high latency connections (~210ms in my case).

That's exactly the situation I'm in, trying to stream something halfway across the globe. I tried following your approach of using sshfs-win but the results are still bad. What values are you using for stream-buffer-size?

I measured the speeds today and I managed to download the file from the SFTP server at 4\~5 Mb/s -- let's assume this is the maximum possible value for the download speed.

When streaming through sshfs-win using the default stream-buffer-size I get around 150\~300 KB/s. By setting stream-buffer-size=2048Kib the speed increased to 600\~700 KB/s, but that's still nowhere near the regular SFTP speed, and not enough for the video to not stutter. I tried to further increase the value but the speed never improved past this point.

Here's the logfile (please excuse all the syncplay garbage logs): output.txt

garoto commented 3 years ago

--stream-buffer-size=14M yields around 7.4MiB/s and that seems to be the cap with the option and with my setup.

By setting stream-buffer-size=2048Kib the speed increased to 600~700 KB/s [...]

For reference, using your --stream-buffer-size=2048Kib value, I get ~3.8MiB/s.

garoto commented 3 years ago

Thought I should add a few more details regarding what I know about stream-buffer-size and sshd:

The option stream-buffer-size was concocted by wm4 as result of this issue being raised https://github.com/mpv-player/mpv/issues/6802. I highly recommend you to read it fully, potential good knowledge to be found there, including tweaks to be made to sshfs-win fuse backend.

sshd is notorously intolerant of high-latency connections as far as bandwidth usage goes. I've being investigating this subject for some ~13yrs already, and I recall using a sshd "experimental" fork which the goal was to tweak the daemon for this purpose circa 2010 or so. So you might want to investigate that if you really need to use any of sshd file transfers facilities, specially on Windows.

Edit: tl;dr: just use plain HTTP or FTP(S) instead lol.