In this article, we will cover the following topics:
- Bandwidth requirements
- Variable Bitrate
- Video delay when streaming
- Video Streaming
- Local Recording
- Cloud Recording & Policy Events
- Offline Mode
Here is a diagram for quick reference:
The bandwidth used when live streaming a camera depends on the amount of motion and type of camera.
- R1 Default Bandwidth Live Streaming: 320Kbps and 720Kbps
- R100 Default Bandwidth Live Streaming: 530Kbps and 720Kbps
- R2 Default Bandwidth Live Streaming: 530Kbps and 720Kbps
- R360 Default Bandwidth Live Streaming: 480Kbps and 1440Kbps
- R400 Default Bandwidth Live Streaming: 530Kbps and 720Kbps
Note: Please note that this bandwidth is only taken when a camera is being actively streamed. Otherwise, the upload bandwidth consumption is 10 - 30 Kbps during normal operation.
Also, if the camera is being streamed locally, no WAN bandwidth is consumed as all streaming occurs over the LAN.
You can view the bandwidth usage of any camera navigating to a particular camera. At the bottom of the page where the video player is, you'll see bandwidth graphs for that camera.
Rhombus is committed to ensuring the lowest possible bandwidth consumption on customers networks while maintaining the highest possible video quality. One of the practices we have implemented the use of smart VBR (variable bit rate) which enables the cameras to greatly reduce bandwidth consumption when there is little change or motion in the camera field of view.
In addition to providing upload and download bitrates for individual cameras, you can also view total bandwidth consumed by locations on the main dashboard.
We guarantee that the numbers reflected in our graphs will match the values reported by other network devices that are part of your networking infrastructure.
Many IP camera solutions struggle with live HD video streaming. The Rhombus solution is near real-time with an average latency of the following depending on where you are streaming.
< 200 milliseconds on LAN (local network streaming)
< 500 milliseconds on WAN (remote streaming)
The actual performance can vary depending on number of cameras being streamed concurrently, distance from those cameras, and available bandwidth on the networks.
Each camera comes with an embedded micro-sd card which serves as the primary storage mechanism for all video data. When a user wants to view either live or past footage, it is streamed directly from the camera to the user’s viewing device. The exact mechanics vary depending on whether the viewer and the camera are on the same LAN, but there is no configuration required to make both work seamlessly. The video player automatically detects the network.
LAN :When on any network where the private IP address of a camera is routable from a user’s laptop or mobile device (so not strictly on the same LAN), the video player will automatically stream video directly from the camera instead of going out through the internet. This means that no internet bandwidth will be consumed, and the video feed will experience extremely low latencies. The connection to the camera will take place over port 8000.
WAN: On an outside network instead of going directly to the camera, which would require ingress ports to be opened up in a firewall, video streaming is proxied through our geo-distributed Video Streaming servers. Each camera initiates and maintains a persistent connection to a server on port 443, while the video player makes its own connection to the same server. Video content is then piped between the player and camera, with the server acting as a tunnel. Bandwidth used over the WAN typically averages between 120 and 1400 Kbps depending on the camera type and resolution.
Regardless of LAN or WAN, streaming is performed over a low-level web socket connection. A custom, light-weight binary protocol is used to control the data flow and keep data transmission as efficient as possible. While streaming live footage, the camera automatically detects transmission speeds and will adapt the video quality based on the consumption speed of the video player.
On each camera, H.264 encoded video is stored in 2 second segments on the local /ext4 filesystem. The size of each segment varies substantially based on the amount of content captured. Light, movement, and area under purview are the biggest variables, and can cause segments to fluctuate from as small as 20 KB to as large as 500 KB.
The storage mechanism works like a circular buffer, expunging old data only when new data needs to be written. This creates a fairly constant sliding window of time available to view, typically around 15 or 45 days, depending on storage model. Once data has been expired, it is no longer available for viewing.
When Cloud Archiving is enabled on a camera, an additional storage mechanism is enabled, with data still being written locally but also simultaneously being sent directly to our cloud storage service (Amazon S3). This results in all attempts to view past footage pulling video segments from the cloud, regardless of WAN or LAN locality. However, viewing live footage still benefits from being on the same LAN, with data never leaving the network.
The Rhombus cameras are designed to intelligently upload content to the cloud where more substantial analysis can take place. Selective video clips are uploaded in 30 second blocks, finding a balance between consuming upload bandwidth and identifying activity. The camera itself does a first pass of analysis, further restricting uploads to only content worth analyzing.
If a connected camera loses its Internet connection (either over WiFi or ethernet), it will continue to record. Because the cameras are writing segments locally, that continues with or without network access. During this time though, no new events (motion, human event, etc) will be shown on the seek bar. Once the camera comes back online, all missing events will be populated and the video will be remotely accessible again.
If you have Cloud Archiving enabled for the camera, you can view past footage online while the camera is offline. Furthermore, once the camera comes back online, the missing footage will automatically be uploaded to the cloud.
When the camera reconnects, it will auto-scan for certain ports including the NTP/123 port. This port must be open for the camera to connect to an NTP server and obtain a time to re-assimilate the footage in the proper timeline. If this port is blocked or connection is inaccessible, then the camera will not begin to record again.