MicrocosmWorksInnovation und Architektur digitaler Kosmen
Ăśber unsKontakt
MicrocosmWorksInnovieren und Gestalten digitaler Kosmen

Bereitstellung von IT-Lösungen, die zählen. Wir sind leidenschaftlich für Technologie, Sicherheit und helfen Unternehmen, durch zuverlässige, innovative IT-Infrastruktur zu wachsen.

[email protected]
+91 7011868196
New Delhi, India

AI Wachstumszentrum

AI HubStartup-InnovationUnternehmensbeschleuniger

Lösungen

Alle LösungenWellness- & Fitness-AppsAI Video PlattformAI Agent Entwicklung

Ressourcen

EinblickeBranchenleitfädenAnwendungsfall-BlaupausenArchitektur-MusterFallstudien

Unternehmen

Ăśber unsKontaktUnsere Arbeit

Dienstleistungen

Digitale BeratungCloud-InfrastrukturSaaS-EntwicklungKI-EntwicklungVideotechnologie
ERP-EntwicklungZoho-AnpassungOdoo-EntwicklungSalesforce-IntegrationBenutzerdefinierte CRM-Entwicklung
QuickBooks-IntegrationIoT-LösungenBlockchain-Entwicklung
Cybersecurity-BeratungIT-Support - L3

© 2026 MicrocosmWorks. Alle Rechte vorbehalten.

DatenschutzrichtlinieNutzungsbedingungen
ZurĂĽck zu Fallstudien
AI SurveillanceVeröffentlicht June 22, 2026 · Aktualisiert June 22, 2026

RTSP-Streaming ĂĽber VPN mit Auto-Scaling-Restreaming, HLS-Bereitstellung und -Aufzeichnung

Eine Überwachungsplattform musste RTSP-Kamera-Feeds von entfernten Standorten sicher über VPN-Tunnel aufnehmen, sie für webbasierte Anzeige und AI-Verarbeitung restreamen, die Restreaming-Infrastruktur bedarfsabhängig auto-skalieren und Streams zur Archivierung aufzeichnen – und das alles bei geringer Latenz und zuverlässiger Konnektivität unter unvorhersehbaren Netzwerkbedingungen.

Ihr Projekt besprechen
vpn-rtsp-streaming-autoscale.webp
AI Surveillance
Domain
13
Technologies
7
Key Results
Delivered
Status

Die Herausforderung

Die Anbindung entfernter IP-Kameras an eine zentralisierte Cloud-Plattform fĂĽhrte zu mehreren Infrastrukturherausforderungen:

  • Netzwerksicherheit — RTSP-Streams der Kamera durchquerten das öffentliche Internet, wodurch Video-Feeds ohne VerschlĂĽsselung der Abfangung ausgesetzt waren
  • NAT/Firewall-Traversal — Kameras hinter Unternehmens-Firewalls und NAT konnten nicht direkt aus der Cloud erreicht werden
  • Restreaming-Overhead — Rohe RTSP-Streams mussten fĂĽr die browserbasierte Anzeige in webfreundliche Protokolle (HLS) umgewandelt werden, was eine dedizierte Transkodierungsinfrastruktur erforderte
  • Variabler Bedarf — Die Nachfrage nach Zuschauer- und AI-Verarbeitung schwankte den ganzen Tag ĂĽber, aber feste Restreaming-Server konnten nicht skalieren
  • Aufzeichnung im groĂźen MaĂźstab — Die kontinuierliche Aufzeichnung Dutzender Kamerastreams erforderte ein zuverlässiges Speichermanagement mit Aufbewahrungsrichtlinien
  • Stream-Zuverlässigkeit — VPN-Tunnel brachen bei Netzwerkinstabilität ab, was eine automatische Wiederverbindung erforderte, ohne die Stream-Kontinuität zu verlieren
  • Multi-Protokoll-Bereitstellung — Verschiedene Konsumenten benötigten unterschiedliche Protokolle: RTSP fĂĽr AI-Worker, HLS fĂĽr Web-Zuschauer und aufgezeichnete Segmente zur Archivierung

