Patch API call to change a HLS path causes long pause in output/some clients need restarting - is seamless possible?

[privatesam]

Question

I'm building an application which has a HLS path declared in the mediamtx.yml:

paths:
    proxied:
      source: http://1.1.7.915:1111/manifest.m3u8?id=11

I'm then reading this stream from mediamtx through the web browser at http://localhost:8888/proxied . Then my web app calls the api to change the path for what is showing on http://localhost:8888/proxied by doing this:

curl -X POST http://localhost:9997/v3/config/paths/replace/proxied \
     -H "Content-Type: application/json" \
     -d '{"source": "http://1.1.1.95:1111/manifest.m3u8?id=234"}'

But unfortunately the stream in http://localhost:8888/proxied just buffering and stalls and sometimes it eventually picks up but mostly it needs the browser refreshing. If the client is VLC reading http://localhost:8888/proxied/index.m3u8 it completely stalls and needs to be restarted. I've tried both POST using replace and PATCH but its the same issue.

This might be expected behaviour for mediamtx but I was hoping to be able to seamless change the HLS path on the fly like this. For example if I run an ffmpeg command to do something similar:

ffmpeg -i 'http://1.1.7.915:1111/manifest.m3u8?id=11' \
-vcodec copy -hls_list_size 30 -hls_flags delete_segments+append_list+omit_endlist \
-f hls \
index.m3u8

and then quickly kill that process and bring it back it with the updated input:

ffmpeg -i 'http://1.1.1.95:1111/manifest.m3u8?id=234' \
-vcodec copy -hls_list_size 30 -hls_flags delete_segments+append_list+omit_endlist \
-f hls \
index.m3u8

then any client consuming index.m3u8 - web html5 player or VLC continues seamlessly because its still working its way through the segments - suddenly the feed just changes to the new input stream.

Is there anything I can tweak in mediamtx to make a seamless patch of the HLS path possible?

[aler9]

Hello, the feature you are looking for is currently unimplemented but is being tracked here: #2214

Unfortunately recent HLS versions got much more complex than the first one, that required just a bunch of files that could be hosted by any HTTP server. Adding files to an existing folder is not enough anymore, as the stream must be coherent in terms of count and kind of published tracks, there must be no gaps between segments and there's also need of blocking endpoints ("preload hints" and "blocking playlists").

Therefore, the only way to solve this issue is to generate a continuous stream on the server-side.