starred/motioneye

Fork 0

mirror of https://github.com/motioneye-project/motioneye.git synced 2026-03-02 22:57:06 -05:00

Limitations #2623

New issue

Open

opened 2026-02-28 01:16:06 -05:00 by deekerman · 3 comments

deekerman commented

2026-02-28 01:16:06 -05:00

Owner

Originally created by @vijaydsk on GitHub (Apr 24, 2025).

Would like to know what are the limitations of this application in terms of following questions...

How many cam's it can accommodate?
What could be the recommended hardware for an installation, which covers nearly 3000 cameras?
Once it is installed on my premises, will that configuration data be shared with you?

Thanks in advance.

Originally created by @vijaydsk on GitHub (Apr 24, 2025). Would like to know what are the limitations of this application in terms of following questions... 1. How many cam's it can accommodate? 2. What could be the recommended hardware for an installation, which covers nearly 3000 cameras? 3. Once it is installed on my premises, will that configuration data be shared with you? Thanks in advance.

deekerman added the

question

label

2026-02-28 01:16:06 -05:00

deekerman commented

2026-02-28 01:16:09 -05:00

Author

Owner

@MichaIng commented on GitHub (Apr 24, 2025):

I am not aware of a software-wise limit in motionEye code.
Uff, not sure whether this is possible, if you want to to motion detection on all those. The simple MJPEG camera device does not allow motion detection, but does not imply notable server load either, since the camera stream is passed directly to the web client, when visiting the website. But for motion detection, each stream must be processed at the server 24/7, and additionally sent to the web client(s) from there. For network cameras (I guess you do not attack 3000 cameras all directly to the server) this means 3000 incoming camera network streams, processing at the server, and sending them out all to every client which visits the web interface. I guess alone the network bandwidth would completely break down by this. Not sure whether the frontend receives only those streams currently visible (depending on scrolling), but even if not, to me this seems to be not possible for a single machine. But this is only my assumption. Would be actually interesting to test this, adding more and more network cameras and see how this affects network bandwidth (with and without web client watching the interface/streams) and CPU/GPU for processing via motion at the server.
No, the motionEye project does not even have an own server or anything where it could collect data. The software does not contain any usage data collection feature or any such.

@MichaIng commented on GitHub (Apr 24, 2025): 1. I am not aware of a software-wise limit in motionEye code. 2. Uff, not sure whether this is possible, if you want to to motion detection on all those. The simple MJPEG camera device does not allow motion detection, but does not imply notable server load either, since the camera stream is passed directly to the web client, when visiting the website. But for motion detection, each stream must be processed at the server 24/7, and additionally sent to the web client(s) from there. For network cameras (I guess you do not attack 3000 cameras all directly to the server) this means 3000 incoming camera network streams, processing at the server, and sending them out all to every client which visits the web interface. I guess alone the network bandwidth would completely break down by this. Not sure whether the frontend receives only those streams currently visible (depending on scrolling), but even if not, to me this seems to be not possible for a single machine. But this is only my assumption. Would be actually interesting to test this, adding more and more network cameras and see how this affects network bandwidth (with and without web client watching the interface/streams) and CPU/GPU for processing via `motion` at the server. 3. No, the motionEye project does not even have an own server or anything where it could collect data. The software does not contain any usage data collection feature or any such.

deekerman commented

2026-02-28 01:16:09 -05:00

Author

Owner

@starbasessd commented on GitHub (Apr 24, 2025):

I guess alone the network bandwidth would completely break down by this. Not sure whether the frontend receives only those streams currently visible (depending on scrolling), but even if not, to me this seems to be not possible for a single machine. But this is only my assumption. Would be actually interesting to test this, adding more and more network cameras and see how this affects network bandwidth (with and without web client watching the interface/streams) and CPU/GPU for processing via `motion` at the server.