Unsere Lösung

Wir haben eine VPN-getunnelte RTSP-Streaming-Plattform mit einem VPN-Hub für sichere Kamera-Konnektivität, auto-skalierenden RTSP-Restreaming-Servern für die Multi-Protokoll-Bereitstellung, HLS-Verpackung für die Browser-Wiedergabe und kontinuierlicher Aufzeichnung mit Aufbewahrungsmanagement entwickelt.

Architektur

  • VPN Hub: Zentralisierter VPN-Server, der sichere Tunnel zu entfernten Kamerastandorten aufbaut
  • RTSP Ingest: Mit VPN verbundene Kameras veröffentlichen RTSP-Streams ĂĽber verschlĂĽsselte Tunnel
  • Restreaming Cluster: Auto-skalierende MediaMTX-Server fĂĽr RTSP-Relay, HLS-Konvertierung und Stream-Verteilung
  • HLS Packaging: Echtzeit-RTSP-zu-HLS-Konvertierung fĂĽr die Bereitstellung an Webbrowser
  • Recording Service: Kontinuierliche Stream-Aufzeichnung mit segmentbasiertem Speicher und Aufbewahrungsrichtlinien
  • Load Balancer: Verteilt Viewer- und AI-Worker-Verbindungen auf Restreaming-Server
  • Orchestrator: Ăśberwacht den Bedarf und skaliert den Restreaming-Cluster nach oben oder unten
  • Storage: Objektspeicher fĂĽr aufgezeichnete Segmente mit Lifecycle Management

VPN-Tunnel-Architektur

Sichere Kamera-Konnektivität

  • Im Cloud bereitgestellter VPN-Hub baut verschlĂĽsselte Tunnel zu jedem entfernten Standort auf
  • Kameras an entfernten Standorten streamen RTSP innerhalb des VPN-Tunnels — keine Exposition gegenĂĽber dem öffentlichen Internet
  • Jeder Standort erhält einen VPN-Client, der sich mit dem Hub verbindet und ein privates Netzwerk-Overlay erstellt
  • Kamera-RTSP-Streams sind fĂĽr die Cloud-Infrastruktur ĂĽber private VPN-IP-Adressen zugänglich
  • Mehrere Kameras pro Standort teilen sich einen einzigen VPN-Tunnel

NAT/Firewall-Traversal

  • VPN-Clients initiieren ausgehende Verbindungen vom Kamerastandort (keine eingehenden Firewall-Regeln erforderlich)
  • Hub akzeptiert eingehende Verbindungen und erstellt bidirektionale Tunnel
  • Cloud-Dienste greifen ĂĽber das VPN-Netzwerk auf Kamera-RTSP-Feeds zu, als wären sie lokal

Zuverlässigkeit

  • Automatische Tunnel-Wiederverbindung bei Netzwerkunterbrechungen
  • Keepalive-Probes erkennen und beheben stille Fehler
  • Mehrere Tunnelprotokolle werden fĂĽr die Kompatibilität mit restriktiven Netzwerken unterstĂĽtzt
  • ZustandsĂĽberwachung pro Tunnel mit Alarmierung bei längeren Trennungen

Auto-Scaling Restreaming

RTSP Relay

Restreaming-Server rufen Kamera-RTSP-Feeds aus dem VPN-Netzwerk ab und stellen sie nachgelagerten Konsumenten zur VerfĂĽgung:

  • AI-Worker verbinden sich ĂĽber RTSP fĂĽr latenzarme, bildgenaue Verarbeitung
  • Mehrere Konsumenten können auf denselben Kamerastream zugreifen, ohne die Kamera zusätzlich zu belasten
  • Stream-Multiplexing reduziert die Bandbreite vom Kamerastandort (ein Abruf, viele Konsumenten)

