search

bluenviron / mediamtx

Ready-to-use SRT / WebRTC / RTSP / RTMP / LL-HLS media server and media proxy that allows to read, publish, proxy, record and playback video and audio streams.
MIT License
10.71k stars 1.4k forks source link

List available streams on local port(eg. 8888), rather than giving a 404. #3337

Closed briantho closed 1 month ago

briantho commented 1 month ago

Describe the feature

When running mediamtx and using any browser to do hls, webrtc, whatnot I've noticed something that should probably be changed. Currently when running http://serveraddress:8888 you get a 404. You have to put the stream name in to get anything. for example, if I put in http://serveraddress:8888/mystream where mystream is a stream i have, eyerything works as expected. If I put in http://serveraddress:8888 without a stream I get a 404. In my opinion, the 404 should say "thanks for using mediamtx" and give a list of streams, so one can simply click a link, and easily load the selected stream.

This would be nice, as it could display all configured streams, all in one page. Then, a user could just click a link, and be brought straight to the correct stream url. Basically, instead of typing http://serveraddress:8888/stream1 or http://serveraddress:8888/stream2 you could just get a list of all available streams all on one page, then clicking stream1 you would be redirected to http://serveraddress/stream1

aler9 commented 1 month ago

Hello, the list of all available streams can be obtained through the Control API. It cannot be exposed publicly for security reasons.

briantho commented 1 month ago

Could this at least be an option in the yaml file if someone wants to expose a list of streams? Besides isn't it possible to just password protect the port? Regardless, a user should not get a 404, if just browsing the local port. Could you at least come up with a message, rather than getting a 404 if just browsing port 8888

aler9 commented 1 month ago

The server is currently used as a backend component, doesn't have a full web interface and even if it would, it wouldn't cover all possible use cases. My advice is to write a web interface that suits your needs and import required server components (live streams or API) through HTTP calls.