Mpv: Seeking in large audio streams over http is very slow

[j4ck0p3]

mpv version and platform

latest release 0.29.1 - macOS 10.14.3, Windows 10

Reproduction steps

Open a URL for a large http audio stream like this, or any large dj set from SoundCloud. Seek towards the end of the file (after 90' for example)

Expected behavior

Audio should play back at the selected point in time almost instantly.
Browsers do it. Other players like vlc do it as well.

Actual behavior

User has to wait a long time (until file is actually downloaded up to the selected point in time, it seems).

Is there a workaround or option/flag for this?
Which part of mpv is responsible for this problem/behavior?
Could mpv be built with another option which would fix this?

[zc62]

Can reproduce. Video seeking is fast, BTW. Probably a FFmpeg (libavformat) issue.
https://github.com/mpv-player/mpv/blob/89eacf8131827533c956a9a10ec1519d2ebdcc31/demux/demux_lavf.c#L1080
ffplay needs a similar amount of time if I specify a starting position close to the end of the file:

ffplay -ss 01:50:00 https://this-side.net/podcast/episodes/tsp004_joe_montana_50ytt.mp3

[mp3 @ 0x7f38dc000b80] Estimating duration from bitrate, this may be inaccurate

[d3vr]

I've got the same problem, any workaround for this?

[ghost]

Raw mp3 isn't a seekable format. libavformat just reads the entire stream until the target time is reached, that's why it's slow. (If it's wrapped into a proper container like mkv or mp4 this is not a problem.)

Now that seeking back and then forward to an already "covered" position will be fast as well, even if mpv didn't cache the data.

You can work this around by adding fastseek to fflags using --demuxer-lavf-o. Don't ask me for the exact syntax.

[d3vr]

Thanks wm4, for anyone that might find it helpful, here's the syntax:

mpv "https://url-to-mp3.tld/file.mp3" --demuxer-lavf-o=fflags=+fastseek