Skip to main content

What Bandwidth Recommendations are there for Wisenet SKY?

  • Updated

 

Summary:

We recommend 100kbps per camera for our real-time previews stream.
You can adjust the quality on those by raising or lowering the
settings but those are safe averages. 
We load balance and pool requests so that multiple people watching
the same live stream view it through our cloud and only a single live
stream between the bridge and our cloud are required.
This allows us to get more cameras on the same bandwidth. In addition,
full resolution video streams can be be watched live or through our
history browser. Our Bandwidth management gets the most out of
available bandwidth.

 

Example 1:
We have a low-bandwidth customer who has successfully deployed 8 HD cameras on our system on a 1.5Mbps connection. We use 0.8Mbps for our low resolution preview video. The customer has the ability to watch a live (or historic) HD video stream of any camera. The preview stream and background upload slow down while the full HD streaming is taking place. Once they finish, the preview stream speeds back up.

Example 2:
We replaced a camera installation at a daycare center. They were providing low resolution video to parents so they could check on their children. Using their previous system, they were only able to support ~20 simultaneous viewers. Using our platform, all 80+ parents can see the preview stream at the same time. The preview stream only uses 0.8Mbps to upload to our cloud and all the parents are served by our cloud.

 

Technical Explaination:

When talking about bandwidth we segment it into three groups:

  • Real-time bandwidth
  • Background bandwidth
  • On-demand bandwidth

Real-time bandwidth:

Is what the bridge and cameras use to send and receive metadata and preview images. By default, we set it to 50kpbs and recommend adjusting to 100kbps or until image updates are smooth.

 

mceclip0.png


Background bandwidth:

Is how we refer to background video uploading. When the video is saved to the bridge it goes into a queue and is scheduled to be uploaded. The metadata travels ahead to the cloud. As bandwidth allows, the background video is sent up and removed from the bridge. The bridge allows for bandwidth limits to be scheduled so as to not interfere with other network traffic.

 

mceclip0.png

 

You can see that we have set the bridge to not use any background bandwidth during working hours and use 4mbps during non-work hours. Here is what that bridge metrics look like and they confirm those settings.

 

mceclip1.png

 

On-demand bandwidth:

Is the highest priority and will utilize all the bandwidth of real-time and background settings. When something is requested from the bridge that has not been uploaded yet, it will be immediately pulled from the bridge and sent to the client. This is the case for live videos. Our cloud will also transcode the video into other formats depending on the client’s request. Live streaming has a couple seconds latency. Video conversion adds additional latency for live viewing. Our goal is to keep live streaming within 2-3 seconds and live stream with video conversion within 8-10 seconds.

Related articles