Ein Überwachungssystem kann für sich genommen einwandfrei funktionieren und dennoch schwierig an eine Kommando-Plattform, Webanwendung oder ein Drittsystem angebunden werden. Kameras, NVRs, Videomanagement-Plattformen, Drohnen und mobile Endgeräte können unterschiedliche Protokolle, Codecs, Stream-Formate, Auflösungen und Authentifizierungsmethoden verwenden. Ein Videogateway bietet eine kontrollierte Integrationsschicht zwischen diesen Systemen und ermöglicht die Wiederverwendung vorhandener Videoressourcen, ohne jede Plattform neu schreiben oder jedes Feldgerät austauschen zu müssen.

Warum eine Integrationsschicht oft notwendig ist

Videoprojekte werden selten zur gleichen Zeit erstellt oder von einem einzigen Hersteller geliefert. Ein Standort kann ein älteres Überwachungssystem mit H.264, ein neu installiertes Kameranetzwerk mit H.265, eine auf SIP und WebRTC basierende Kommando-Plattform und eine Geschäftsanwendung, die browserkompatibles Video erwartet, umfassen. Jedes System kann seine ursprüngliche Funktion korrekt erfüllen, aber die direkte Kommunikation zwischen ihnen ist nicht gewährleistet.

Die Unterschiede treten normalerweise in mehreren Bereichen auf:

• Geräteregistrierung und -authentifizierung

• Videosignalisierung und Stream-Steuerungsmethoden

• Kompatibilität von H.264, H.265 und anderen Codecs

• Zugriff über RTSP, RTMP, SIP, GB/T 28181 und herstellerspezifische SDKs

• Ausgabeanforderungen für FLV, HLS und WebRTC

• Einschränkungen bei Auflösung, Bildrate und Bitrate

• Audio-Unterstützung und Zwei-Wege-Kommunikation

• Wiedergabe im Browser, auf mobilen Endgeräten und auf Großbildschirmen

Die Anpassung jeder Kamera, jedes Rekorders und jeder Anwendung zur Behebung dieser Unterschiede kann einen erheblichen Entwicklungsaufwand verursachen. Sie kann auch Risiken in bereits zuverlässig laufende Systeme einbringen. Die Platzierung eines Gateways zwischen Quelle und Ziel schafft eine klarere Grenze: Die ursprünglichen Systeme behalten ihre etablierten Arbeitsabläufe, während das Gateway Zugriff, Konvertierung und Verteilung übernimmt.

Diese Architektur ist besonders nützlich, wenn eine Organisation bestehende Überwachungsinvestitionen erhalten und gleichzeitig Einsatzleitung, Notfallreaktion, IoT-Anbindung, Fernzugriff oder zentrale Verwaltung hinzufügen möchte.

Verteilte Kamerasysteme in eine einheitliche Betriebsansicht bringen

Organisationen mit mehreren Niederlassungen, Industriestandorten, Bahnhöfen, Werksgeländen oder entfernten Einrichtungen betreiben oft separate Überwachungssysteme. Kameras und NVRs bleiben unter lokaler Kontrolle, während ein regionales oder nationales Zentrum berechtigungsbasierten Zugriff auf ausgewählte Streams benötigt.

Ein Videogateway kann diese Ressourcen bündeln und mit einer übergeordneten Plattform verbinden. Je nach beteiligten Systemen kann der Zugriff GB/T 28181, RTSP, RTMP, ein SDK oder eine andere unterstützte Schnittstelle nutzen. Das Gateway stellt die erforderlichen Streams für die Zielplattform bereit, ohne jeden entfernten Standort zum Austausch seines vorhandenen Rekorders oder Kamerabestands zu zwingen.

Diese Anordnung kann mehrere Betriebsmodelle unterstützen:

• Zentrale Betrachtung von Kameras aus mehreren Niederlassungen

• Selektive Weitergabe wichtiger Streams an ein Kommandozentrum

• Videozugriff über private Netzwerke, WAN-Verbindungen oder VPN

• Integration bestehender Überwachung in eine neue GIS- oder Einsatzplattform

• Kontrollierte Verteilung einer Videoressource an verschiedene berechtigte Anwendungen

Das Gateway sollte nicht einfach als passive Netzwerkbrücke behandelt werden. Eine praktische Bereitstellung erfordert auch Gerätezuordnung, Stream-Statusüberwachung, Zugriffsberechtigungen, Verbindungsprotokolle und klare Benennung. Die Bediener sollten operative Namen wie "Kamera Nordtor", "Produktionslinie 2" oder "Tunneleingang" sehen, anstatt einer unerklärlichen IP-Adresse oder Kanalnummer.

