WebRTC wird zunehmend für den Aufbau browserbasierter Einsatzkonsolen für Einsatzleitung, konvergierte Kommunikation, industrielle Steuerung, öffentliche Sicherheit und Fernbetrieb eingesetzt. Seine Echtzeit-Audio- und Videofähigkeiten ermöglichen es, Anruf-, Konferenz-, Befehlsfunktionen und Multimedia-Kommunikation in einer Weboberfläche zu vereinen, ohne dass die Bediener einen herkömmlichen Desktop-Client installieren müssen.

Die Herausforderung tritt auf, wenn die Einsatzplattform auch Videos von bestehenden Überwachungssystemen, tragbaren Überwachungskameras, Drohnen, am Körper getragenen Geräten oder Videoplattformen Dritter anzeigen muss. Diese Systeme können unterschiedliche Codecs, Transportprotokolle, Auflösungen, Bildraten und Streaming-Formate verwenden. Ein Videostream, der innerhalb einer Überwachungsplattform korrekt funktioniert, kann daher möglicherweise nicht direkt in einer WebRTC-Einsatzkonsole abgespielt werden. Die praktische Lösung besteht nicht darin, die gesamte Einsatzanwendung neu zu entwerfen, sondern eine Medienkonvertierungs- und Protokollanpassungsschicht zwischen der Videoquelle und der browserbasierten Konsole zu platzieren.

Warum der Videozugriff schwierig wird

Ein modernes Einsatzsystem ist selten auf Sprache beschränkt. Bediener müssen möglicherweise Anrufe entgegennehmen, mit Außendienstmitarbeitern kommunizieren, CCTV-Feeds überwachen, eine Drohnenkamera betrachten, an einer Videokonferenz teilnehmen und einen Einsatzort von derselben Workstation aus inspizieren. Daher wird erwartet, dass das System Kommunikationsressourcen verbindet, die ursprünglich unabhängig voneinander entwickelt wurden.

WebRTC eignet sich besonders gut für interaktive Browserkommunikation. Es bietet Medienübertragung mit geringer Latenz und wird häufig für browserbasierte Audio-, Video- und Konferenzanwendungen eingesetzt. Eine um WebRTC herum aufgebaute Einsatzkonsole kann Kommunikationssteuerungen über eine Standard-Webschnittstelle bereitstellen und lässt sich einfacher in andere Geschäftsanwendungen integrieren als ein geschlossener Desktop-Client.

Die Überwachungsinfrastruktur folgt jedoch einer anderen technischen Entwicklung. Kameras, Netzwerk-Videorekorder, Videomanagementsysteme, tragbare Überwachungsterminals, Drohnen und branchenspezifische Überwachungsplattformen können Streams über GB/T28181, RTSP, RTP, RTMP, HLS, SIP oder andere Schnittstellen bereitstellen. Sie können auch Videocodecs verwenden, die in erster Linie für Speichereffizienz und nicht für die Browserwiedergabe ausgewählt wurden.

Das daraus resultierende Problem ist eine Interoperabilitätslücke. Die Videoquelle ist verfügbar, die Einsatzkonsole funktioniert normal und die Netzwerkverbindung ist intakt, aber der Browser kann den Stream in seiner ursprünglichen Form dennoch nicht dekodieren oder konsumieren.

Verwandtes Produkt: Becke Einsatzkonsole

Wo H.265 eine Kompatibilitätslücke schafft

Eines der häufigsten Integrationsprobleme tritt auf, wenn ein Überwachungssystem H.265-Video liefert. H.265, auch bekannt als HEVC, ist für Überwachungsanwendungen attraktiv, da es im Vergleich zu älteren Codierungsverfahren bei vergleichbarer Bildqualität Bandbreiten- und Speicheranforderungen reduzieren kann. Bei großen Kamerainstallationen kann diese Effizienz wertvoll sein.

Das Problem ist, dass die H.265-Wiedergabeunterstützung in typischen WebRTC- und Browserumgebungen nicht durchgängig verfügbar ist. Eine Überwachungsplattform kann daher einen vollkommen gültigen H.265-Stream bereitstellen, der von der am Einsatzort verwendeten WebRTC-Anwendung nicht direkt konsumiert werden kann.

Es ist normalerweise unpraktisch, alle Kameras auszutauschen oder die gesamte Überwachungsplattform zu ändern, nur um den Browser zufriedenzustellen. Auch die Anpassung der Einsatzkonsole an jeden möglichen Codec eines Drittanbieters erzeugt unnötige Entwicklungskomplexität. Ein besser handhabbarer Ansatz besteht darin, die Medien zu normalisieren, bevor sie WebRTC erreichen.

