mpv:// protocol still doesn't work with encoded URI fragment, sometimes

[CrendKing]

mpv Information

mpv v0.40.0-112-gb3070d125 Copyright © 2000-2025 mpv/MPlayer/mplayer2 projects
 built on May 13 2025 00:25:49
libplacebo version: v7.350.0 (v7.349.0-66-g72fb3c6-dirty)
FFmpeg version: N-119465-g9980a0b9b
FFmpeg library versions:
   libavcodec      62.3.101
   libavdevice     62.0.100
   libavfilter     11.0.100
   libavformat     62.0.102
   libavutil       60.2.100
   libswresample   6.0.100
   libswscale      9.0.100

Other Information

- Windows version: 10.0.26100.4061
- GPU model, driver and version: NVIDIA GTX 2070 Super
- Source of mpv: https://github.com/shinchiro/mpv-winbuild-cmake/releases
- Latest known working version: Not sure
- Issue started after the following happened: Ever since I started to use mpv://

Reproduction Steps

Even with the encoded URI, I still only managed to make the mpv:// protocol work with Twitch VOD URLs, with the help of --script-opts=ytdl_hook-use_manifests=yes. Other sources such as Youtube doesn't work at all. Seems to be incompatibility with yt-dlp?

1. mpv.exe --no-config "mpv://https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DRJ16miAsnZw" => The protocol is either unsupported, or was disabled at compile-time.
2. mpv.exe --no-config --script-opts=ytdl_hook-use_manifests=yes "mpv://https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DRJ16miAsnZw" => Same error
3. mpv.exe --no-config "mpv://https%3A%2F%2Fwww.twitch.tv%2Fvideos%2F2457215331" => Same error
4. mpv.exe --no-config --script-opts=ytdl_hook-use_manifests=yes "mpv://https%3A%2F%2Fwww.twitch.tv%2Fvideos%2F2457215331" => Works!

Expected Behavior

All 4 should work.

Actual Behavior

Only 1 works.

Log File

1 (Youtube without opt).log
2 (Youtube with opt).log
3 (Twitch without opt).log
4 (Twitch with opt).log

Sample Files

No response

I carefully read all instruction and confirm that I did the following:

• I tested with the latest mpv version to validate that the issue is not already fixed.
• I provided all required information including system and mpv version.
• I produced the log file with the exact same set of files, parameters, and conditions used in "Reproduction Steps", with the addition of --log-file=output.txt.
• I produced the log file while the behaviors described in "Actual Behavior" were actively observed.
• I attached the full, untruncated log file.
• I attached the backtrace in the case of a crash.

[CrendKing]

Interestingly, if I try the ytdl:// protocol, both URLs could work, but only if I do not encode it. For example:

1. mpv.exe --no-config "ytdl://https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DRJ16miAsnZw" => The protocol is either unsupported, or was disabled at compile-time.
2. mpv.exe --no-config "ytdl://https://www.youtube.com/watch?v=RJ16miAsnZw" => Works
3. mpv.exe --no-config "ytdl://https%3A%2F%2Fwww.twitch.tv%2Fvideos%2F2457215331" => Same error
4. mpv.exe --no-config "ytdl://https://www.twitch.tv/videos/2457215331" => Works

[CrendKing]

Another issue about mpv:// is that URL with // is of the authority form (reference). The browser would consider the part after mpv: as the "authority" part of the URL, and missing a path. It then tries to normalize the URL by adding an empty path / at the end. So what mpv receives is actually (after decoding) something like mpv://https://www.youtube.com/watch?v=RJ16miAsnZw/, which is wrong. The simple solution is to use the non-authority form URL by omitting the // at beginning. However, mpv can't handle that. mpv.exe --no-config "mpv:https://www.youtube.com/watch?v=RJ16miAsnZw" is reported with "Invalid argument" error.

[CrendKing]

I did some research. The cause of the issue seems to be that when the mpv URL is sent to ytdl, it is resolved into some edl streams. And since mpv stream has STREAM_ORIGIN_NET, edl stream has STREAM_ORIGIN_FS, and mpv doesn't allow network stream to open non-network stream, the stream will fail to open. Obviously I can workaround by changing mpv stream's origin to STREAM_ORIGIN_FS, but is it the right approach? I guess the only other option is to allow NET stream to open FS stream, but I don't know the history why the restriction is there to begin with.

For the "last slash" issue, I found how mpv is currently checking if a path is URL, in path_utils.c. It tries to find the "://" string and make it as the cue. If I understand RFC 3986 correctly, this is not how it should be done. Syntactically speaking, even a Windows path like "c:/windows" fits the URI syntax, where "c:" could be the scheme and "/windows" is the path part. However, the IANA URI Schemes Registry makes sure that is not valid URI. But since path_utils.c neither has a list of valid schemes it supports (i.e. only include schemes like https, file or ftp), nor consults that registry at runtime, it can't distinguish mpv:https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DRJ16miAsnZw as a URI while c:/windows as not.

Given this, even though I could change match_proto to specifically work for URIs like mpv:https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DRJ16miAsnZw, it is not exhaustive enough. Unless we'd want to also change path_utils.c. Another option is to always strip the last slash if exists in open_mpv.

[CrendKing]

PR for the main issue: #16348

[CrendKing]

The conclusion is that if ytdl hook is needed, use ytdl:// protocol directly. Or invent any protocol name, as long as there is a script to proxy the request to mpv.