IIRC, back in the 0.42.1 days, the limitation was always network first, and CPU 2nd. You have the bandwidth per camera to the server, then the bandwidth per client from the server. IIRC, the limits, even if all the cameras were 640x480, was in the neighborhood of 10 cameras. I personally got up to about 20 cameras total, but that was using 3 NICs, and 3 separate wired networks (all 3 were gigabit ethernet), for a test I ran. The server was a PC running Debian 10, on a Ryzen 7 1700, 32GB RAM, and mutiple TB HD. Networks bogged down before the CPU got stressed. Should get better on a 2.5Gbit or 10Gbit, but I don't know of too many cameras that have that connectivity.

3. No, the motionEye project does not even have an own server or anything where it could collect data. The software does not contain any usage data collection feature or any such.

Easy 'test', put it on an isolated network with no internet access. Wireshark it.

@starbasessd commented on GitHub (Apr 24, 2025): > I guess alone the network bandwidth would completely break down by this. Not sure whether the frontend receives only those streams currently visible (depending on scrolling), but even if not, to me this seems to be not possible for a single machine. But this is only my assumption. Would be actually interesting to test this, adding more and more network cameras and see how this affects network bandwidth (with and without web client watching the interface/streams) and CPU/GPU for processing via `motion` at the server. > IIRC, back in the 0.42.1 days, the limitation was always network first, and CPU 2nd. You have the bandwidth per camera to the server, then the bandwidth per client from the server. IIRC, the limits, even if all the cameras were 640x480, was in the neighborhood of 10 cameras. I personally got up to about 20 cameras total, but that was using 3 NICs, and 3 separate wired networks (all 3 were gigabit ethernet), for a test I ran. The server was a PC running Debian 10, on a Ryzen 7 1700, 32GB RAM, and mutiple TB HD. Networks bogged down before the CPU got stressed. Should get better on a 2.5Gbit or 10Gbit, but I don't know of too many cameras that have that connectivity. > 3. No, the motionEye project does not even have an own server or anything where it could collect data. The software does not contain any usage data collection feature or any such. Easy 'test', put it on an isolated network with no internet access. Wireshark it.

deekerman commented

2026-02-28 01:16:09 -05:00

Author

Owner

@MichaIng commented on GitHub (Apr 24, 2025):

Yeah that sounds pretty realistic, also that network is the bottleneck, at least for netcams and/or when clients are watching.

Easy 'test', put it on an isolated network with no internet access. Wireshark it.

Better be safe than sorry 👍. I once contributed to a fork of an old project, and found it sending to a Google Analytics account of the original project owner. Imagine, this was open source network service software hosted by thousands of admins. And all their users/visitors were sending usage data to one Google Analytics instance, neither transparently visible to them, nor to any of the admins, as long as they did not check the code. Not sure how many national privacy laws were violated by this, without anymore knowing/recognizing 🙈.

However, I have contributed to motionEye and all its source code/script files a lot longer, many others did, and no one ever saw data collection or tracking code. Also in above example, it was not exactly hidden. I think that developer just did not think about it properly, but did not have bad intentions.

@MichaIng commented on GitHub (Apr 24, 2025): Yeah that sounds pretty realistic, also that network is the bottleneck, at least for netcams and/or when clients are watching. > Easy 'test', put it on an isolated network with no internet access. Wireshark it. Better be safe than sorry 👍. I once contributed to a fork of an old project, and found it sending to a Google Analytics account of the original project owner. Imagine, this was open source network service software hosted by thousands of admins. And all their users/visitors were sending usage data to one Google Analytics instance, neither transparently visible to them, nor to any of the admins, as long as they did not check the code. Not sure how many national privacy laws were violated by this, without anymore knowing/recognizing 🙈. However, I have contributed to motionEye and all its source code/script files a lot longer, many others did, and no one ever saw data collection or tracking code. Also in above example, it was not exactly hidden. I think that developer just did not think about it properly, but did not have bad intentions.

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

starred/motioneye#2623

No description provided.

Rows
Columns