In dieser Architektur empfängt ein Videotranscoding-Dienst den ursprünglichen H.265-Stream und wandelt ihn in H.264 oder ein anderes von der Ziel-WebRTC-Umgebung unterstütztes Format um. Die Einsatzkonsole konsumiert dann den konvertierten Stream, anstatt zu versuchen, das ursprüngliche H.265-Medium direkt zu dekodieren.

Diese Trennung ist wichtig, da sie die Medienkompatibilität außerhalb der Kern-Einsatzanwendung hält. Die Browserschnittstelle kann ihren normalen WebRTC-Workflow weiterhin verwenden, während das Gateway die Codec-Anpassung im Hintergrund übernimmt.

Eine praktische Transcoding-Gateway-Architektur

Ein Videotranscoding-Gateway fungiert als Medienbrücke zwischen Überwachungsressourcen und der WebRTC-Einsatzschicht. Seine Rolle ist umfassender als die einfache Codec-Konvertierung. In einem echten konvergierten Kommunikationsprojekt muss es möglicherweise Streams von mehreren Videoplattformen empfangen, Medienparameter konvertieren, Streams neu verpacken und sie in einem für das Einsatzsystem nutzbaren Format veröffentlichen.

Ein typischer Workflow kann in fünf Phasen unterteilt werden:

1. Die Einsatzplattform fordert eine bestimmte Kamera, Drohne, tragbare Überwachungseinrichtung oder Videoressource eines Drittanbieters an.

2. Das Gateway erhält den Quellstream über das verfügbare Überwachungs- oder Streaming-Protokoll.

3. Der Mediendienst prüft den eingehenden Codec, die Auflösung, die Bildrate, die Bitrate und das Stream-Format.

4. Bei Bedarf wird das Video in ein für die WebRTC-Umgebung geeignetes Format transcodiert oder neu verpackt.

5. Die konvertierten Medien werden zur Echtzeitbetrachtung an die browserbasierte Einsatzkonsole geliefert.

Bei einer H.265-Quelle ist der wichtigste Schritt typischerweise die H.265-zu-H.264-Konvertierung. In anderen Projekten ist der Codec möglicherweise bereits kompatibel, aber die Auflösung, Bitrate, Bildrate oder Protokollverpackung müssen möglicherweise dennoch angepasst werden.

Diese Architektur reduziert auch die Kopplung zwischen Systemen. Die Überwachungsplattform muss nicht verstehen, wie die Einsatzschnittstelle implementiert ist, und die WebRTC-Anwendung muss keine dedizierte Logik für jeden Kamerahersteller oder jedes Streaming-Format enthalten. Jede Seite verbindet sich mit einer speziell für Interoperabilität entwickelten Medienanpassungsschicht.

Protokollzusammenspiel zwischen Videosystemen

Die Codec-Konvertierung löst nur einen Teil des Integrationsproblems. Unterschiedliche Systeme können auch unterschiedliche Signalisierungs- und Transportprotokolle verwenden. Ein vollständiges Video-Gateway muss daher sowohl Protokollanpassung als auch Medienverarbeitung durchführen.

Häufige Schnittstellen in Einsatz- und Überwachungsumgebungen sind GB/T28181, RTSP, RTP, RTMP, FLV, HLS, SIP und WebRTC. Ihre Zwecke sind nicht identisch. Einige werden für den Zugriff auf Überwachungsgeräte und deren Steuerung verwendet, einige für den Echtzeit-Medientransport, einige für die Streaming-Verteilung und andere für die Sitzungssignalisierung oder Browserkommunikation.

Ein zwischen diesen Systemen positioniertes Gateway kann einen Stream in einem Format empfangen und über eine andere von der Einsatzplattform benötigte Schnittstelle bereitstellen. Beispielsweise kann auf eine Überwachungskamera über RTSP zugegriffen werden, während eine bestehende Überwachungsplattform Ressourcen über GB/T28181 bereitstellt. Die Einsatzanwendung muss diese Protokolle nicht direkt konsumieren, wenn das Gateway sie in einen WebRTC-kompatiblen Bereitstellungspfad umwandelt.