Zentralisierung bedeutet nicht unbedingt, dass jeder Stream kontinuierlich übertragen werden muss. Für entfernte Standorte mit begrenzter Bandbreite kann die Plattform Video anfordern, wenn ein Alarm auftritt oder wenn ein Bediener eine Kamera auswählt. Haupt- und Unterströme können auch für verschiedene Zwecke verwendet werden: ein qualitativ hochwertiger Stream für Beweiszwecke oder Großbildbetrachtung und ein strom mit niedrigerer Bitrate für Vorschauen oder mobilen Zugriff.

Gleichzeitige Unterstützung von Kameras, Drohnen und Feldvideo

Moderne Kommandoprojekte verwenden mehr als nur fest installierte Überwachungskameras. Video kann von PTZ-Kameras, NVRs, Körperkameras, fahrzeugmontierten Endgeräten, Drohnen, intelligenten Helmen, tragbaren Rekordern, Video-Gegensprechanlagen und SIP-Videotelefonen stammen. Diese Geräte unterscheiden sich nicht nur im Protokoll, sondern auch darin, wie sie einen Stream initiieren, aufrechterhalten und beenden.

Ein Videogateway kann diese Quellen normalisieren, bevor sie an die Kommando-Umgebung übergeben werden. Feste Kameras können über ein Überwachungsprotokoll registriert werden, während eine Drohne oder ein mobiles Endgerät einen RTMP-Stream pushen kann. Eine Einsatzleitungskonsole kann Video über SIP anfordern, und eine Webanwendung kann FLV-, HLS- oder WebRTC-Ausgabe erfordern.

Häufige Integrationspfade umfassen:

• Abrufen von Live-Video von Kameras und NVRs über RTSP

• Empfangen von gepushtem Video von Drohnen oder mobilen Geräten über RTMP

• Anbinden von Überwachungsressourcen über GB/T 28181

• Verknüpfung von Video mit SIP-Anrufen, Gegensprech-Ereignissen oder Einsatzsitzungen

• Bereitstellung browserkompatibler Streams über WebRTC, HLS oder FLV

• Bereitstellung kontrollierter Schnittstellen für die Entwicklung von Drittanwendungen

Die Audio-Fähigkeit muss separat bestätigt werden. Ein Gerät, das Live-Video liefert, unterstützt nicht automatisch Audio, Gegensprechen oder SIP-Kommunikation. Wenn ein Projekt erfordert, dass der Bediener einen Ort sieht und mit Feldpersonal von derselben Oberfläche aus spricht, muss das Design Audiocodecs, Mikrofon- und Lautsprecherwege, Echobehandlung, Berechtigungen und Anrufsteuerungsverhalten überprüfen.

Dies ist in Kommandozentren wichtig, da Video normalerweise Teil eines umfassenderen Reaktionsprozesses ist. Ein Bediener kann eine nahegelegene Kamera öffnen, ein Feldendgerät anrufen, eine Konferenz starten, eine Durchsage versenden und den Vorfall von einer Workstation aus aufzeichnen. Das Gateway macht das Video verfügbar, während die Kommunikations- und Einsatzplattform den gesamten operativen Arbeitsablauf steuert.

Anpassung jedes Streams an sein Ziel

Protokollkonvertierung und Videotranscodierung lösen unterschiedliche Probleme. Die Protokollkonvertierung ändert, wie auf einen Stream zugegriffen, transportiert oder präsentiert wird. Die Transcodierung ändert die Medien selbst, wie Codec, Auflösung, Bildrate oder Bitrate. Manche Projekte benötigen nur die Weiterleitung von Streams, während andere beide Prozesse erfordern.

Ein häufiges Kompatibilitätsproblem tritt zwischen H.264 und H.265 auf. Viele etablierte Überwachungs- oder Kommunikationssysteme wurden um H.264 herum entworfen, während neuere Überwachungsinstallationen zunehmend H.265 verwenden, um Speicher- und Bandbreitenverbrauch zu reduzieren. Wenn ein Ziel den Quellcodec nicht dekodieren kann, muss der Stream vor der Anzeige transcodiert werden.

Eine Transcodierung kann auch erforderlich sein, wenn:

• Eine hochauflösende Kamera auf einem Endgerät mit niedrigerer Auflösung angezeigt werden muss

• Ein Stream mit hoher Bitrate eine begrenzte WAN- oder Mobilfunkverbindung durchqueren muss

