Very slow HTTP fetch on a specific host

[gunir]

Important Information

Provide following Information:

• mpv version

mpv v0.36.0-431-gf40bbfec Copyright © 2000-2023 mpv/MPlayer/mplayer2 projects
 built on Sep 28 2023 04:24:02
libplacebo version: v6.338.0-1-gd322515-dirty
FFmpeg version: N-112203-gb643af4ac
FFmpeg library versions:
   libavutil       58.25.100
   libavcodec      60.27.100
   libavformat     60.13.100
   libswscale      7.3.100
   libavfilter     9.11.100
   libswresample   4.11.100

• Platform and Version Windows 10
• Source of the mpv binary https://github.com/zhongfly/mpv-winbuild/releases

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

• mpv https://web.lotuscdn.vn/2023/10/30/ecb56ab1476e2b5dcd9f04456f9c89b0_1698619279984-4gzz6xob0v.mp4 -v --no-ytdl --no-config --log-file=lotus.txt
• Video loads very slowly and checking mitmproxy log it looks like the MPV keeps using Range request that server refuse to load
• Every single video from this site has the similar issue

Video: https://imgur.com/UOjjP2j

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.

Expected behavior

• Open this link in web browsers
• Load superfast with zero delay

So video should be able to load as fast as in browsers

Actual behavior

Video loads slowly like stoneage

Log file

• --no-config logs: lotus.txt

Make a log file made with -v -v or --log-file=output.txt, paste it to
https://0x0.st/ or attach it to the github issue, and replace this text with a
link to it.

Sample files

Sample files needed to reproduce this issue can be uploaded to https://0x0.st/
or similar sites. (Only needed if the issue cannot be reproduced without it.)
Do not use garbage like "cloud storage", especially not Google Drive.

[gunir]

Additional information:

• It's still possible to watch by saving the video to disk and open it: https://streamable.com/g7ksub
• VLC can't even open the video: https://streamable.com/qcozo9

mpv -v ecb56ab1476e2b5dcd9f04456f9c89b0_1698619279984-4gzz6xob0v.mp4 --no-config --log-file=lotus_offline.txt
--no-config logs: lotus_offline.txt

[Vance-ng-vn]

I have the same issue on Linux and Android

mpv https://web.lotuscdn.vn/2023/10/30/ecb56ab1476e2b5dcd9f04456f9c89b0_1698619279984-4gzz6xob0v.mp4 --no-ytdl --log-file=lotus.txt --no-config
Linux:
lotus.txt

[gunir]

More information, it's possible to open this url in VLC by disabling Hardware Acceleration in Input-Codec:

https://streamable.com/ry6c6x

MPV should be able to handle this url.

[MoSal]

If you pass --msg-level=all=no,ffmpeg=v, you will notice that the stream keeps seeking between the beginning of the file, and offsets >=58205773.

Why?

If you use boxdumper from l-smash to analyze the file locally, and check out the stco boxes which contain chunk offset information, you will notice that all the audio chunks come after all the video chunks in the file! So, to stream this efficiently, you would need some special intra-stream per-track caches to be implemented by players. But players are probably not going to add all that complexity for files that are accidentally (likely) or deliberately created to be shit for streaming.

[MoSal]

Actually, I just thought of a workaround if you are not bandwidth-capped. Use -audio-file so you have two tracks from two streams:

mpv $url -audio-file $url

Magic!

[GalaxySnail]

It looks similar to #7854. --stream-buffer-size=128M can be helpful.

[MoSal]

It looks similar to #7854. --stream-buffer-size=128M can be helpful.

Yes and no. In this case, the server does support ranges/seeking just fine. There are continuous seeks forward and backward that actually work. It's just seeking takes time and invalidates the smaller-than-buffer-size buffer every time. So increasing the buffer size to make it larger than the seeks will help, but a lot of cache invalidation will still take place. Increasing the buffer size to a value larger than the stream itself is a fix in a sense. But that's more like fully downloading to ram than streaming , and kind of requires knowing the size of the stream beforehand.

And what if the stream is huge, let's say 10GiB in size, and audio only starts at >9GiB? Increasing the stream-buffer-size to match that is not a practically workable solution. A workaround that gives each track a separate buffer (using audio-file) is the best solution, as it manages to closely mimic the imaginary proper future fix from mpv and/or ffmpeg (à la a new --stream-per-track-buffering option).

The only potential downside, which I'm probably overstating a lot, is the little bit of bandwidth wasted from early demuxing and buffering (done twice). It is maybe safe to assume that people who play URLs directly, instead of downloading/grabbing streams first, are not that bandwidth strapped, but you never know.