Ein integrierter Streaming-Dienst kann auch das Abrufen und Veröffentlichen von Streams verwalten. Wenn ein Bediener eine Kamera auswählt, kann das System einen Abrufvorgang von der Quellplattform initiieren, die Medien verarbeiten und den resultierenden Stream zur Einsatzkonsole veröffentlichen. Dies vermeidet die Aufrechterhaltung unnötiger Streams, wenn eine Ressource nicht betrachtet wird.

Dieselbe Architektur ist auch über CCTV hinaus nützlich. Tragbare Überwachungskameras, Drohnenvideo, Videotelefone, Konferenzsysteme und andere Echtzeit-Medienressourcen können alle über verschiedene Protokolle in die einheitliche Einsatzumgebung gelangen. Ein protokollbewusstes Gateway bietet einen gemeinsamen Punkt für die Handhabung dieser Unterschiede.

Bereitstellungs-Workflow für reale Projekte

Ein erfolgreiches Integrationsprojekt sollte mit der vorhandenen Videoumgebung beginnen, nicht nur mit der WebRTC-Schnittstelle. Die erste Aufgabe besteht darin, zu identifizieren, welche Ressourcen angezeigt werden müssen und wie diese Ressourcen derzeit bereitgestellt werden.

Bestehende Videoquellen erfassen

Das Projektteam sollte Überwachungsplattformen, fest installierte Kameras, tragbare Kameras, Drohnen, Konferenzsysteme, Videotelefone und alle anderen relevanten Quellen auflisten. Für jede Ressource sollten das verfügbare Protokoll, der Codec, die Auflösung, die Bildrate, die Authentifizierungsmethode und der Netzwerkstandort dokumentiert werden.

Signalisierung von Medien trennen

In einigen Systemen bestimmt die Signalisierung, auf welches Gerät zugegriffen werden soll, während Medien über ein anderes Protokoll transportiert werden. Die Behandlung von Signalisierung und Medien als separate Integrationsebenen erleichtert die Fehlersuche. Eine Kamera kann sich erfolgreich registrieren und gesteuert werden, während ihr Videostream aufgrund von Codec- oder Transportinkompatibilität dennoch ausfällt.

Nur bei Bedarf normalisieren

Transcoding verbraucht Rechenressourcen und kann zusätzliche Verarbeitungsverzögerungen verursachen. Ein praktisches Gateway sollte daher unnötige Konvertierungen vermeiden. Wenn die Quelle bereits einen von der WebRTC-Umgebung akzeptierten Codec und ein akzeptiertes Medienprofil verwendet, können Neuverpackung oder Weiterleitung ausreichen. Vollständiges Transcoding sollte nur bei echten Inkompatibilitäten von Codec oder Medienparametern eingesetzt werden.

On-Demand-Stream-Abruf verwenden

Große Überwachungssysteme können Hunderte oder Tausende von Kameras enthalten, aber ein Einsatzbediener betrachtet normalerweise jeweils nur eine kleine Teilmenge. Das Starten eines Streams nur auf Anforderung des Bedieners kann Bandbreite, Medienverarbeitungslast und unnötigen Serverressourcenverbrauch reduzieren.

Den Bediener-Workflow einfach halten

Die Medienkonvertierung sollte für den Einsatzbediener unsichtbar bleiben. Idealerweise wählt der Bediener eine Kamera aus einer Kontaktliste, einer GIS-Karte, einer Einsatzseite oder einem Videoresourcen-Panel aus und das Bild öffnet sich direkt. Die Protokollauswahl, Codec-Konvertierung, Stream-Einrichtung und Wiederherstellung sollten vom Backend übernommen werden.

Zuverlässigkeit und Medienqualität sind wichtig

Einen Stream sichtbar zu machen ist nur der erste Schritt. Einsatz- und Industrieanwendungen benötigen auch stabiles Video unter sich ändernden Netzwerkbedingungen. Eine brauchbare Mediaschicht sollte daher mehr als nur den Codec anpassen können.

Die Auflösungsanpassung kann nützlich sein, wenn eine hochauflösende Kamera in einem kleineren Einsatzfenster angezeigt oder über eine eingeschränkte Netzwerkverbindung übertragen werden muss. Die Bildratenkonvertierung kann die Verarbeitungs- und Bandbreitenanforderungen für Überwachungsszenarien reduzieren, in denen extrem hohe Bildraten nicht erforderlich sind. Die Bitratensteuerung kann helfen, die Kontinuität aufrechtzuerhalten, wenn die verfügbare Netzwerkkapazität schwankt.

