Cloud Archive Bandwidth

[BlakeRichardson]

I am looking at potentially moving to MV cameras, we currently us a mixture of Axis and Hikvision cameras attached to an NVR, we have about 43 cameras and plan on adding more as we are a large site and many buildings and have a few blackspots. My question is how much bandwidth does "cloud archive" require per camera. I am assuming that the footage upaloded is heavily compressed.

Thanks 

The gnomes' hidden egg has been found!

[PhilipDAth]

I have been told 1Mb/s per camera and it is stored in the cloud exactly as it is stored in the camera with regard to quality.

[BlakeRichardson]

Perfect thanks @PhilipDAth 

[MerakiDave]

Hi @BlakeRichardson  Confirmed, when you deploy an MV_CA license on any given camera, that camera will dual-record to both the local camera AND to the Cloud Archive, continuously.  In the camera view you'll now see the usual green bar (local storage) as well as a blue bar (cloud archive).  Motion based retention will become unavailable, since it's recording continuously so MBR doesn't apply and it's dual-recording to the camera and the cloud archive in Azure.  When leveraging MV_CA, the quality settings are locked to whatever options would not exceed 1024Kbps, such as 720p at 15fps or 1080p at 8fps for example.  So the main thing to be aware is that you'll start streaming 1Mbps per camera continuously to the cloud.  So plan accordingly especially if ISP bandwidth is limited.  Hope that helps!

[jdsilva]

As with all things, the devil is in the details 🙂

Over time you will get a 1Mbps average, but that's not what's actually happening. The cameras roll up 30 second chunks of video and upload those individually to the cloud, using as much bandwidth as they possibly can get. What you actually get is a saw tooth of bursts of video being uploaded, not a continuous, steady 1Mbps. 

This may be important to you, it may not. But I think it's important to understand the actual behaviour. If these bursts are a problem for you traffic shaping on the cameras can help smooth it out.

[MerakiDave]

Agreed @jdsilva that it's not a continuous steady 1Mbps stream to the cloud archive.  As you stated, the nature of HLS leverages video in 30-second chunks, and the bursts of video content, when they are uploaded to MV_CA, will burst accordingly.  Thanks for pointing that out.  If those bursts are an issue for some reason, it's simple enough to configure a traffic shaping rule to address it. 

The 1Mbps per camera then is more of a guideline of what to plan for (on average) when deploying MV_CA.  If a customer has 1000 cameras and wants 100 MV_CA licenses, the guideline it to plan accordingly for that additional 100Mbps of Internet traffic. 

Overall the MV solution is very bandwidth-conscious.  I'll also add that as you deploy more cameras with MV_CA licenses, their uploads to cloud archive will not be synchronized (by design) so that will randomize the uploads and minimize bandwidth spikes.  It's not like all 100 cameras in the example above would simultaneously hammer the WAN/ISP every 30 seconds.  So statistically speaking, as you scale up the solution, any sawtooth pattern will certainly tend to flatten out.

[OCTOMG]

Sorry to revive such an old thread, but have the MV_CA quality limitations been increased with the release of the 4MP and 4K cameras or will their footage still be stored as 1080p at 8fps?  I can't find any information on this in their documentation.  

We're evaluating a 100 camera deployment and are trying to determine the WAN bandwidth requirements for this project.

If you've got any new info or can point me in the right direction, I'd really appreciate it.

[PhilipDAth]

I don't know the answer.

The documentation seems to have been updated to include some of the newer cameras like the MV63 and MV93, but it still seems to top out at 1080p.

https://documentation.meraki.com/MV/Initial_Configuration/MV_Cloud_Archive 

[cmr]

I too don't know, but as our (non Meraki) 360° cameras stream at about 15-20Mbps (including compression), I can't see how a 1Mbps limit would work!

[OCTOMG]

Thank you, sir.

I had a discussion with Meraki today regarding this issue and it was confirmed that all video in the cloud is stored at 1080P and that the current upload bandwidth limitations are still in effect for the higher resolution cameras.  We didn't get any information on if/when this might be changed.

Not the answer we hoped for, but at least we know the parameters to help us design the solution.

[OCTOMG]

---

@MerakiDave wrote:

When leveraging MV_CA, the quality settings are locked to whatever options would not exceed 1024Kbps, such as 720p at 15fps or 1080p at 8fps for example.  So the main thing to be aware is that you'll start streaming 1Mbps per camera continuously to the cloud.  So plan accordingly especially if ISP bandwidth is limited.  Hope that helps!

---

I'd like to clarify this statement because I originally misunderstood it.  I was under the assumption that local footage would still be viewable at any resolution and only footage offloaded to the cloud would be retained at a lower resolution.  This is not true, so I was incorrect.  As I reflect on it, that was a foolish assumption on my part.

When you apply a cloud archive license to a 4K or 4MP camera such as the MV52, the video settings are automatically locked to 1080p (which is exactly what @MerakiDave said) for both local and cloud storage, so any footage viewed from this camera, whether live or archived, will only be available at the lower resolution.

The TLDR is this: when planning an MV deployment, the first decision to be made is what's more important - retention or quality.  If longer retention is the primary goal, know that your max quality will be 1080p @ 8fps if Cloud Archive is required.  If quality is the primary goal, know that Cloud Archive isn't an option and your retention will be between 5-35 days if you deploy the 4MP or 4K cameras @15fps or higher.

In spite of these limitations (which aren't unique to Meraki), the Meraki MV solution still has several other benefits that make it an extremely attractive option when compared to conventional systems.  We're committed to it, but I just wanted to point this out in an effort to help others who may be going through the same evaluation process.

[cmr]

I have to admit that these kind of limitations made by a number of cloud camera vendors does somewhat limit their use.

With 'traditional' IP camera solutions you can have multiple feeds and each one has its own bandwidth setting.  Therefore a continual stream to a video wall can be limited to 1Mbps, but the recorded footage could well be 5Mbps, even in 1080p if you have a high quality setting and frame rate.

I'd hope that there will soon be an update where you can set the onboard and cloud rates to be different, so you don't restrict the devices quality needlessly.

[OCTOMG]

Well said.  I completely agree with this and hope for the same update.

We're forging ahead with the project in spite of these limitations with the expectation that future updates will accommodate our long term needs.

[Bandwiches]

EGG FOUND!

[PacerX]

Egg Found!

[MerryAki]

EGG FOUND !

[Jason_Willett]

Egg found!

[JulienBelazzoug]

Easter egg found !! 🙂 

[Greenberet]

EGG FOUND !!

[SSAY-AXS]

Nicely done, 

Good Jod and congratulaion 👏