Closed siferati closed 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).
Does it still happen with
--demuxer-max-bytes=4G
? (this will increase the buffer size from 200M to 4G).
Yup, the problem remains.
it only uses ~18Mpbs
What IS the maximum bandwidth you expect?
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.
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?
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.
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...
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).
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?
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).
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.
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:
> sftp user@domain
> get file.mkv
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.
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.
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.
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).
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
--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.
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.
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