mediamtx
mediamtx copied to clipboard
Add a backing database in order to store changes sent through the API
Describe the feature
Add a backing database in order to store changes sent through the API.
etcd ?
etcd ?
yes, that's exactly my idea, but i also want to use this feature to implement horizontal scalability, i.e:
users --> (N replicas of rtsp-simple-server) --> (N replicas of etcd)
users-group-1 -> rtsp-simple-server-1 -> etcd-claster-1 .... users-group-N -> rtsp-simple-server-N -> etcd-claster-N ?
OR
users-group-1 -> rtsp-simple-server-1 -> etcd-claster-comon .... users-group-N -> rtsp-simple-server-N -> etcd-claster-comon
in my opinion there should be a single pool of rtsp-simple-server replicas and a single pool of etcd replicas. Each rtsp-simple-server replica is in charge of a set of paths.
For instance:
replica 1:
- /path1
- /path2
replica 2:
- /path3
- /path4
Replicas are behind a load balancer.
If a user lands on a rtspss replica which is in charge of the path the user is looking for, the user stays on that replica. If a user lands on a rtspss replica which is not in charge of the path the user is looking for, the replica redirects the user to another replica by either sending a redirect (but in this case, all replicas should be exposed publicly) or by acting as a proxy to the right replica.
I would love this feature. I'm looking to implement RTSP proxy into one of my projects. But the lack of a persistent database is kind of holding me back. In my case id have to do some elaborate constructions with sidecars in a k8s deployment to make sure each instance got the data needed after each spin up. So any way for some database to have one source of truth would be great.
Why not consider incorporating a feature that enables updating the YAML configuration file to synchronize changes made via the API? This functionality would prove valuable in allowing server restarts without losing any configuration settings. Ideally, supporting the S3 storage API would further enhance this capability.
Hi, can we get an idea if we will have an options to make changes from the API persistent to the yaml file or we still have to use a DB , in this case we will need to do a changes in database and when server is up we need another service to dump out all changed to the mediamtx and also a 3rd service to monitor the server status , im confused, im trying to get an alternative to GUI where we can add 1800 camera to a running server and have it saved and dont lose all the effort done, advices is very welcome
Even an in memory DB like Redis with an option to update the yaml file via an API call would be good
would so much appreciate if we can know should we find a work around or if its planned some how along the road or if someone already find away to do that
I'd love to see this feature implemented, right now i can't make any replicas of mediamtx due to the fact i'm generating paths dynamically and there's no way for the clients to connect to the proper instance of the deployment
If a user lands on a rtspss replica which is in charge of the path the user is looking for, the user stays on that replica. If a user lands on a rtspss replica which is not in charge of the path the user is looking for, the replica redirects the user to another replica by either sending a redirect (but in this case, all replicas should be exposed publicly) or by acting as a proxy to the right replica.
We are doing something similar at the moment to achieve horizontal scalability. We have an OnReady hook setup to write the PodIP with the path as the key into a redis database (etcd would be better for this) when a stream is published. For WebRTC signalling we have a simple reverse proxy that looks up the path and then forwards the request to that specific instance. We are using a TURN server which takes care of the data.
We also tested with doing the same thing with HLS. For RTSP we initially just send a redirect as the client was inside the k8s cluster, however I don't think it would be too much work to use the rstp server library to act as a reverse proxy.