Case Study: ONVIF Edge Gateway with Edge AI 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, "reinstall it and see" is not an available diagnostic step, and intelligent processing had to run at the edge, next to the cameras, not in a distant data centre.

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 — together with local, intelligent processing of the video itself. That meant the platform had to work across several disciplines at once — embedded software, IP networking, video protocols, computer vision 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, ONVIF and edge-processing 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, device-management and analysis 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.

Edge AI: computer vision next to the camera

A key part of the project was running computer-vision and AI processing close to the video source, on the gateway itself, rather than relying entirely on centralised processing.

That is easy to say and hard to do on embedded hardware. The engineering covered acquiring camera video at the edge, feeding it into the computer-vision pipeline, processing it locally, and integrating the results with the wider gateway and software architecture — while keeping the video handling itself reliable alongside the inference workload. On constrained edge hardware, an analysis pipeline that starves the streaming path is worse than no analysis at all, so performance optimisation was a workstream in its own right, not an afterthought.

The architectural argument for edge processing is the same one that applies to any large camera estate: video is heavy, events are light. Processing near the source means the network carries what matters, latency stays low, and the platform's operating cost does not scale with every additional stream shipped to a central processor.

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 — including PTZ cameras — 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

IP/PTZ cameras → ONVIF / RTSP → embedded OpenWrt gateway → edge AI / computer vision → video & event processing → SSM / IP network → wider CCTV platform

Each arrow in that chain is a discipline: device interfaces, standards implementation, video protocols, computer vision, 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 — against real CCTV hardware, not simulators alone.

Faults could originate in embedded applications, device configuration, ONVIF behaviour, network configuration, multicast routing, streaming configuration, camera behaviour, the analysis pipeline 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, edge processing and multicast operation:

• Working ONVIF device functionality and CCTV/video device integration
• Edge AI / computer-vision processing running on the gateway alongside live video handling
• Stable Source Specific Multicast operation
• Operational real-time video streaming
• Embedded OpenWrt platform integration with successful device-handler integration
• System-level verification against physical CCTV equipment — 38 passing tests with live streaming operational on the integrated platform

Technologies

• Embedded — C/C++, embedded Linux, OpenWrt
• Video — ONVIF, RTSP, RTP, IP video, PTZ device control
• Edge AI — computer-vision pipelines, edge inference, performance optimisation on constrained hardware
• Networking — TCP/IP, UDP, multicast, Source Specific Multicast, IGMP
• Engineering — device integration, gateway development, alarm/relay integration, 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, computer vision, networking, video protocols and physical devices at once — camera interoperability, an edge gateway, IP video, edge AI and reliable network integration in one platform — 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, edge-AI analytics, 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.