Dynamic Stream Selection 2.0
Moderne Videomanagementsysteme stehen vor einem grundlegenden architektonischen Kompromiss:
Einerseits steigt die Anzahl der pro Client gleichzeitig angezeigten Kameras kontinuierlich an (z. B. große Kontrollräume mit Dutzenden von Streams), andererseits nehmen die Kameraauflösungen und Bitraten stetig zu.
Herkömmliche Streaming-Architekturen, insbesondere Single-Stream- oder einfache Dual-Stream-Ansätze, stoßen auf physikalische Grenzen auf GPU-, CPU- und Netzwerkebene.
Dynamic Stream Selection 2.0 (DSS 2.0) adressiert genau dieses Problem durch eine konsequente Entkopplung von Stream-Erzeugung, Stream-Verarbeitung und Stream-Nutzung.
Grundprinzip von DSS 2.0
DSS 2.0 basiert auf einem klaren Architekturprinzip:
Die Auswahl des Videostreams erfolgt nicht mehr beim Eingang (Kamera zu Server), sondern erst beim Ausgang (Server zu Client).
Kernelemente:
- Die Kamera liefert bis zu vier parallel konfigurierbare Streams an den Server
- Diese Streams unterscheiden sich typischerweise in der Auflösung (z. B. niedrig, mittel, hoch, sehr hoch)
- Alle Streams werden permanent an den Server übertragen, sofern sie konfiguriert sind
- Der Server entscheidet dynamisch und individuell pro Verbraucher, welcher Stream ausgeliefert wird
Clients sind dabei:
- Operator-Viewer (z. B. G-View, G-SIM Clients)
- Web-Clients (Web API / WebSocket Streaming)
- Videoanalyse (z. B. G-Tect)
- Aufzeichnung (permanent oder ereignisbasiert)
Client-spezifische Stream Auswahl
Jeder Client übermittelt beim Anfordern eines Videos:
- die tatsächliche Größe seines Viewers (Pixelmaß)
- optional weitere Präferenzen (z. B. Qualitäts- vs. Performance-Priorisierung)
Basierend auf diesen Informationen wählt DSS 2.0 mithilfe einer Approximationsmethode den am besten geeigneten Stream aus.
Die Entscheidung eines Clients hat keinen Einfluss auf andere Viewer derselben Kamera.
Beispiel
- Ein Operator öffnet eine Kamera im Vollbild (4K erforderlich).
- Parallel verarbeitet die Videoanalyse weiterhin einen niedrig aufgelösten Stream.
- Andere Operatoren sehen dieselbe Kamera in einer anderen Auflösung.
Kein Client zwingt andere Clients zu einer höheren Auflösung.
DSS 2.0
- Streams sind ständig verfügbar
- Umschaltung erfolgt intern und nahtlos
- Keine Encoder-Neukonfiguration auf der Kamera
- Auch mit zwei Streams bereits deutlicher Performance-Gewinn
Wesentlicher Unterschied zu Dual Stream:
Alle konfigurierten Streams laufen dauerhaft, damit Umschaltungen ohne Verzögerung oder Lücken möglich sind.
Klassischer Dual Stream
Feste Zuordnung:
- Stream A: Recording
- Stream B: Live Betrachtung
Nachteile:
- Umschaltungen können Encoder-Resets verursachen.
- Potenzielle Aufzeichnungslücken bei Ereignissen.
- Kein clientindividuelles Verhalten.
- Kamera muss Streams on-the-fly umkonfigurieren, wenn Anforderungen wechseln.
Konfiguration und Voraussetzungen
Unterstützt wird DSS 2.0 von:
- Plugin Loader
- RTSP Universal Plugins
- E4 und E5 Plugins
Streams werden direkt über RTSP-URLs referenziert oder über den Plugin Loader auf der Kamera konfiguriert.
Alle Streams eines DSS-Sets müssen denselben Codec verwenden (z. B. H.264 oder H.265). Die Stream-Auswahl erfolgt primär nach Auflösung, nicht nach Framerate.
Netzwerkbandbreite
DSS 2.0 verschiebt den Bandbreitenbedarf:
Kamera zu Server:
Tendenziell höher, da mehrere Streams parallel übertragen werden. Abhängig von:
- Anzahl der Streams
- Auflösungen
- Bitratenprofilen der Kamera
Server zu Clients:
- Geringer, da Clients nur die tatsächlich benötigte Auflösung erhalten
Wichtig:
Die effektive Mehrbandbreite liegt nicht linear bei Faktor 4, sondern typischerweise im Bereich 1,5×–1,75×, abhängig von den Stream-Profilen.
System Resourcen
Der größte technische Vorteil von DSS 2.0 liegt in der drastischen Reduktion der Dekodierlast (CPU/GPU).
- Kleine Viewer dekodieren kleine Streams.
- Große Viewer dekodieren große Streams.
- Keine unnötige 4K-Dekodierung für Miniaturansichten.
Praxisbeispiel:
35 Kameraviewer auf 3 Monitoren.
Vor DSS 2.0:
- GPU-Auslastung: ~90–100
- Ruckelnde Darstellung
Nach Umstellung auf DSS 2.0 (zwei Streams/Kamera):
- GPU-Auslastung: ~40–45 %
- Flüssige Darstellung
- Volle Auflösung bei Doppelklick auf Einzelbild
Einschränkungen (absichtlich)
DSS 2.0 unterscheidet derzeit nicht zwischen identischen Auflösungen mit unterschiedlichen Frameraten.
Use cases wie:
- niedrige FPS im Normalbetrieb
- hohe FPS bei Events
müssen weiterhin über klassische Mechanismen (z. B. Auflösungswechsel) gelöst werden.
Diese Einschränkung ist kein Defekt, sondern eine bewusste Entscheidung für Stabilität und Vorhersagbarkeit.
Zusammenfassung der Vorteile
Dynamic Stream Selection 2.0 bietet:
- Clientindividuelle Stream-Auswahl
- Massive Reduktion von GPU- und CPU-Last
- Deutlich bessere Skalierbarkeit von Viewstations
- Nahtlose Umschaltung ohne Encoder-Resets
- Optimale Nutzung von hohen Auflösungen dort, wo sie benötigt werden
- Klare Trennung von Aufnahme-, Analyse- und Anzeigeanforderungen
DSS 2.0 ist keine inkrementelle Verbesserung, sondern eine architektonische Neuausrichtung der Streamverteilung und wurde mit G-Core 8.2 eingeführt.