Packet loss on wireless bridge
I run several cameras in a garden that has power, but not networking. So I run an enterprise grade wireless access point using 802.11s to connect a POE switch in the garden with several POE cameras. My throughput and wireless connection are solid and fast. Specs are well within normal use case for the equipment and no problems except that the camera streams work for about 5 min and then drop for a minute.
In SS I can notice a 1-3% packet loss for each camera.
My guess is that there is something in the nature of WiFi that RTSP streams do not like. Except that all of my Wi-Fi cameras actually do fine. So I wonder if there is a buffer in the wireless cameras that is not used in POE cameras? Is there anything that can be done about this on the SS side?
I'm almost to the point of ripping out the (supposedly more dependable) POE cameras and just putting in Tapo wireless cameras.
Suggestions?
Comments
In a similar usage situation, I use the camera's included power adapter rather than POE, and physically connect each camera to a dedicated eero WiFi repeater. I use older, cheaper eeros for this purpose.
Using a dedicated, physically connected eero means I'm not using the cam's built-in WiFi.
This differs from your setup in how the camera is powered, as yours uses POE, mine the power adapters. It sounds like all your cams are physically connected to one WiFi access point via the POE switch, whereas each of my cams has its own WiFi repeater. And each of those repeaters is part of a mesh system that will always find the best path back to the server in the event an individual component in the network chokes for any reason.
Maybe your cams total bandwidth exceeds the router's capacity, at times, perhaps when there's lots of motion (windy day, lots of foliage moving, perhaps)
I had just looked at my status report from yesterday before I saw your message. These are all SV3C cams except for one Dahua doorbell.
SUMMARY
- 9 of 9 cameras currently online
- 216 movie files recorded in total
- 0 image files recorded in total
- 164 GB of data recorded in total
- 100.0% software uptime
- 11% average CPU usage
- Normal memory pressure
CAMERAS
Network camera:
- 24 movie files recorded
- 0 image files recorded
- 22.8 GB of data recorded
- 0 errors
- 100.0% camera uptime
PTZ3:
- 24 movie files recorded
- 0 image files recorded
- 16.6 GB of data recorded
- 0 errors
- 100.0% camera uptime
Network camera 1:
- 24 movie files recorded
- 0 image files recorded
- 30.3 GB of data recorded
- 0 errors
- 100.0% camera uptime
PTZ2:
- 24 movie files recorded
- 0 image files recorded
- 35.8 GB of data recorded
- 0 errors
- 100.0% camera uptime
PTZ4:
- 24 movie files recorded
- 0 image files recorded
- 9.9 GB of data recorded
- 0 errors
- 100.0% camera uptime
Network camera 4:
- 24 movie files recorded
- 0 image files recorded
- 20.9 GB of data recorded
- 0 errors
- 100.0% camera uptime
Network camera 2:
- 24 movie files recorded
- 0 image files recorded
- 8.0 GB of data recorded
- 0 errors
- 100.0% camera uptime
Network camera 3:
- 24 movie files recorded
- 0 image files recorded
- 10.1 GB of data recorded
- 0 errors
- 100.0% camera uptime
PTZ1:
- 24 movie files recorded
- 0 image files recorded
- 10.5 GB of data recorded
- 0 errors
- 100.0% camera uptime
STORAGE
- Video Archive: 100 GB available of 4.0 TB total
Thanks for the comment on your setup. I did postulate at one point that the bandwidth of the link was insufficient, but with both Aruba and Ruckus (I've used and tried both) there is plenty of additional bandwidth at all times.
Another interesting piece to this is that I run Unifi Protect cameras side by side with some Annke and Reolink as I try different cameras. The Unifi Protect cameras such as the G4 connect via wireless bridge and have no drops whereas the Annke and Reolinks are sometimes rough. The Hiks are somewhere in the middle. Granted, the Unifi cameras connect to a UNVR before I get the RTSP for SS.... so their box could be doing something magic with the stream.
Are all your cams using H.265?
I think they might be. Is that codec more prone to latency or disruption?
It uses about half the bandwidth of H.264. It is a much lighter load on your network, and allows twice as much elapsed time videos to be recorded on your existing storage capacity.
The Apple M-series chips use hardware decoding for it, which is why you see my Mini reports only 11% CPU usage while recording nine 5K cams at 15FPS.
Thanks @Sawmill. I don't believe this is a bandwidth issue as there is plenty of that available on my network, and not a storage issue.
Whether you get packet loss largely depends on how the camera deals with situations of transient low network bandwidth, which can happen from time to time on even the best WiFi networks. The packet loss that SecuritySpy reports is loss of RTP packets, which carry the video/audio media payloads within the RTSP stream.
At the network level, the TCP protocol that SecuritySpy uses for these streams guarantees packet delivery (using loss detection and retransmission), so the problem is not at this level. Rather, it's at the level of the camera's own network buffers: if these fill up due to a transient low-bandwidth situation, what the camera should do is to temporarily lower its frame rate or drop a few frames, while maintaining consistency of the RTP packets that it is transmitting. However, what we have seen (usually for low-cost cameras) is that the camera drops RTP packets or whole chunks of video data, leading to video stream corruption.
These are the things you can try in order to solve this:
Thanks for the suggestion. Some feedback and possible anecdotal help for others in the same situation.