Diese Fähigkeiten sind auch nützlich, wenn zwei Videosysteme unterschiedliche Medienprofile verwenden, obwohl beide nominell H.264 unterstützen. Unterschiede in Auflösung, Profil, Bildrate, Bitrate oder Paketierung können dennoch eine reibungslose Interoperabilität verhindern.

Das Media-Gateway kann daher als Normalisierungspunkt zwischen Videotelefonen, Konferenzplattformen, CCTV-Systemen, Drohnen-Feeds und browserbasierten Einsatzanwendungen dienen. Anstatt zu verlangen, dass jedes Subsystem direkt mit jedem anderen Subsystem übereinstimmt, benötigt jedes System nur eine zuverlässige Verbindung zum Gateway.

Das Netzwerkdesign sollte auch Verzögerung, Paketverlust, Stream-Wiederherstellung, Authentifizierung, Zugangskontrolle und Anforderungen an gleichzeitige Betrachtung berücksichtigen. Ein Einsatzzentrum benötigt möglicherweise mehrere Bediener, um dieselbe Quelle zu betrachten, während ein Vorfall möglicherweise plötzlich das gleichzeitige Öffnen mehrerer Videoresourcen erfordert. Die Kapazitätsplanung sollte realistische Spitzen-Workloads widerspiegeln, nicht nur einen einzelnen Teststream.

Abschließende Bemerkungen

WebRTC bietet eine effektive Grundlage für browserbasierte Einsatzkonsolen, aber reale Einsatzsysteme müssen weit mehr als nur native WebRTC-Endpunkte verbinden. CCTV-Plattformen, Drohnen, tragbare Überwachungsgeräte, Konferenzsysteme und ältere Videoressourcen führen oft unterschiedliche Codecs und Streaming-Protokolle ein.

H.265 ist eine besonders häufige Quelle von Inkompatibilität. Anstatt die Einsatzkonsole neu zu entwerfen oder vorhandene Überwachungsgeräte auszutauschen, kann ein Media-Transcoding-Gateway den ursprünglichen Stream empfangen, bei Bedarf H.265 in H.264 konvertieren, Auflösung, Bildrate und Bitrate anpassen und das Ergebnis über einen WebRTC-kompatiblen Pfad bereitstellen.

Wenn dasselbe Gateway auch Schnittstellen wie GB/T28181, RTSP, RTP, RTMP, FLV, HLS, SIP und WebRTC unterstützt, wird es zu einer praktischen Interoperabilitätsschicht für eine breitere konvergierte Kommunikationsarchitektur. Das Ergebnis ist ein Einsatz-Workflow, bei dem Bediener auf heterogene Videoressourcen über eine einzige Schnittstelle zugreifen können, während Codec-Konvertierung und Protokollanpassung im Hintergrund bleiben.

FAQ

Sollte jeder Überwachungsstream dauerhaft konvertiert werden, bevor ein Bediener ihn anfordert?

Normalerweise nicht. Bei großen Installationen ist die bedarfsgesteuerte Verarbeitung oft effizienter. Der Mediendienst kann mit dem Abruf und der Anpassung eines Streams beginnen, wenn ein Bediener die entsprechende Ressource öffnet, und dann die Verarbeitungskapazität freigeben, wenn der Stream nicht mehr benötigt wird.

Kann derselbe Kamerastream an mehrere Einsatzbediener geliefert werden?

Ja, vorausgesetzt, die Streaming-Architektur ist für die 1-zu-viele-Verteilung ausgelegt. Ein Mediendienst kann eine Quelle einmal empfangen und die verarbeitete Ausgabe an mehrere autorisierte Betrachter verteilen, anstatt für jeden Bediener eine separate Upstream-Verbindung zu öffnen.

Wie sollten Videozugriffsberechtigungen verwaltet werden?

Der Kamerazugriff sollte normalerweise den Benutzer- und Rollenberechtigungen der Einsatzplattform folgen. Bediener dürfen möglicherweise nur bestimmte Regionen, Einrichtungen, Kameragruppen oder einsatzbezogene Ressourcen anzeigen, während Administratoren umfassendere Steuerungs- und Konfigurationsrechte erhalten können.

Was passiert, wenn die ursprüngliche Videoquelle vorübergehend nicht verfügbar ist?

Die Einsatzanwendung sollte einen klaren Offline- oder Wiederverbindungsstatus erhalten, anstatt unbegrenzt ein eingefrorenes Bild anzuzeigen. Das Backend kann gemäß definierten Wiederholungsrichtlinien erneut verbinden und den Stream automatisch wiederherstellen, sobald die Upstream-Quelle wieder verfügbar ist.