One of the nice features of the mpv API is the ability to modify the currently loading file stream using the on_load hook and the stream-open-filename property. This allows scripts to detect types of urls which mpv doesn't support, and make modifications to the path. For example, I have a script to remove percent encoding for ftp streams, which ffmpeg doesn't support for some reason.
The above mentioned method works great when loading an incompatible file directly, but there seems to be no way to do this when loading an external file. For example, say someone drags an ftp subtitle link onto the player, there seems to be no way to detect this file path before mpv discards it as incompatible (technically, it is possible to parse the following error messages printed to the console, but that is a pretty terrible way to do it).
Expected behavior of the wanted feature
My suggestion is to add a new hook which is run whenever an external file is being loaded (and perhaps on failed load as well), and a property that contains the stream path for the new file which API users could manipulate in the same way as stream-open-filename. The property would preumably be ignored/wiped as soon as the file has finished/failed loading.
Ideally this would trigger for all external file loads - automatic sub/audio loading, the --external-file option, video/audio/sub-add commands, etc. I assume it uses the same code, but I don't know how the mpv internals work.
I also don't know if it is ideal to have a hook in the middle of playback, would it freeze the whole player until the hook returns, or just the track loading code?
Alternative behavior of the wanted feature
I'm not sure what other methods would work, this seems like the cleanest option. Perhaps an event containing the path which is sent when an external file fails to load, then a script could parse the path and call the vid/audio/sub commands manually.
One of the nice features of the mpv API is the ability to modify the currently loading file stream using the
on_loadhook and thestream-open-filenameproperty. This allows scripts to detect types of urls which mpv doesn't support, and make modifications to the path. For example, I have a script to remove percent encoding for ftp streams, which ffmpeg doesn't support for some reason.The above mentioned method works great when loading an incompatible file directly, but there seems to be no way to do this when loading an external file. For example, say someone drags an ftp subtitle link onto the player, there seems to be no way to detect this file path before mpv discards it as incompatible (technically, it is possible to parse the following error messages printed to the console, but that is a pretty terrible way to do it).
Expected behavior of the wanted feature
My suggestion is to add a new hook which is run whenever an external file is being loaded (and perhaps on failed load as well), and a property that contains the stream path for the new file which API users could manipulate in the same way as
stream-open-filename. The property would preumably be ignored/wiped as soon as the file has finished/failed loading.Ideally this would trigger for all external file loads - automatic sub/audio loading, the --external-file option, video/audio/sub-add commands, etc. I assume it uses the same code, but I don't know how the mpv internals work.
I also don't know if it is ideal to have a hook in the middle of playback, would it freeze the whole player until the hook returns, or just the track loading code?
Alternative behavior of the wanted feature
I'm not sure what other methods would work, this seems like the cleanest option. Perhaps an event containing the path which is sent when an external file fails to load, then a script could parse the path and call the vid/audio/sub commands manually.