A great technical question was posed to us last week on a 3rd party security technology evaluation site, IPVM. In this post we re-post the spirit of the question and explore Bosch's CBIT technology which will eventually lead us to a comparison to Axis' Zipstream technology.
Introductory information about Bosch's bit rate reduction technology, iDNR a.k.a. CBIT, can be found here.
So, here is the general question from an anonymous security pro:
CBIT didn't seem to have variable GOP, to which IPVM indicated it did. More precisely what I meant to say was 'continuously variable GOP', i.e. one that dynamically adjusts on the fly based upon the image, like Zipstream. Does it have that? Would you say it is similar to (Axis') Zipstream or not?
To get the best answer, we went to the experts directly. David Brent, from Bosch, offered the following response:
CBIT is an imaging technology that works on noise reduction …. It does not change the way the processor in the camera functions when it comes to FPS:
Encoding interval/ FPS: The DSP never changes cycles or “frame rates,” it is always running at 100% for efficiency purposes. It delivers the correct amount of video to users and storage devices by placing only the desired number of frames on the network for delivery. The equation for Frame Rate is: 30/Encoding Interval = FPS (Example: 30/2 = 15 FPS)
- Target data rate and Max data rate: Although these are two separate settings they are bound together as two of the three primary “numbers” that make your encoder tick.
- Target: This is the bit rate that the encoder will always try to achieve when transmitting video or sending video to storage.
- Max: This is the maximum bit rate the encoder will produce and place on the network. If for some reason the bandwidth on the network is reduced or the scene activity increases and the max bit rate has been achieved, the encoder will automatically reduce resolution of the encoder’s I-Frames and P-Frames to ensure full frame rate video is supplied. ….. if full frame rate cannot be sustained the DSP will reduce resolution and frame rate to get the video down the pipe
CBIT does speak directly to the DSP, but so that the DSP can tune how it produces the image… iDNR on the other hand changes the compression that is utilzed in low light settings between spatial and temporal… it does this based on three factors :
- CBIT movement analysis
- Light levels in the scene
- User set levels
Neither CBIT or iDNR will change the GOP…. The GOP will have one I Frame (anchor Frame) and the rest of the GOP will be P Frames (predictiable frames, or better known as macro blocks : 16x16 luminecent areas….. the only other way a GOP will change is if you manually force B Frames into it ... the Zipstream (white) paper uses the “forensic” phrase to say that it is intelligently/selectively dropping I-Frames .. from a forensic standpoint that could lead to calling evidentiary video into question …. If you miss something because you dropped the only I Frame in a GOP, then all you have is P-Frames which are updates. So how do I know if I missed something or not if (the customer) is doing UDP … an I-Frame could be dropped due to network congestions and now the remaining P-Frames = ?
The beginning of a GOP is the I Frame …. This is the base and foundation of viewable video, and without an I Frame in the proper place P Frames amount to usually useless video. Based on the ZIP Document from AXIS they are achieving low bit rates and storage by compressing. This is based on :
- Scene motion
- Scene content
- Ambient light level
- Configuration options:
This part basically equates to Bosch's CBIT and iDNR technology: since I don’t have this AXIS camera I can’t test it in my lab, all I have to go by is their documentation.
Configuration Options:
- Compression parameter
- Group of Pictures (GOP) length
- Frame rate
- Strength parameter
- Dynamic GOP parameter
- Dynamic GOP limitation parameter
After reading their documentation I am assuming the following:
They do a Dynamic ROI, this equates to our Encoder Regions which is a separate optional feature . Theirs does it automatically we set ours manually because it is a separate feature but works in concert with CBIT and IDNR. This is important due to the following: if their camera is auto detecting what it thinks is insignificant and reducing the resolution of that area on its own it could be detrimental from an evidentiary video standpoint. (I know I bring this up a lot, but from my perspective the sole purpose of video is evidence and its admissibility in court)
I appreciate the sentiment in the response, but here are my concerns: The GOP length and Dynamic Parameters coupled with compression. The end game of how they are doing things is encode the video, extend the length of the GOP by changing I Frame distance and crushing the P Frames with compression. The camera makes the decision to produce more I frames when needed based on Motion.
In a lab I am sure this works like a champ. Even my Bosch colleagues in Germany don’t like my answers sometimes.
In a real world deployment with 300 cams (equates to moderate network traffic), and I am assuming that we are in a NVR scenario, if you have 150 of these Axis cameras kick to high frame rate at one time:
o Do I drop an I frame because of network congestion: if you are doing UDP (not TCP) the I Frame is gone
o Does the NVR app corrupt the current video file because it only has P Frames (uselsss data with out an I Frame)
o If multiple cameras are all assigned to the NVR, does it cause the NVR to hiccup with the sudden change in traffic from all of its cameras? There are a ton of factors: are we doing Verint / Sec Center / Milestone…. What hardware is deployed, what is the network design, unicast or multicast, stacked switches, using Cisco or Brocade, how many streams per camera?
With the Bosch solution you can adjust the GOP length, we do set it standard for iSCSI recording, as we don’t not record to an NVR app with our solution…. Bosch doesn’t record video files we record raw data … I just wrote a paper for the NSA and the FBI on this topic.
So there are other mitigating factors that come into play with how we deploy and set our features up.
If you are interested in more "Tech Talk", subscribe to our weekly tech newsletter here.