• Ein Browser oder eine mobile Anwendung das ursprüngliche Medienformat nicht unterstützt

• Unterschiedliche Bildraten für Live-Überwachung und Aufzeichnung benötigt werden

• Eine Kommando-Plattform H.264 benötigt, während das Quellsystem H.265 ausgibt

• Ein Stream Überlagerungen, Zeitstempel, Maskierungen oder Wasserzeichenverarbeitung erfordert

Die Transcodierung verbraucht erheblich mehr Verarbeitungsressourcen als die Weiterleitung. Die Kapazität sollte daher anhand der Anzahl gleichzeitiger Streams, der Quellauflösung, der Ausgabeauflösung, der Codec-Konvertierung, der Bildrate und der erwarteten Betriebsdauer berechnet werden. Ein Gateway, das viele Kanäle weiterleiten kann, unterstützt möglicherweise weniger Kanäle, wenn die vollständige Transcodierung aktiviert ist.

Auch die Latenz muss berücksichtigt werden. Jede Dekodierungs-, Verarbeitungs- und Neukodierungsstufe fügt Verzögerungen hinzu. Die Überwachungsansicht kann mehr Latenz tolerieren als interaktive Einsatzleitung, Drohnensteuerung oder Videogegensprechanlage. Für Echtzeitanwendungen sollte die Architektur unnötige Konvertierungen minimieren und eine für die Anwendung geeignete Ausgabemethode wählen.

Verknüpfung von Video mit Alarmen und Geschäftsabläufen

Der Wert der Integration steigt, wenn Video Teil eines operativen Ereignisses wird und nicht nur ein isolierter Überwachungsbildschirm ist. IoT, Zutrittskontrolle, Perimeterschutz, Geräteüberwachung und Notfallkommunikationsplattformen können Video nutzen, um einen Alarm zu verifizieren und die nächste Aktion zu steuern.

Beispielsweise kann ein Gassensor in einem Industriegebiet einen abnormalen Wert melden. Die Anwendung identifiziert den Sensorstandort, fordert die zugehörige Kamera über das Gateway an und zeigt den Live-Stream dem diensthabenden Bediener an. Der Bediener kann dann das Personal vor Ort anrufen, einen Reaktionsablauf aktivieren oder eine Warnung über die Kommunikationsplattform senden.

Ähnliche Arbeitsabläufe können für folgende Fälle entworfen werden:

• Zutrittskontrollalarme, die mit Eingangskameras verknüpft sind

• Perimetervorfälle, die mit nahegelegenen PTZ-Kameras verbunden sind

• Gerätestörungen, die mit der Überwachung des Produktionsbereichs verknüpft sind

• Notfall-Gegensprechanrufe, die mit standortspezifischem Video verknüpft sind

• Verkehrsereignisse, die mit Straßen- und Tunnelkameras verbunden sind

• Mobile Teams, die Live-Video an eine Kommandokarte zurücksenden

• Drohnen-Streams, die während Inspektionen oder Notfallreaktionen angezeigt werden

Ein Gateway kann den innerhalb der Geschäftsanwendung erforderlichen videospezifischen Entwicklungsaufwand reduzieren. Anstatt für jede Kameramarke, jeden Rekorder und jedes Stream-Format separate Zugriffsmodule zu erstellen, verbindet sich die Anwendung mit einer normalisierten Medienschnittstelle und konzentriert sich auf ihren eigenen Arbeitsablauf, Benutzerberechtigungen und Ereignislogik.

Dieser Ansatz ist für intelligente Parks, Industrieanlagen, Bergwerke, Versorgungsbetriebe, Verkehrsnetze, Werksgelände, Gewerbeimmobilien und mehrstandortige Organisationen anwendbar. Die Geschäftsplattform bleibt für Alarme, Karten, Arbeitsaufträge und Reaktionsverfahren verantwortlich, während das Gateway den Videozugriff, die Medienanpassung und die Stream-Bereitstellung übernimmt.

Planung einer zuverlässigen Bereitstellung

Ein erfolgreiches Projekt beginnt mit einer Bestandsaufnahme der Quell- und Zielsysteme. Das Überprüfen einer Liste von Protokollnamen ist nicht ausreichend. Zwei Produkte können beide RTSP- oder GB/T 28181-Unterstützung beanspruchen und sich dennoch in Authentifizierung, Stream-Adressierung, Codec-Behandlung, Gerätekatalogstruktur oder Signalisierungsverhalten unterscheiden.

Das Planungsteam sollte Folgendes bestätigen:

