This is the 49th article in the “Real Words or Buzzwords?” series from SecurityInfoWatch.com contributor Ray Bernard about how real words can become empty words and stifle technology progress. Access Part Two and Part Three of this article in the Related Box on the right.
The primary purpose of this “Real Words or Buzzwords?” article series is to foster maximum technology progress – which includes optimum procurement and deployment of the right kinds of technologies – by clearing up misunderstandings and incomplete understandings of technology factors and the words relating to them.
This article set is about the H.264/H.265 MPEG video standards and how the configurations settings for video cameras stream configuration impact computing and networking requirements for security video deployments. There already are many security industry vendor documents on this topic, and much online information for security video as well as in the commercial and consumer video domains.
Nonetheless, several things prompted the writing of this article set:
- Video Deployment Issues. In my company’s security system deployment evaluation work we are still finding some video surveillance deployments whose camera configurations relating to vary significantly across the same make and model of camera, even though the fields of view and camera purposes and the networks involved are the same. This won’t happen if the technicians involved fully understand the video compression methods and their implications.
- Document Errors and Conflicts. The MPEG/H.264/265 standards have evolved over time, and some vendor documentation is outdated and contains a few now-incorrect statements.
- Insufficient Guidance. Installer and user documentation from camera and VMS vendors often assume the reader understands the compression method and don’t provide sufficient guidance about the use of related settings.
- Deployment Shortcomings. In recent technology evaluations of existing and new video deployments, we’re still seeing under-powered video servers with insufficient computer processing capabilities.
- Video Analytics. AI-based video analytics significantly increases the computing processing power and memory required for video servers.
Several companies do an outstanding job with video technology documentation, especially Axis Communications, Avigilon, IQinVision (now merged with Vicon), Milestone, OnSSI (recently merged with Qognify) and Salient Systems. But their video compression documentation – which is very good – doesn’t always include clear enough definitions along with how they relate to the whys and wherefores (the complete set of reasons) behind the various camera configuration settings relating to compression. Partly this is because in some documentation they are trying to keep the discussion higher level and avoid getting too deep into technical details, and partly because the documents address different topics relating to video compression.
Thus, you’d have to study multiple vendors’ materials, plus additional non-vendor references, and build your own mental model to get full clarity. An example of two non-vendor references that relate video technical details to video quality are the 40-page Digital Video Quality Handbook (2013) and the 50-page Digital Video Quality Handbook Appendix (2018), produced by the Video Quality in Public Safety initiative (VQiPS) initiative of the Science and Technology Directorate of the U.S. Department of Homeland Security. I highly recommend those two references for anyone designing or maintaining security video surveillance systems.
Because the video encoding standards are still evolving, any vendor’s older documentation might conflict with a newer document from the same or a different vendor. Checking the date of the documents is one way to resolve such conflicts, although some vendors don’t include publication dates in all their documentation.
Additionally, DVD video standards place some limitations on DVD video that don’t apply to security camera streaming video. This is why some of the information found online applies only to commercial DVD video or commercial video streaming such as Vimeo, YouTube – and much user-generated content about video compression is written by video editors and producers who aren’t aware of security surveillance video applications and their requirements.
Plus, some online forums contain material from forum users that’s unintentionally incorrect or incomplete, and determining what’s right or wrong and applicable or inapplicable to a security video deployment isn’t easy unless you already have a full understanding of the current state of the MPEG video compression standards as they relate to such deployments.
These are some reasons why there are apparent conflicts within the breadth of information available online and in vendor documentation.
My purpose for this two-part article set is to have the shortest possible illustrated discussion that clarifies the handful of terms that are involved in security video camera stream configuration settings and explains why they are important. This includes the tradeoffs involved in video quality, server/workstation processing requirements, video stream bandwidth requirements, and video storage requirements.
Understanding these factors is key to optimizing existing video deployments so that the minimum required video quality can be achieved for each camera’s purpose, and the maximum utilization can be made of existing video deployment infrastructure.
About the Author:
Ray Bernard, PSP CHS-III, is the principal consultant for Ray Bernard Consulting Services (RBCS), a firm that provides security consulting services for public and private facilities (www.go-rbcs.com). In 2018 IFSEC Global listed Ray as #12 in the world’s top 30 Security Thought Leaders. He is the author of the Elsevier book Security Technology Convergence Insights available on Amazon. Mr. Bernard is a Subject Matter Expert Faculty of the Security Executive Council (SEC) and an active member of the ASIS International member councils for Physical Security and IT Security. Follow Ray on Twitter: @RayBernardRBCS.
