The test that lies
You have a camera stuttering. Someone runs a speed test on the phone, right where the camera is standing. The result is comfortably fast.
Conclusion: the network is fine, so the problem must be the camera, the software, or the phone. That conclusion is wrong, and the speed test is the reason.
A speed test measures how much bulk data you can move in a short burst, downloading. A wireless camera needs a modest amount of data delivered evenly, continuously, and upward, for an hour, while other devices are doing the same thing.
Those are almost unrelated properties. A network can be excellent at the first and poor at the second, and a speed test cannot tell you the difference.
What cameras actually need
Three things, none of which appear on a router's box.
Consistency over speed. A camera produces frames on a fixed schedule. Each one must get out before the next arrives. A connection that delivers in bursts (fast, pause, fast, pause) has excellent throughput and produces stuttering video, because the pauses become dropped or late frames. Steady beats fast, every time.
Upload, not download. Everything about consumer internet is optimised for downloading, including how it is advertised and how it is tested. Cameras only upload. Your download figure tells you almost nothing about your camera capacity.
Airtime, not bandwidth. This is the one people find most surprising and it explains the most.
The airtime problem
Wireless is a shared medium. Every device on the same band, in the same space, takes turns. Only one transmits at a time; the rest wait.
This means the constraint is not really bandwidth. It is airtime... the proportion of available transmission time each device gets.
The consequences are unintuitive:
A slow device hurts everyone. A phone with a weak signal transmits at a low rate, so it needs more time to send the same data. That is airtime nobody else can use. One badly-placed device can degrade a network that has plenty of nominal capacity.
Idle devices are not free. Every connected phone in the building talks periodically even when nobody is using it... checking for messages, updating, announcing itself. Individually trivial, collectively substantial. A room with two hundred phones in pockets has a busy network before anyone streams anything.
Adding devices degrades everyone. Not just the new device. Airtime is divided, so each additional participant reduces what is available for everyone else.
This is why a camera setup that works perfectly during Thursday setup (empty room, three devices) struggles on Sunday with the same equipment and settings. Nothing changed except the number of phones in the building, and that changed everything.
What actually helps
In rough order of how much difference they make:
1. Separate the cameras. The single most effective change. Put cameras on their own network... a separate band, a separate access point, or a dedicated network name that only cameras use. This removes them from competition with every phone in the room. It usually costs nothing and it is more effective than any equipment purchase.
2. Use the higher-frequency band for cameras. The 5 GHz band is less crowded and carries more data, at the cost of shorter range and worse penetration through walls. For cameras in the same room as the access point, that trade is almost always right. Leave the longer-range band for everyone else.
3. Improve the worst signal, not the average. Find the camera with the weakest connection and fix that one... move it, move the access point, or add one nearer. Because of the airtime effect, your worst-connected device disproportionately damages everybody. Improving an already-good connection does nearly nothing.
4. Reduce the number of competing devices. Not usually practical for a congregation, but relevant for anything on your production network. Every device that does not need to be there is taking airtime.
5. Consider wire for the fixed positions. Unglamorous and extremely effective. A camera that never moves does not need to be wireless. Every camera taken off the air is airtime returned to the ones that genuinely need it.
Testing properly
If you want to know whether your network will hold, test the thing you actually do.
Test with a full room, or simulate one. An empty-building test tells you about an empty building. If you cannot test with a congregation, at least test with every device you can find connected and active.
Test upload, sustained. Not a burst. Run something that uploads continuously for several minutes and watch whether the rate holds steady or sawtooths.
Test for the duration of your event. Problems that appear at minute fifty do not appear in a two-minute test. Buffers fill, interference drifts, devices join. If your service is an hour, your test should be too.
Watch the worst moment, not the average. A network that is excellent for fifty-nine minutes and terrible for one produces a visibly broken stream and an excellent average. Averages hide exactly the events that matter.
When the building is the problem
Sometimes the honest answer is that the venue's network cannot do this. Old wiring, a single access point covering a large hall, thick walls, or a connection shared with something else demanding.
In that situation, more configuration will not save you, and it is worth recognising early rather than spending months tuning. The options are to improve the network properly, to wire the cameras, or to reduce what you are asking of it... fewer cameras, lower resolution, a simpler setup that works reliably.
A reliable simple setup beats an ambitious one that fails on the days that matter. That is not a compromise; it is the correct engineering answer to a real constraint.
The short version
Your speed test measures a burst of download in an empty moment. Your cameras need steady upload across a busy hour, sharing air with every phone in the building.
Before you buy anything: separate the cameras from everyone else, and fix your worst connection. Those two changes are free, and between them they solve most of the wireless camera problems I see.