This is huge for us. Zipstream alone is huge for us, but as they refine it further it is truly going to be a game changer. Even though bandwidth is not an issue (as in we have plenty) our IT staff continues to push us to lower our usage.
Axis Launches Next Gen Zipstream
Smart codecs are one of the most important emerging surveillance technology trends.
Axis was the first, launching Zipstream in Spring 2015 but was quickly followed by Hikvision H.264+, Panasonic Smart Coding and more every month.
Now, Axis is pushing forward with its next generation smart codec that has the potential to further reduce bandwidth by another 50%.
In this report, we examine what Axis is doing, its potential impact and how it matches up against competitors like Avigilon and Hikvision..
Dynamic ***** **** - *** *** *******
**** *** ***** ******* ***** **** (****) to *********, ******** *** ***** **** to **** *** **** ***** ** motion ********. ***** **** ****** ** not *****, ** ** ***** ******** with ********'* ******* ***** *********** *** ******* I-frame *********, ** ******* ******* ********* savings.
***, ********* *** *********** ***** ***** ***** for ***-******** *****. ********* ****** ***** on *** ******** *****, ** *** scene *** * ***** ****** ** activity ** *** **** **** ***** to *****, ***** * **** ****** scene **** ** * ******* *** drop ** *** ** ****.
** *** ********* *****, **** ***** *** a ******* ********* (** *****) ***** reduce ******** ******** ** * ******** FPS ******* (** *****):
**** ********* ***** ***** **** ********:
**** *** ** ******* (** ***) independently ** *** ******** *********** *** I ***** ********. ** *** ***** release, ***** ** ** ******** *** a ***** ** ******* ***** **** and *** *** ** **** ** 1. **** **** * ****** ******** release **** *** ****.
************
*** *** ********* **** **** **** be ********* ** *** **** ***** starting **** *** *.** ********.
Original ********* ******* ***********
*** ******** **** ********* **** ****** ************* ******* ** **%+ ***********, even **** **** ******* *********** *** I ***** ********.
**** ** * ********** **** *** recent**** *****-* ****:
Projected ********* ******* *** ***
** ***** **** ******* ** *** activity (********, **********, ***** ***** *****, etc.), *** ******** ** **** **** likely drop ********* ** ******* **% ** so.
** **** ******, ** *** *********** a *****, ***** *********, **** *** HD *****, ** ********* ******** **********.
Motion ***** ********* ***********
******* ********* ** ********* *** ***** customers ** ****** ********** ********* ******* of ******-***** *********, ******* ****** ** increase ***** ******* ******.
******-**** ********* *** **** * **** for ********* **** ****** ****** **** can ** ******* ** ********** ******. If * ******** ******* ****** **** were ******* ** * *****, ***** may ** ** ***** ******** (** the ***** ** *****, ***** *** have **** ** ********, *** **** nothing ** ******* * *********), * 1 *** ***** ****** *** ** ********** to ***** ** ******** *** *** occur ** *******.
** *** ***** ****, **** ***** will ****** ** ******** ***** **** at ***. *** *****, ********* **** is *** * ***.
Avigilon **** ***** **** **********
**** ***** * ***** ********* ** Avigilon ****. ***, **** *** ***** the *** *** ********* ******* **** Avigilon ***** (**** ** *** ***** equivalent ** ******** **** ***** ****) but **** **** *** **** ***** codec ******* ***** ******** *** ****.
Hikvision *.***+ **********
***** *.***+ ****** ********* ******* ***** the *** ** **** *********, **** has *** **-****** **** **** *** addition ** ****. ** ******, ********* is * **** ******** ** ** is ***** ****** ********* ** **** / ** ********* ******* *****.
Overall ****** ******
*** *** **** ****, ************ **** ******** *********, ** **** ******** **** ***** codecs *** ** ********* *****. *** addition ** **** ** ** *********** advance, ****** *** ** *********** ** the ******** *********, ** *** ******* **** in ******** ********* *********** *** ******* competition ** ***** ***** ******** ** fall ******.
****
Can't this already be done with Zipstream, albeit crudely, thru a VMSes speed up on motion mechanism?
Yes, at least within Milestone. I can't speak to any others. However, this will likely decrease the processor load on the server in making that decision.
So the green is without Zipstream and the black is with DFPS Zipstream?
Where's the same comparison from New Zip to Old Zip? Isn't that what we need to see to evaluate how much of an improvement there is?
I think that they are wringing out a damp sponge at this point.
Sure 50% sounds great, but as you say the savings are greatest when the activity is least. And since the dynamic GOP can already be set to drastically reduce those times to little more than the motion difference between the frames, I'm thinking that the savings might not be very much at all when you are already cranking the GOP up.
Is that a graph that they showed at one time with the old zip?
Original zip with dynamic GOP?
Because those I-frames look very undynamic even as the activity varies greatly. Also, notice how dynamic they are in the black.
Even though they are close in the spots you point out there is a noticeable difference. Multiply that across a few hundred cameras and it turns into a large difference.
Ross, before we get to what the graph means, we need to know what it is actually comparing. I'm pointing out the spikes only to show the the graph, IMHO, is comparing the new Zipstream with no Zipstream.
The spikes are I-frames; their regularly spaced presence indicates that one set of data does NOT have dynamic GOP enabled.
That's all I am showing with arrows. I could be totally wrong about the savings being small, but John didn't say that (yet), instead he questioned one of my assumptions, i.e. the the graph is showing Zip vs no Zip, where he believes it is Zip vs old Zip.
What do you think it is comparing?
I took it to be old zip to the new zip, but I see what you mean. Could easily be new to none.
To me, this old graph makes it clear that the new graph is DFPS vs nothing, especially the top line. What do you think?
I would be interested to know if anyone has had any experience with Indigovision SMART.core in this regard? As I understand it Indigovision has done something in this area for a while.
According to IndigoVision's website:
SMART.core has Activity Controlled Frame-rate and saves you huge amounts of storage costs. Dozing along at 1fps when there is no activity, it launches instantly into a full alert mode of 30fps when there is. Storage savings can be up to 90%.
This description is similar to DFPS except that DFPS can dynamically adjust frame rates in between (i.e., not just 1 to 30).
Also, Zipstream dynamically adjusts compression by region and I frame interval whereas I have not heard IndigoVision claim that.
Thank you John. This is new for me with dynamic compression in this manner. Normally our clients wants a constant 25fps recording as it's ofthe process related rather than security.
Can the Axix Zipstream compressed files encoded with all bells and whistles still be played back in any viewer?
Can the Axix Zipstream compressed files encoded with all bells and whistles still be played back in any viewer?
We have tested with 3 or 4 VMSes and it has worked. It does not seem to be a general issue and should not be, but obviously i cannot vouch for 'any viewer'.
From the updated whitepaper:
When using dynamic GOP, the GOP length will vary, which might pose a problem for some VMS and other types of client software. When using dynamic FPS, the frame rate will also vary, a ecting some VMS and client software.
Hi John, Version 2.0 of ACF of IV can be configured not only with 1 ~ 30 fps only pending intelligence application to the I frame interval and dynamic regions of activity.
DFPS is soundingly awfully like what Dedicated Micros used to call Multimode:
MultiMode Recording - Dynamically-switchable resolution, record-rate & compression (MPEG-4/H.264/JPEG) settings
Maybe Mike is going to return as a patent troll ?
A feature like this is quite suitable for in cam edge recording where there is little live monitoring and only event based after the fact viewing. Limited storage, limited life of storage, but still having a 24/7 chain of evidence and not requiring a centralised NVR.
This is a huge improvement. Now we need someway to predict the benefits when sizing storage. Most NVR storage calculators are way behind the camera / codec technology. This puts more emphasis on our "guess-timating" and accepting the risk if we undersize the storage. Any ideas or help?
Brad, good question / point.
On the plus side, you are probably not going to undersize storage with any NVR storage calculator, since they almost all way overestimate even without factoring in smart codecs, which would reduce bandwidth further.
I asked Axis if their Design tool / bandwidth calculator will be updated to factor in Zipstream. I'll respond with any new info.
In general, though, I agree with your underlying point. It's becoming harder and harder to abstractly estimate bandwidth usage given the numerous factors that can radically change bandwidth consumption.
Another possibly less risky and more beneficial approach to Axis version of dynamic frame rate would be to implement VMS based frame rate paring.
The way this would work would be that the camera would transmit at full rate always, along with its motion meta-data. The VMS would record at full rate.
After a suitable period of time has elapsed, (normally corresponding to the first order review time, 48 hours for instance), those streams with little motion would be retroactively reduced based on a similar algorithm to the one used by Axis.
This has the advantage of providing the full frame rate video during the time period when it's most likely to be needed. The overall storage reduction is nearly the same, adding only the extra storage for those 48 hours. Also an automatic mechanism could be added to prevent such reduction if the footage has ever been reviewed in that period.
Server side proceessing of the reduction could take place in the background, during the low utilization periods corresponding with high dynamic GOP.
One caveat, for this to work on h.264 efficiently and without decoding, svc-t encoding or its equivalent would have to be implemented at the camera. Hikvision and Dahua have this option on some lines today.
Milestone's archive grooming method allows you to reduce framerate in multiple steps by stripping video down to keyframes. I don't want to insult their features, but it is very limited, though it certainly helps in larger deployments with long total retention times. It can end up losing valuable video or stopping recording in general if you do not constantly watch for the dynamically changing bandwidth loads. Overall you are unable to use a lot of your storage because of the possibility of data loss.
Your idea would be more effective than the in-camera codecs from usage of pre and post recording so as not to miss important details of an incident whereas relying on the camera to do this would incur extra complexity regarding offloading buffered video to be stored by the VMS after the pre and post buffers were fulfilled.
Could look at making a VMS plug-in that enhances the existing troublesome features and allow users to manage storage far better. Eventually this will likely get moved from the camera to the VMS anyway, as other centralized technologies have.