• Anzahl und Art der Kameras, NVRs, Plattformen und mobilen Videoquellen

• Erforderliche Eingangs- und Ausgangsprotokolle

• Kompatibilität von Video- und Audiocodecs

• Maximale gleichzeitige Live-, weitergeleitete und transcodierte Streams

• Auflösung, Bildrate und Bitrate repräsentativer Quellen

• Wiedergabeanforderungen für Browser, mobile Geräte, Workstations und Videowände

• Erwartete Latenz für Überwachungs- und interaktive Anwendungen

• Benutzerauthentifizierung, Berechtigungen und Anforderungen an verschlüsselte Übertragung

• WAN-Bandbreite, Paketverlust und Netzwerk-Failover-Bedingungen

• Überwachung, Protokolle, Zeitsynchronisation und Wartungsverantwortlichkeiten

Ein Proof-of-Concept-Test sollte echte Geräte und repräsentative Streams verwenden. Er sollte die kontinuierliche Wiedergabe, die Wiederherstellung der Verbindung nach Netzwerkunterbrechungen, die Audiosynchronisation, die PTZ-Steuerung (falls erforderlich), die Browserkompatibilität und das Verhalten jedes Transcodierungsprofils überprüfen. Das Testen nur einer Kamera über einen kurzen Zeitraum repräsentiert keine mehrkanalige Produktionsumgebung.

Auch die Anforderungen an die Hochverfügbarkeit müssen definiert werden. Kritische Kommandoprojekte können redundante Gateways, mehrere Netzwerkschnittstellen, Plattform-Failover und Stream-Wiederherstellung nach Dienstunterbrechungen erfordern. Die lokale Überwachung sollte unabhängig weiterarbeiten, wenn die Verbindung zur übergeordneten Kommando-Plattform nicht verfügbar ist.

Ein Videogateway ist am effektivsten, wenn seine Rolle klar definiert ist. Es bietet Protokollanpassung, Stream-Zugriff, Weiterleitung, Transcodierung und Integrationsunterstützung, ersetzt jedoch nicht automatisch alle Aufzeichnungs-, Untersuchungs-, Alarmverwaltungs- und Beweissicherungsfunktionen eines vollständigen Videomanagementsystems. In vielen Projekten arbeiten die beiden Systeme zusammen.

Häufig gestellte Fragen

Kann ein Kamerastream mit mehreren Anwendungen geteilt werden?

Ja, wenn das Gateway Stream-Replikation oder Medienverteilung unterstützt. Das Gateway kann einen Quellstrom einmal abrufen und separate Ausgaben für berechtigte Anwendungen bereitstellen, wodurch die Notwendigkeit verringert wird, dass jede Anwendung eine eigene Verbindung zur Kamera herstellt. Die tatsächliche Kapazität hängt von der Ausgangsbandbreite und den Grenzen gleichzeitiger Sitzungen ab.

Benötigt ein Videogateway eine öffentliche Internetverbindung?

Nein. Es kann vollständig in einem LAN, privaten WAN oder isolierten Netzwerk betrieben werden. Internetzugang ist nur erforderlich, wenn entfernte Benutzer, Cloud-Dienste oder externe Plattformen Video über eine Internetverbindung empfangen müssen.

Warum kann ein Stream in einem Desktop-Client abgespielt werden, aber nicht in einem Browser?

Desktop-Clients können proprietäre Codecs und Protokollkomponenten enthalten, die Browser nicht unterstützen. Die Browserwiedergabe erfordert normalerweise eine kompatible Übertragungsmethode wie WebRTC, HLS oder browserunterstütztes fragmentiertes Video. Der Stream muss möglicherweise vor der Anzeige protokollkonvertiert oder transcodiert werden.

Sollte jeder eingehende Stream transcodiert werden?

Nein. Wenn der Quellcodec und die Parameter bereits vom Ziel unterstützt werden, ist die direkte Weiterleitung effizienter und verursacht weniger Latenz. Die Transcodierung sollte nur aktiviert werden, wenn Kompatibilitäts-, Bandbreiten- oder Anzeigeanforderungen dies erforderlich machen.

Was sollte geschehen, wenn eine entfernte Netzwerkverbindung ausfällt?

Das lokale Überwachungssystem sollte weiterhin unabhängig aufzeichnen und arbeiten. Das Gateway und die übergeordnete Plattform sollten die Unterbrechung erkennen, den Offline-Status melden und den Streamzugriff nach der Netzwerkwiederherstellung automatisch wiederherstellen. Kritische Projekte können auch einen sekundären Übertragungsweg erfordern.