Scalability

[PatchaSravani2]

Question

I want to live stream 400 streams parallelly. Is this mediamtx server is capable of handling that many streams?

[aler9]

Hello, this server is used to handle thousands of streams at the same time, the limit is usually not CPU or RAM but the bandwidth of your network, so the only way to find out the maximum number of streams you can handle is to perform incremental tests on your infrastructure.

[pikachu937]

Hello, this server is used to handle thousands of streams at the same time, the limit is usually not CPU or RAM but the bandwidth of your network, so the only way to find out the maximum number of streams you can handle is to perform incremental tests on your infrastructure.

Greetings.
I would like to insert a little of myself and express my deep gratitude to the developer for such a wonderful product, there are many different implementations on the Internet, but in terms of speed, functionality and ease of operation, this project seems to me to be one of the best.
I have tested 2800 published streams (rtsp 720p) and, accordingly, 2800 broadcast streams (webrtc/rtsp) in a test environment. Everything works great on a computer with an intel core i9 processor (it is possible that it could work on an intel core i7), 128GB of memory and several groups of network interfaces combined in LACP.
In the process, I encountered a system limitation in the number of open files, but as we all know, in the Linux OS this limitation is easily bypassed. ATTENTION, when enabling the recording function (performed on a separate network server, the connection to which is made through a separate network interface), it was necessary to divide the server into containers (LXC/Docker), because mediamtx begins to freeze when the number of recorded streams exceeds 550, which is not surprising given such a load. As a result, I made a container limit of 100 published (including recorded) streams and 500 streams per broadcast, and as a result I got a lot of containers. As a result of the work done, the I/O load has dropped significantly and freezes are no longer observed. Expansion of network storage is expected ahead (by adding several nodes and redistributing disk arrays between them) to reduce the load on the network storage side.

PS. There is not enough function for clustering and searching for streams on servers, so that you can receive streams from different servers through one mediamtx server without first registering them on the main one.

[yelodevopsi]

@pikachu937 Thanks for sharing! I will presume the separate external application is a private project?
From what I read you use the stock/unmodified mediamtx-repo - as is - and develop more or less standalone modules/applications outside of this?

I ask since I see we're in the process of scaling up the MTX with the possibility with load balancing too and is curious to how you solved this.

We've made some ad-hoc solution with a REST API for saving/reading the mediamtx.yml config directly (to have persistence), but I see now that the "source of truth"/config should be maybe placed outside in some kind of load-balancer service or master-controller of some sort.

Would you care to share some of the architecture/structure of the db-application you are using? (if possible) 🙏

A wider question to both @pikachu937 and @aler9 maybe:

Sorry if I've missed any info about this - but are there a general common approach people take when building plugins/integrations towards the mediamtx today? I see that the core of the project should be simple, and thus I'm trying a way to modularize the current custom code I've developed on my own fork of the repo.

[rfscheidt]

Good morning, team!

From what I understood, Pikachu created this layer above MediaMTX to control the cameras and decide which server should handle the requested stream.

What I'd actually like to do (and I'm working on it) is to automatically create a stream when an RTSP request is made, if it doesn't already exist. So, when someone calls RTSP://xxxxx/channel1, I would access my API, retrieve the necessary data, create the path in MediaMTX, and then return the RTSP stream.

Best regards!

[aler9]

Hello everyone, regarding scalability, the feature description and discussion is in #998. The reason why it has not been implemented yet is that it's quite hard to do, since

• there are lots of features, and horizontal scalability must cover all of these
• horizontal scalability must be able to distribute streams among nodes but also to distribute readers among nodes, and there are several possible architectures
• there is no persistency layer (changes get lost after a restart) and we must think how to make it cohexist with the ability to add sources through the configuration file (changing the configuration file dynamically is a no-go)
• MediaMTX is a standalone software (it doesn't require dependencies like an external DB) and is often used in edge devices with very limited computational power

Now, of course if you discard one (or all) of these constraints, things get much simpler, and it's perfectly possible to build a scalability mechanism that makes use, for instance, of a database, or just redirects HLS users to a fixed instance. The question is that these simpler solution cannot be added to the codebase right now.

[aler9]

Sorry if I've missed any info about this - but are there a general common approach people take when building plugins/integrations towards the mediamtx today? I see that the core of the project should be simple, and thus I'm trying a way to modularize the current custom code I've developed on my own fork of the repo.

The first thing you have to decide is whether it's better to add additional features to the server or build them in a separate software. Personally i seldom edit the server, while i often build wrappers that launch the server and control it through the API. Regarding things that must get into the server at all cost (for instance, a new protocol), there are several subfolders inside the internals/ directory that should be self-explaining ("staticsources", "protocols", "servers", etc).

[rfscheidt]

Hey @aler9 can you show the way to do that?

I would like to create a new path when receiving an RTSP call.
What would be the best place to add this part of the code?

I tried creating it in the method func (m *Manager) authenticateHTTP(req *Request) error { before authentication. But it doesn't work; it seems to restart the application's context and cancels the RTSP call.

func (m *Server) createChannelHTTP() error {
confName := "namechanneltest"

pathJson := fmt.Sprintf({ "name": "%s", "source" : "rtsp://xxxx:[email protected]:8554/%s" }, confName, confName)

var p conf.OptionalPath
err := json.Unmarshal([]byte(pathJson), &p.Values)
if err != nil {
fmt.Println("Error parsing JSON:", err)
return nil
}

//a.mutex.Lock()
//defer a.mutex.Unlock()

newConf := m.Conf.Clone()

err = newConf.AddPath(confName, &p)
if err != nil {
return nil
}

err = newConf.Validate()
if err != nil {
return nil
}

m.Conf = newConf
//m.Parent.APIConfigSet(newConf)

return nil
}