We tend to believe that only the IP camera will dedicate how much bandwidth is required and not the VMS/NVR, but it’s not entirely true.
Recently I did very simple test to measure the efficiency of Omnicast versus another well-known product. Using a video amplifier, I hook a single camera to 2 ports of an Axis Q7406. Because the Q7406 expose 1 IP address per video port, I have been able to assign each video port to different software. Then I configured the same video quality settings in both products and measure the bandwidth between the encoder and the NVR using Wireshark.
Depending of the scene and frame rate, I found situation where Omnicast was using 2-3x less bandwidth and storage than a competing Product. In all scenarios I tested, Omnicast was always more efficient. Obviously I inverted the video port to make sure it was not introduced by the encoder.
Initially, I suspected a configuration error and started looking at the differences; both products had the same resolution, same quality, same frame rate… but only Omnicast gives the flexibility to configure the key Frame Interval (I-Frame Interval) and the default value was 4 seconds (30 FPS) but it can go up to 20 seconds.
Figure 1 - Omnicast Video Configuration page (Axis H.264)
The configuration interface of Product X didn’t expose anything to configure the I-Frame frequency (GOP Size). In fact I confirmed that this product absolutely requires 1 I-Frame every second.
When Product X is recording a camera at 2 FPS, 1 frame out of 2 is an I-Frame, it’s a terrible waste of bandwidth because I-Frames can be 50X bigger than P-Fame… As you may already know, I-Frame contains the entire picture while P-Frame only the differences with the previous frame.This paper from Axis gives a very good overview of compression technologies.
Next time you use an NVR/VMS, take a look at the video configuration page to see if the product supports variable GOP size (I-Frames frequency).
Posts
3 comments:
Hi Jo, Reductions in bandwidth from I frame settings make sense. However, the risk of generating more infrequent I frames is a loss of quality, especially during times of complex movement (a panning PTZ is a worse case scenario).
I think it's valuable that Genetec supports I-frame setting adjustment, however I question whether your lower bandwidth consumption is not at the expense of lower video quality (especially during periods of high motion). This will depend on what the camera is viewing but I think this is a real and important risk (and potential tradeoff).
Thoughts?
Hi John,
I have never noticed a quality differences during my test with fix and mobile H.264 cameras.
Nothing in the MPEG-4/H.264 standard prevent the encoder to use I-Macroblocks instead of P-Macroblocks when there's a lot of motion, I have seen it in many implementations. That's why the bitrate increase a lot when you move a dome.
Do you have specific camera manufacturers in mind when you mentionned a loss of quality?
Using some MPEG-4 domes, I observed situations where the dome only send 26 to 28 FPS at 4CIF when the I-Frame interval is set to 1 seconds (GOP Size 30) versus 30 FPS at 4CIF with a I-Frame interval >= 4 seconds.
Hi Jo,
I have seen it in a number of cameras and encoders. Lowering the i frame rate often causes significant macroblocking/artifacting. I agree it depends on implementation and have not tested this specifically. However, from field deployments, I have seen this issue. As an example, we had a PTZ with significant quality problems every time it was panned. By increasing the i frame rate (from 1 per to second to 5 per second), the issue went away. It seemed from the visual results that the encoder was fixed at the i frame rate and would not go beyond what was set.
Beyond that, the whole premise of changing a configuration setting to reduce bandwidth consumption by 2-3x without any tradeoffs sounds 'too good to be true'. My example above is one practical issue I have seen with variances to such a setting.
This is definitely an interesting topic.
Post a Comment