mediamtx icon indicating copy to clipboard operation
mediamtx copied to clipboard

Add a backing database in order to store changes sent through the API

Open aler9 opened this issue 2 years ago • 11 comments

Describe the feature

Add a backing database in order to store changes sent through the API.

aler9 avatar Jan 22 '23 12:01 aler9

etcd ?

JeDiE99 avatar Jan 24 '23 09:01 JeDiE99

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)

aler9 avatar Jan 24 '23 09:01 aler9

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

JeDiE99 avatar Jan 24 '23 12:01 JeDiE99

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.

aler9 avatar Jan 24 '23 15:01 aler9

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.

ivalkenburg avatar Feb 19 '23 21:02 ivalkenburg

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.

dottgonzo avatar May 02 '23 17:05 dottgonzo

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

Tabarane avatar Jan 27 '24 18:01 Tabarane

Even an in memory DB like Redis with an option to update the yaml file via an API call would be good

davidtaddei avatar Jan 27 '24 20:01 davidtaddei

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

Tabarane avatar Feb 01 '24 21:02 Tabarane

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

manfredipist avatar Apr 11 '24 13:04 manfredipist

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.

dbason avatar May 05 '24 22:05 dbason