HLS-Konvertierung

FĂĽr die webbasierte Anzeige konvertieren Restreaming-Server RTSP in Echtzeit in HLS:

  • Segmentbasierte Verpackung fĂĽr HTTP-Bereitstellung ĂĽber Standard-Web-Infrastruktur
  • UnterstĂĽtzung adaptiver Bitraten fĂĽr unterschiedliche Netzwerkbedingungen der Zuschauer
  • CDN-kompatible Ausgabe fĂĽr Edge-Cache-basierte Bereitstellung
  • Low-Latency HLS-Konfiguration fĂĽr nahezu Echtzeit-Anzeige

Auto-Scaling

Der Restreaming-Cluster skaliert basierend auf dem Bedarf:

  • Scale Up — Wenn Viewer-/AI-Verbindungen pro Server einen Schwellenwert ĂĽberschreiten oder die CPU-Auslastung hoch ist
  • Scale Down — Wenn die Auslastung ĂĽber einen längeren Zeitraum unter einen Schwellenwert fällt
  • Neue Server ziehen Kamera-Feeds aus dem VPN-Netzwerk und registrieren sich beim Load Balancer
  • Graceful Shutdown beendet Verbindungen, bevor Server entfernt werden (Zuschauer verbinden sich automatisch ĂĽber stabile URLs wieder)

Aufzeichnungspipeline

Kontinuierliche Aufzeichnung

  • Restreaming-Server oder dedizierte Recording-Worker erfassen RTSP-Streams als segmentierte Dateien
  • Segmente werden in konfigurierbaren Intervallen fĂĽr ĂĽberschaubare Dateigrößen geschrieben
  • Jedes Segment ist mit Kamera-ID, Zeitstempel und Dauer-Metadaten versehen

Speichermanagement

  • Segmente werden fĂĽr die dauerhafte Archivierung in den Object Storage hochgeladen
  • Aufbewahrungsrichtlinien löschen Segmente, die älter als der konfigurierte Aufbewahrungszeitraum sind, automatisch
  • Storage Lifecycle Rules verschieben ältere Segmente vor der Löschung in gĂĽnstigere Speicher-Tiers
  • Speicherquoten pro Kamera und pro Standort verhindern ausufernde Kosten

Wiedergabe

  • Aufgezeichnete Segmente sind ĂĽber zeitbasierte Abfragen zugänglich (Kamera + Zeitbereich)
  • HLS-Manifest wird on-the-fly fĂĽr die browserbasierte Wiedergabe von aufgezeichnetem Material generiert
  • Suchen und Scrubben durch die aufgezeichnete Timeline mit Segment-Level-Granularität

Multi-Protokoll-Bereitstellung

| Konsument | Protokoll | Latenz | Anwendungsfall |

|----------|----------|---------|---------------|

| AI Workers | RTSP | Gering (~500ms) | Echtzeit-Objekterkennung, Analysen |

| Web Viewers | HLS | Mittel (2-6s) | Browserbasiertes Live-Monitoring |

| Mobile Apps | HLS | Mittel (2-6s) | Fernüberwachung auf Mobilgeräten |

| Archivierung | Aufgezeichnete Segmente | N/A | VorfallsprĂĽfung, Compliance, Forensik |

Monitoring & Zuverlässigkeit

Stream-Zustand

  • Kamerabasierte Stream-StatusĂĽberwachung (verbunden, puffert, getrennt)
  • VPN-Tunnel-Zustand pro Standort (Latenz, Paketverlust, Betriebszeit)
  • Restreaming-Server-Metriken (CPU, Bandbreite, Verbindungsanzahl)
  • Zustand der Aufzeichnungspipeline (Segment-Schreibrate, Speichernutzung, Upload-Status)

