Case Study: CCTV and ONVIF Platform for UK National Infrastructure

Most video integration problems are not video problems. They are network problems, or device-behaviour problems, or standards-interpretation problems, and they only present as video problems because video is the thing that visibly stops working.

This engagement was a clear case. DevSpark engineering was applied to the development, integration and verification of an embedded CCTV and video communications platform operating within a UK national infrastructure environment — one where the network is tightly controlled, the equipment is multi-vendor, and "reinstall it and see" is not an available diagnostic step.

The problem shape

A national CCTV estate is not one system. It is cameras, encoders, gateways and management platforms from different manufacturers, each implementing the same standards with slightly different assumptions, all sharing a network nobody fully controls and which has operational constraints that a lab network does not.

The requirement was reliable interoperability between CCTV equipment and the wider video infrastructure, within those constraints. That meant the platform had to work across several disciplines at once — embedded software, IP networking, video protocols and physical device behaviour — because a fault could originate in any of them and present identically in all of them.

ONVIF: standards-based instead of proprietary

A significant part of the engagement was ONVIF communication between CCTV devices and the wider system.

The work covered ONVIF device integration and service implementation, device discovery and communication, media and streaming functionality, camera capability handling, and integration with external systems — plus the interoperability testing and compatibility investigation that inevitably follows.

The point of this was architectural rather than academic. It allowed components of the CCTV environment to communicate through a standards-based interface rather than a stack of proprietary integrations. That difference decides whether adding a camera model in three years is a configuration change or a development project.

Embedded Linux and OpenWrt as the platform

The gateway ran on embedded Linux with OpenWrt, extended to support the video, networking and ONVIF functionality the role required.

That covered OpenWrt platform development and configuration, application and service integration, network configuration, embedded application debugging, and hardware/software integration through to deployment and system testing.

The result was a compact embedded environment running the networking, video and device-management services in one place — which is the sensible shape for roadside and infrastructure equipment, where every additional box is another thing to power, house and maintain.

Source Specific Multicast, and why it earned its own workstream

Distributing video to multiple consumers without multiplying the bandwidth means multicast. On a shared national network it means Source Specific Multicast.

SSM lets a receiver subscribe to multicast traffic from a specified source rather than accepting traffic from any source in a multicast group. On a controlled network carrying multiple video sources, that distinction matters for both correctness and security — it is the difference between "give me the stream from this encoder" and "give me whatever is on this group".

The work covered multicast and SSM configuration and implementation, stream subscription handling, network configuration, and a substantial amount of testing and investigation of multicast communication problems. Stable SSM operation was achieved as part of system integration.

This is characteristically the area where video and networking expertise have to meet. A pure video engineer will not debug IGMP behaviour; a pure network engineer will not recognise why a stream fails to recover after a renegotiation.

Device handlers: keeping vendor quirks contained

Device handlers were developed to sit between physical video devices and the wider platform, managing device-specific behaviour while presenting the interface the rest of the system expected.

The purpose was containment. Without that layer, every quirk of every camera model leaks upward into application code, and the platform slowly becomes a collection of special cases. With it, higher-level applications stop depending on individual camera implementations — which is what makes a multi-vendor estate maintainable.

The gateway, end to end

CCTV devices → ONVIF services → video streaming → network transport → external CCTV systems

Each arrow in that chain is a discipline: device interfaces, standards implementation, video protocols, IP networking, system integration. The engagement required working across all of them rather than owning one layer and handing off — which is precisely the gap that leaves faults unresolved between suppliers, each correctly reporting that their own equipment is working.

Verification

Testing ran at device, software and integrated-system level: functional and ONVIF testing, network testing, video streaming validation, device integration testing, multicast and SSM testing, regression testing, fault reproduction, root-cause investigation and system stability testing.

Faults could originate in embedded applications, device configuration, ONVIF behaviour, network configuration, multicast routing, streaming configuration, camera behaviour or external system integration. The approach was therefore to analyse the complete communication chain rather than test each component in isolation — the only method that finds faults living in the gaps between components, which is where the expensive ones live.

Outcome

A functioning embedded CCTV integration platform with stable video streaming and multicast operation:

• Working ONVIF device functionality and CCTV/video device integration
• Stable Source Specific Multicast operation
• Operational real-time video streaming
• Embedded OpenWrt platform integration with successful device-handler integration
• System-level verification, with streaming demonstrated on the integrated platform

Technologies

Embedded — C/C++, embedded Linux, OpenWrt Video — ONVIF, RTSP, RTP, IP video Networking — TCP/IP, UDP, multicast, Source Specific Multicast, IGMP Engineering — device integration, gateway development, system integration, verification and validation, network diagnostics, hardware/software integration

What this means if you have a similar problem

The capability this engagement demonstrates is not "we know ONVIF". It is the ability to work a fault or a requirement across embedded software, networking, video protocols and physical devices at once, which is the combination most organisations cannot assemble from a single supplier.

That applies directly to IP cameras, NVRs and video management systems, smart and industrial cameras, traffic monitoring and transport infrastructure, security systems, edge video devices, embedded Linux gateways, ONVIF products, and multi-vendor video integration generally.

If you have equipment that works in isolation and fails in combination — or a stream that dies on one site and not another — that is the shape of problem this work was made of. It usually starts with a fixed-price diagnosis rather than a proposal.

Specific customer architecture and implementation details are not disclosed, in line with confidentiality obligations. This account describes the engineering scope and technologies only.