Alarmierung

  • Kamera-Trennungsalarme mit Standortidentifikation
  • VPN-Tunnel-Fehlermeldungen
  • Kapazitätswarnungen des Restreaming-Clusters
  • Speicherquoten- und Aufbewahrungsalarme
  • AufzeichnungslĂĽcken, erkannt durch Segment-KontinuitätsprĂĽfungen

Hauptmerkmale

  1. VPN-gesicherter Ingest — Verschlüsselte Tunnel schützen RTSP-Streams von entfernten Kameras
  2. NAT/Firewall-Traversal — Ausgehende VPN-Verbindungen umgehen restriktive Netzwerkkonfigurationen
  3. Auto-Scaling Restreaming — Cluster skaliert mit Viewer- und AI-Nachfrage
  4. HLS-Konvertierung — Echtzeit-RTSP-zu-HLS für browserbasierte Anzeige
  5. RTSP Relay — Latenzarmer Stream-Zugriff für AI-Verarbeitungs-Worker
  6. Kontinuierliche Aufzeichnung — Segmentbasierte Aufzeichnung mit Aufbewahrungsmanagement
  7. Multi-Protokoll — RTSP, HLS und aufgezeichnete Segmente aus einem einzigen Ingest
  8. Automatische Wiederverbindung — VPN-Tunnel und Stream-Verbindungen erholen sich von Unterbrechungen
  9. Storage Lifecycle — Gestufter Speicher mit automatischer Durchsetzung der Aufbewahrung
  10. Stream-Multiplexing — Ein Kamera-Abruf bedient mehrere Konsumenten ohne zusätzliche Kamerabelastung

Ergebnisse

Sicherheit: Alle Kamera-Feeds Ende-zu-Ende ĂĽber VPN-Tunnel verschlĂĽsselt
Skalierbarkeit: Restreaming-Cluster skaliert je nach Bedarf von 2 auf ĂĽber 20 Server
HLS-Latenz: 2-6 Sekunden fĂĽr nahezu Echtzeit-browserbasierte Anzeige

Technologie-Stack

VPN (WireGuard/OpenVPN)MediaMTXRTSPHLSFFmpegDockerCloud VMsObject StorageLoad BalancerPythonRedisPrometheusGrafana

caseStudyDetail.more Fallstudien

Entdecken Sie mehr unserer technischen Implementierungen

Kickly: KI-gestĂĽtzte Projektplattform fĂĽr Startups

Kickly ist eine KI-gestützte Projektmanagementplattform, die für Startups entwickelt wurde – und intelligente Aufgabenautomatisierung, Teamkollaboration und Echtzeit-Fortschrittsverfolgung in einem Produkt vereint.

Fallstudie lesen
AI Accounting

KI-gestĂĽtzte Rechnungsverarbeitung mit OCR und QuickBooks-Integration

Ein mittelständisches Unternehmen, das monatlich Hunderte von Lieferantenrechnungen verarbeitete, musste die manuelle Dateneingabe eliminieren, indem es Rechnungsdaten automatisch mithilfe von AI/OCR extrahierte und diese direkt mit QuickBooks für die Buchhaltung und Zahlungsverfolgung synchronisierte.

Fallstudie lesen

Bereit, Ihr Unternehmen zu transformieren?

Lassen Sie uns besprechen, wie wir ähnliche Lösungen für Ihre Herausforderungen anwenden können.

Kontakt aufnehmencaseStudyDetail.viewAllCaseStudies
RTSP-Latenz: Sub-Sekunden-Relay fĂĽr AI-Verarbeitungs-Worker
Aufzeichnung: Kontinuierliche Aufzeichnung mit konfigurierbarer Aufbewahrung und Lifecycle Management
Wiederverbindung: VPN-Tunnel und Streams erholen sich innerhalb von Sekunden nach Unterbrechung automatisch
Kosten: Auto-Scaling reduziert die Infrastrukturkosten um 50-70 % gegenĂĽber fester Bereitstellung fĂĽr Spitzenlasten
Video Encoding

Clientseitige Anzeigeninsertion (CSAI) mit SCTE-35 Marker-Parsing & Multi-Plattform-Player-Integration

Eine Video-Streaming-Plattform musste die Clientseitige Anzeigeninsertion (CSAI) über Web-, Mobil- und Connected TV-Apps hinweg implementieren – was personalisierte, gerätespezifische Anzeigenerlebnisse mit vollständiger Unterstützung der Anzeigeninteraktion (anklickbare Overlays, Companion-Banner, Skip-Buttons) ermöglicht, die serverseitige Insertion nicht bieten kann.

Fallstudie lesen

Häufig gestellte Fragen

MicrocosmWorks hat die VPN-Schicht hinzugefügt, weil RTSP-Kameras hinter Unternehmensfirewalls oder NAT nicht direkt von der Cloud-Infrastruktur aus zugänglich sind und das Verfügbarmachen von RTSP-Ports von Kameras im öffentlichen Internet schwerwiegende Sicherheitslücken schafft. Der VPN-Tunnel fügt je nach geografischer Entfernung etwa 5-15 ms Latenz hinzu, was für Überwachungsanwendungsfälle vernachlässigbar ist, und der verschlüsselte Tunnel stellt sicher, dass Videodaten während der Übertragung den Sicherheits- und Compliance-Anforderungen von Unternehmen entsprechen.

MicrocosmWorks implementierte adaptives Bitraten-HLS-Transcoding, das mehrere Qualitätsstufen aus jedem RTSP-Quellstream generiert und es dem HLS-Player ermöglicht, automatisch zwischen den Qualitätsstufen zu wechseln, basierend auf der verfügbaren Bandbreite des Zuschauers. Das System verwendet hardwarebeschleunigtes Transcoding, um die Latenz zwischen dem Live-RTSP-Feed und der HLS-Ausgabe zu minimieren, wodurch typische Glass-to-Glass-Verzögerungen von 4-8 Sekunden erreicht werden, abhängig von der Konfiguration der Segmentdauer.

MicrocosmWorks hat Edge-seitiges Buffering in das VPN-Gateway integriert, das Stream-Segmente während Netzwerkunterbrechungen lokal zwischenspeichert und diese in chronologischer Reihenfolge hochlädt, sobald die Verbindung wiederhergestellt ist. Dies gewährleistet keine Aufzeichnungslücken, selbst bei längeren Trennungen. Der Cloud-seitige Aufzeichnungsdienst erkennt Zeitachsenlücken und markiert diese in der Wiedergabeschnittstelle, was den Bedienern eine klare Übersicht über Zeiträume verschafft, in denen Live-Aufnahmen verzögert wurden.

MicrocosmWorks hat die Architektur getestet, um 50-100 gleichzeitige 1080p RTSP-Streams pro VPN-Tunnel zu unterstützen, abhängig von der verfügbaren Upstream-Bandbreite am Kamerastandort und den Hardware-Spezifikationen des VPN-Gateways. Für Standorte mit mehr Kameras unterstützt das System mehrere parallele VPN-Tunnel mit automatischer Stream-Verteilung, und der Cloud-seitige Auto-Scaler stellt zusätzliche Restreaming-Worker bereit, wenn die aggregierte Stream-Anzahl steigt.

MicrocosmWorks erstellt VPN-basierte Streaming-Plattformen zu Entwicklungsraten von 25-45 $/Std., wobei typische Implementierungen 2-4 Monate für eine produktionsreife Bereitstellung benötigen, einschließlich VPN-Infrastruktur, Auto-Scaling Restreaming, HLS-Transcoding und Aufzeichnung. Laufende Cloud-Kosten werden durch das Auto-Scaling-Muster optimiert und sind typischerweise 40-60 % niedriger als bei Bereitstellungen mit fester Kapazität, indem Restreaming-Worker während der Nebenzeiten heruntergefahren werden.