Oft stellt sich die Frage: Wie verbindet man eine IP-Kamera mit dem NVR, wenn sie nicht in der Kompatibilitätsliste steht?
Es gibt zwei Möglichkeiten ONVIF und RTSP
Beginnen wir mit dem ONVIF-Protokoll (Open Network Video Interface Forum).
ONVIF ist ein allgemein akzeptiertes Protokoll für die Zusammenarbeit von IP-Kameras, NVRs, Software, falls alle Geräte von verschiedenen Herstellern stammen. ONVIF kann mit Englisch für die internationale Kommunikation zwischen Menschen verglichen werden.
Stellen Sie sicher, dass die angeschlossenen Geräte ONVIF unterstützen, auf einigen Geräten ist ONVIF möglicherweise standardmäßig deaktiviert.
Oder die ONVIF-Autorisierung kann deaktiviert werden, was bedeutet, dass der Benutzername / das Passwort immer der Standardwert ist
unabhängig von Login/Passwort für WEB 
Es ist auch erwähnenswert, dass einige Geräte verwendenseparater Port für die Arbeit unter dem ONVIF-Protokoll
In einigen Fällen kann sich das ONVIF-Passwort vom Passwort für den WEB-Zugriff unterscheiden.
Was ist bei einer Verbindung über ONVIF verfügbar?
Geräteerkennung
Übertragung von Videodaten
Empfangen und Senden von Audiodaten
PTZ-Steuerung (PTZ)
Videoanalyse (z. B. Bewegungserkennung)
Diese Optionen hängen von der Kompatibilität der ONVIF-Protokollversionen ab. In einigen Fällen sind einige Parameter nicht verfügbar oder funktionieren nicht richtig.
K und mit ONVIF
Bei SNR- und Dahua-Rekordern befindet sich das ONVIF-Protokoll auf der Registerkarte Remote Device in der Zeile Manufacturer
Wählen Sie den Kanal aus, mit dem das Gerät verbunden wird
Wählen Sie auf der Registerkarte Hersteller aus ONVIF
Angeben IP Adresse Geräte
RTSP Port bleibt Standard
Kameras verwenden ONVIF Port 8080
(seit 2017 wurde bei neuen ONVIF-Modellen der Port auf 80 für die Alpha-, Mira-Serie geändert)
OMNY-Kameras Base verwenden ONVIF Port 80, im Registrar wird er als HTTP-Port angegeben
Name
Passwort nach Geräteparametern
entfernter Kanal der Standardwert ist 1. Wenn es sich um ein Mehrkanalgerät handelt, wird die Kanalnummer angezeigt.
Decoder-Puffer— Pufferung des Videostreams mit Zeitwert
Server TypEs gibt eine Auswahl von TCP, UDP-Schedule
TCP- stellt eine Verbindung zwischen Sender und Empfänger her, sorgt dafür, dass alle Daten unverändert und in der gewünschten Reihenfolge beim Empfänger ankommen, regelt auch die Übertragungsgeschwindigkeit.
Im Gegensatz zu TCP, UDP stellt keine vorläufige Verbindung her, sondern beginnt einfach mit der Datenübertragung. UDP verfolgt die empfangenen Daten nicht und dupliziert sie nicht im Falle eines Verlustes oder Fehlers.
UDP ist weniger zuverlässig als TCP. Andererseits bietet es ein schnelleres Streaming, da verlorene Pakete nicht erneut übertragen werden.
Zeitlicher Ablauf— automatische Typerkennung.
So sehen verbundene Geräte in Dahua aus
Grüner Status bedeutet, dass der DVR und die Kamera erfolgreich verbunden sind
Roter Status bedeutet, dass es Verbindungsprobleme gibt. Beispielsweise ist der Verbindungsport falsch.
Die zweite Art der Verbindung ist RTSP(Echtzeit-Streaming-Protokoll) 
RTSPein Echtzeit-Streaming-Protokoll, das Befehle zum Steuern eines Videostreams beschreibt.
Mit Hilfe dieser Befehle wird der Videostream von der Quelle zum Empfänger übertragen.
zum Beispiel von einer IP-Kamera zu einem DVR oder einem Server.
Was ist bei einer Verbindung über RTSP verfügbar?
Übertragung von Videodaten
Empfangen und Senden von Audiodaten
Vorteildieses Übertragungsprotokolls dadurch, dass es keine Versionskompatibilität erfordert.
Heute wird RTSP von fast allen IP-Kameras und NVRs unterstützt.
Mängel Protokoll ist, dass außer der Übertragung von Video- und Audiodaten nichts weiter zur Verfügung steht.
Sehen wir uns ein Beispiel für den Anschluss einer Kamera an zu und mit RTSP
.jpg)
RTSP befindet sich auf der Registerkarte „Remote Device“ in der Zeile „Manufacturer“ und wird im SNR- und Dahua-Registrar als angezeigtAllgemein
Wählen Sie den Kanal aus, mit dem das Gerät verbunden wird
URL-Adr- Hier geben wir die Abfragezeichenfolge ein, mit der die Kamera zurückkehrt Basic RTSP-Stream von hoch Auflösung.
Zusätzliche URL - hier Geben Sie die Abfragezeichenfolge ein, mit der die Kamera zurückkehrt zusätzlich RTSP-Stream von niedrige Auflösung.
Anfragebeispiel:
rtsp://172.16.31.61/1 Hauptstrom
rtsp://172.16.31.61/2 zusätzlicher Stream
Warum brauchen Sie einen zusätzlichen Stream?
Auf einem lokalen Monitor, der mit einem Multibildrekorder verbunden ist, verwendet der Rekorder einen zusätzlichen Thread, um Ressourcen zu sparen. Bei kleinen Bildern mit 16 Fenstern ist es beispielsweise überhaupt nicht erforderlich, die Full-HD-Auflösung zu decodieren, D1 reicht aus. Nun, wenn Sie in diesem Fall 1/4/8 Fenster geöffnet haben, wird der Hauptstrom mit hoher Auflösung decodiert.
Namenach Geräteparametern
Passwort nach Geräteparametern
Decoder-PufferPufferung des Videostreams mit Zeitwert
Server Typ- TCP, UDP, Zeitplan (ähnlich dem ONVIF-Protokoll)
Dieser Artikel beantwortet die häufigsten Fragen wie:
Ist die IP-Kamera mit dem NVR kompatibel?
Und wenn es kompatibel ist, wie verbindet man sich !?
RTSP-Protokoll
RTSP (Real Time Streaming Protocol, oder auf Russisch Echtzeit-Streaming-Protokoll) ist ein Anwendungsprotokoll, das Befehle zur Steuerung eines Videostreams beschreibt. Mit diesen Befehlen können wir beispielsweise der Kamera oder dem Server „befehlen“, mit der Übertragung eines Videostreams zu beginnen. Ein Beispiel für eine Anfrage zum Starten der Wiedergabe sieht folgendermaßen aus: PLAY rtsp://192.168.0.200/h264 RTSP/1.0
Das heißt, RTSP ist nur eine Reihe von Befehlen zur Steuerung des Videostreams. Machen wir ein Experiment. Dazu benötigen wir eine IP-Kamera, die das RTSP-Protokoll und ihre RTSP-Adresse unterstützt. Diese Adresse sieht etwa so aus: rtsp://
TCP-Protokoll
Angenommen, wir haben die RSTP-über-TCP-Methode gewählt und möchten mit der Übertragung eines Videostreams beginnen. Was wird auf der Ebene der Transportmechanismen passieren? Zuvor wird mit Hilfe mehrerer Befehle eine Verbindung zwischen Sender und Empfänger hergestellt. Danach beginnt die Videodatenübertragung. Gleichzeitig TCP-Mechanismen
sorgt dafür, dass alle Daten unverändert und in der richtigen Reihenfolge beim Empfänger ankommen. Außerdem wird TCP die Übertragungsrate so regeln, dass der Sender nicht intensiver Daten sendet, als der Empfänger sie verarbeiten kann, z.
UDP ist eine Alternative zum TCP-Transportprotokoll. Im Gegensatz zu TCP baut UDP keine Vorverbindung auf, sondern beginnt einfach mit der Datenübertragung. UDP stellt nicht sicher, dass die Daten empfangen werden, und dupliziert sie nicht, wenn Teile fehlen oder fehlerhaft empfangen werden. UDP weniger
zuverlässiger als TCP. Andererseits bietet es ein schnelleres Streaming, da kein Mechanismus zur erneuten Übertragung verlorener Pakete vorhanden ist. Der Unterschied zwischen TCP- und UTP-Protokollen kann durch das folgende Beispiel veranschaulicht werden. Zwei Freunde treffen sich. TCP-Option:
Ivan: Hallo! Sollen wir uns unterhalten?" (Verbindung wird aufgebaut)
Simon: „Hallo! Lasst uns!" (Verbindung wird aufgebaut)
Ivan: „Gestern war ich im Laden. Hast du verstanden?" (Datentransfer)
Simon: "Ja!" (die Bestätigung)
Ivan: „Sie haben neue Ausrüstung abgeladen. Hast du verstanden?" (Datentransfer)
Semjon: „Nein“ (Bestätigung)
Ivan: „Sie haben neue Ausrüstung abgeladen. Hast du verstanden?" (Weitersendung)
Simon: "Ja!" (die Bestätigung)
Ivan: „Morgen bin ich wieder da. Hast du verstanden?" (Datentransfer)
Simon: "Ja!" (die Bestätigung)
UDP-Variante
Ivan: Hallo! Ich war gestern im Laden“ (Datenübertragung)
Ivan: „Sie haben neue Ausrüstung abgeladen“ (Datenübertragung)
Ivan: „Morgen bin ich wieder da“ (Datenübertragung)
Ivan: "Ich kann Ihnen Preise besorgen" (Datenübertragung)
Ivan: "Sie haben Rabatte für gute Mengen versprochen" (Datenübertragung)
Ivan: "Wenn du willst, ruf an - wir gehen zusammen" (Datenübertragung)
Semjon: "Ja, ich rufe an" (Datenübertragung)
Sie können den Unterschied in den Protokollen auch sehen, indem Sie das folgende Experiment durchführen: Versuchen Sie, die Kamera auf den RTSP-über-TCP-Modus einzustellen, und bewegen Sie Ihre Hand vor dem Objektiv - Sie sehen eine Verzögerung auf dem Monitorbildschirm. Führen Sie nun den gleichen Test im RTSP-über-UDP-Modus durch. Die Verzögerung wird geringer sein. Mehrere Faktoren beeinflussen die Verzögerungszeit: das Komprimierungsformat, die Leistung des Computers, das Übertragungsprotokoll und die Funktionen der an der Videodecodierung beteiligten Software.
RTP (Real-time Transport Protocol) oder Echtzeit-Transportprotokoll auf Russisch. Dieses Protokoll wurde speziell für die Übertragung von Echtzeitverkehr entwickelt. Es ermöglicht Ihnen, die Synchronisation der übertragenen Daten zu überwachen, die Reihenfolge der Paketzustellung anzupassen und eignet sich daher besser als andere für die Übertragung von Video- und Audiodaten. Im Allgemeinen ist es vorzuziehen, entweder RTP oder UDP zu verwenden, um einen Videostream zu übertragen. Das Arbeiten über TCP ist nur dann gerechtfertigt, wenn wir mit problematischen Netzwerken arbeiten müssen, da das TCP-Protokoll Fehler und Ausfälle korrigieren kann, die während der Datenübertragung auftreten.
RTSP (Echtzeit-Streaming-Protokoll) ist ein Echtzeit-Streaming-Protokoll, das einen einfachen Satz grundlegender Befehle zur Steuerung eines Videostreams enthält.
Verbinden von RTSP-Quellen und IP-Kameras in einer Videokonferenz
Das RTSP-Protokoll ermöglicht es jedem TrueConf-Benutzer, sich mit IP-Kameras und anderen Medieninhaltsquellen zu verbinden, die dieses Protokoll verwenden, um entfernte Objekte zu überwachen. Außerdem kann sich der Benutzer mit solchen Kameras verbinden, um während einer Videokonferenz Bilder zu übertragen.
Dank der Unterstützung des RTSP-Protokolls können Benutzer von TrueConf Server nicht nur eine Verbindung zu IP-Kameras herstellen, sondern auch Videokonferenzen an RTSP-Player und Medienserver übertragen. Lesen Sie mehr über RTSP-Broadcasts.
Vorteile der Verwendung von IP-Kameras mit TrueConf-Softwarelösungen
- Indem Sie eine IP-Kamera in einem Büro oder einer Industriewerkstatt installieren und jederzeit daran anschließen, können Sie den Produktionsprozess Ihres Unternehmens überwachen.
- Sie können rund um die Uhr entfernte Objekte überwachen. Wenn Sie beispielsweise in den Urlaub fahren und Ihre Wohnung nicht unbeaufsichtigt lassen möchten, installieren Sie dort einfach eine oder mehrere IP-Kameras. Indem Sie eine dieser Kameras von Ihrem PC mit installierter TrueConf-Clientanwendung anrufen, können Sie sich jederzeit mit Ihrer Wohnung verbinden und in Echtzeit sehen, was dort passiert.
- TrueConf-Client-Anwendungen für Windows, Linux und macOS bieten allen Benutzern die Möglichkeit, Videokonferenzen aufzuzeichnen, wodurch Sie alle Ereignisse während der Videoüberwachung aufzeichnen und dokumentarische Beweise dafür erhalten können.
Nach einigen Daten hat die Welt bis heute installiert hunderte Millionen IP-Kameras für die Videoüberwachung. Bei weitem nicht allen ist jedoch die Verzögerung bei der Videowiedergabe kritisch. Die Videoüberwachung erfolgt in der Regel "statisch" - der Stream wird im Speicher aufgezeichnet und kann auf Bewegung analysiert werden. Für die Videoüberwachung wurden viele Software- und Hardwarelösungen entwickelt, die ihren Job gut machen.
In diesem Artikel werden wir uns eine etwas andere Anwendung ansehen. IP-Kameras, nämlich die Verwendung in Online-Sendungen, sofern erforderlich geringe Kommunikationsverzögerung.
Klären wir zunächst ein mögliches Missverständnis in der Terminologie rund um Webcams und IP-Kameras auf.
Webcam ist ein Videoaufnahmegerät, das über keinen eigenen Prozessor und keine eigene Netzwerkschnittstelle verfügt. Die Webcam erfordert eine Verbindung zu einem Computer, Smartphone oder einem anderen Gerät, das über eine Netzwerkkarte und einen Prozessor verfügt.
IP Kamera ist ein eigenständiges Gerät, das über eine eigene Netzwerkkarte und einen eigenen Prozessor verfügt, um das aufgenommene Video zu komprimieren und an das Netzwerk zu senden. Somit ist die IP-Kamera ein eigenständiger Mini-Computer, der vollständig mit dem Netzwerk verbunden ist und nicht mit einem anderen Gerät verbunden werden muss und direkt an das Netzwerk senden kann.
Geringe Wartezeit(niedrige Latenz) ist eine ziemlich seltene Anforderung für IP-Kameras und Online-Übertragungen. Die Notwendigkeit, mit geringer Latenz zu arbeiten, ergibt sich beispielsweise, wenn die Quelle des Videostreams aktiv mit den Zuschauern dieses Streams interagiert.
Meistens wird in Gaming-Anwendungsfällen eine niedrige Latenz benötigt. Beispiele sind: Echtzeit-Videoauktion, Live-Dealer-Videocasino, interaktive Online-TV-Show mit einem Moderator, Fernsteuerung eines Quadrocopters usw.
Ein Live-Online-Casino-Händler bei der Arbeit.
Eine gewöhnliche RTSP-IP-Kamera drückt in der Regel Video hinein H.264 Codec und kann in zwei Arten des Datentransports arbeiten: verschachtelt und nicht verschachtelt.
Modus verschachtelt die beliebtesten und bequemsten, weil In diesem Modus werden die Videodaten per TCP-Protokoll innerhalb der Netzwerkverbindung zur Kamera übertragen. Um von einer IP-Kamera auf Interleaved zu verteilen, müssen Sie nur einen RTSP-Port der Kamera (z. B. 554) nach außen öffnen / weiterleiten. Der Player muss sich nur über TCP mit der Kamera verbinden und den Stream bereits innerhalb dieser Verbindung aufnehmen.
Die zweite Betriebsart der Kamera ist nicht verschachtelt. In diesem Fall wird die Verbindung über das Protokoll aufgebaut RTSP/TCP, und der Verkehr geht schon separat, laut Protokoll RTP/UDP außerhalb des erstellten TCP-Kanals.
Modus nicht verschachtelt günstiger für die Übertragung von Videos mit minimaler Verzögerung, da es das Protokoll verwendet RTP/UDP, ist aber gleichzeitig problematischer, wenn sich der Spieler dahinter befindet NAT.
Beim Verbinden mit der IP-Kamera eines Players hinter NAT muss der Player wissen, welche externen IP-Adressen und Ports er zum Empfangen von Audio- und Videoverkehr verwenden kann. Diese Ports werden im Text SDP config angegeben, der beim Aufbau einer RTSP-Verbindung an die Kamera gesendet wird. Wenn das NAT korrekt geöffnet wurde und die richtigen IP-Adressen und Ports definiert sind, dann funktioniert alles.
Um also mit minimaler Verzögerung Videos von der Kamera aufzunehmen, müssen Sie verwenden nicht verschachtelt Modus und empfangen Videoverkehr über UDP.
Browser unterstützen den RTSP/UDP-Protokollstapel nicht direkt, unterstützen jedoch den eingebetteten Technologieprotokollstapel WebRTC.
Insbesondere Browser- und Kameratechnologien sind sich sehr ähnlich SRTP es ist verschlüsselt RTP. Aber für eine korrekte Verteilung an Browser müsste eine IP-Kamera den WebRTC-Stack teilweise unterstützen.
Um diese Inkompatibilität zu beseitigen, ist ein zwischengeschalteter Relay-Server erforderlich, der eine Brücke zwischen den Protokollen der IP-Kamera und den Protokollen des Browsers bildet.
Der Server übernimmt den Stream von der IP-Kamera zu sich selbst RTP/UDP und gibt es über WebRTC an verbundene Browser weiter.
Die WebRTC-Technologie arbeitet gemäß dem Protokoll UDP und sorgt so für geringe Latenz in der Richtung Server > Browser. Die IP-Kamera arbeitet ebenfalls mit dem Protokoll RTP/UDP und bietet eine geringe Latenz in Richtung Kamera > Server.
Die Kamera kann aufgrund begrenzter Ressourcen und Bandbreite eine begrenzte Anzahl von Streams liefern. Durch die Verwendung eines Zwischenservers können Sie die Übertragung von einer IP-Kamera auf eine große Anzahl von Zuschauern skalieren.
Andererseits werden bei Verwendung des Servers zwei Kommunikationszweige aktiviert:
1) Zwischen Zuschauern und Server
2) Zwischen Server und Kamera
Eine solche Topologie hat eine Reihe von "Merkmale" oder "Fallstricke". Wir listen sie unten auf.
Fallstrick Nr. 1 – Codecs
Die verwendeten Codecs können ein Hindernis für niedrige Latenzzeiten sein und eine Verschlechterung der Gesamtsystemleistung verursachen.Zum Beispiel, wenn die Kamera einen 720p-Videostream in H.264 liefert und ein Chrome-Browser auf einem Android-Smartphone verbunden ist, das nur VP8 unterstützt.
Wenn die Transkodierung aktiviert ist, muss für jede der angeschlossenen IP-Kameras eine Transkodierungssitzung erstellt werden, die dekodiert H.264 und kodiert ein VP8. In diesem Fall kann ein Dual-Prozessor-Server mit 16 Kernen nur 10–15 IP-Kameras bedienen, mit einer ungefähren Berechnung von 1 Kamera pro physischem Kern.
Wenn die Serverkapazitäten die Transcodierung der geplanten Anzahl von Kameras nicht zulassen, sollte daher auf eine Transcodierung verzichtet werden. Bedienen Sie beispielsweise nur Browser mit H.264-Unterstützung und bieten Sie den Rest an, eine native mobile Anwendung für iOS oder Android zu verwenden, bei der der H.264-Codec unterstützt wird.
Als Option zum Umgehen der Transcodierung in einem mobilen Browser können Sie verwenden HLS. HTTP-Streaming ist jedoch keineswegs latenzarm und kann derzeit nicht für interaktives Streaming verwendet werden.
Fallstrick Nr. 2 – Kamerabitrate und -verlust
Das UDP-Protokoll hilft bei der Bewältigung der Verzögerung, lässt jedoch den Verlust von Videopaketen zu. Daher kann das Bild trotz der geringen Latenz bei großen Netzwerkverlusten zwischen Kamera und Server beschädigt werden.
Um Verluste zu vermeiden, müssen Sie sicherstellen, dass der von der Kamera erzeugte Videostream eine Bitrate hat, die in die zugewiesene Bandbreite zwischen Kamera und Server passt.
Fallstrick Nr. 3 – Bitrate und Verlust des Zuschauers
Jeder Broadcast-Zuschauer, der sich mit dem Server verbindet, hat auch eine bestimmte Download-Bandbreite.Wenn die IP-Kamera einen Stream sendet, der die Möglichkeiten des Viewer-Kanals übersteigt (z. B. sendet die Kamera 1 Mbit/s, und der Betrachter kann nur akzeptieren 500 kbit/s), dann kommt es auf diesem Kanal zu großen Verlusten und dadurch zu Videofriesen oder starken Artefakten.
In diesem Fall gibt es drei Möglichkeiten:
- Transcodieren Sie den Videostream individuell für jeden Betrachter mit der erforderlichen Bitrate.
- Transcodieren Sie Streams nicht für jeden verbundenen, sondern für eine Gruppe von Zuschauern.
- Bereiten Sie Streams von der Kamera im Voraus in mehreren Auflösungen und Bitraten vor.
Zweite Option besteht darin, die Belastung der Server-CPU mithilfe von Transcoding-Gruppen zu reduzieren. Der Server erstellt mehrere Gruppen nach Bitrate, zum Beispiel zwei:
- 200 kbit/s
- 1 Mbit/s
Dritte Möglichkeit beinhaltet einen kompletten Verzicht auf serverseitiges Transcoding und die Verwendung bereits aufbereiteter Videostreams in unterschiedlichen Auflösungen und Bitraten. In diesem Fall ist die Kamera so konfiguriert, dass sie zwei oder drei Streams mit unterschiedlichen Auflösungen und Bitraten ausgibt, und die Zuschauer wechseln je nach Bandbreite zwischen diesen Streams.
In diesem Fall entfällt die Transcoding-Last auf dem Server und verlagert sich auf die Kamera selbst, weil Die Kamera muss jetzt zwei oder mehr Streams anstelle von einem codieren.
Als Ergebnis haben wir drei Optionen in Betracht gezogen, um uns an die Bandbreite der Zuschauer anzupassen. Wenn wir davon ausgehen, dass eine Transcodierungssitzung 1 Serverkern benötigt, erhalten wir die folgende Tabelle der CPU-Auslastung:
Die Tabelle zeigt, dass wir die Transcodierungslast auf die Kamera verlagern oder die Transcodierung auf den Server übertragen können. Die Optionen 2 und 3 scheinen die optimalsten zu sein.
Testen von RTSP als WebRTC
Es ist an der Zeit, einige Tests durchzuführen, um das wahre Bild dessen zu zeigen, was passiert. Nehmen wir eine echte IP-Kamera und testen Sie sie, um die Sendelatenz zu messen.Nehmen wir eine alte IP-Kamera zum Testen D-Link DCS-2103 mit der Unterstützung RTSP und Codecs H.264 und G.711.
Da die Kamera lange Zeit in einem Schrank mit anderen nützlichen Geräten und Kabeln lag, musste ich sie einschicken zurücksetzen indem Sie die Taste auf der Rückseite der Kamera 10 Sekunden lang gedrückt halten.
Nach dem Verbinden mit dem Netzwerk ging das grüne Licht an der Kamera an und der Router sah ein anderes Gerät im lokalen Netzwerk mit der IP-Adresse 192.168.1.37.
Wir gehen auf das Webinterface der Kamera und stellen die Codecs und die Auflösung zum Testen ein:
Gehen Sie als nächstes zu den Netzwerkeinstellungen und finden Sie die RTSP-Adresse der Kamera heraus. In diesem Fall die RTSP-Adresse live1.sdp, d.h. Die Kamera ist unter erhältlich rtsp://192.168.1.37/live1.sdp
Die Zugänglichkeit der Kamera kann einfach mit überprüft werden VLC-Player. Medien - Netzwerkstream öffnen.
Wir haben dafür gesorgt, dass die Kamera funktioniert und Video über RTSP liefert.
Wir werden Web Call Server 5 als Server zum Testen verwenden. Dies ist ein Streaming-Server mit Unterstützung RTSP und WebRTC Protokolle. Es wird eine Verbindung zur IP-Kamera hergestellt RTSP und nehmen Sie den Videostream. Weiter verteilen den Stream durch WebRTC.
Nach der Installation müssen Sie den Server in den RTSP-Modus schalten nicht verschachtelt die wir oben besprochen haben. Dies kann durch Hinzufügen der Einstellung erfolgen
rtsp_interleaved_mode=false
Diese Einstellung wird zur Konfiguration flashphoner.properties hinzugefügt und erfordert einen Neustart des Servers:
Dienst webcallserver Neustart
Wir haben also einen Server, der nach dem Non-Interleaved-Schema arbeitet, Pakete von der IP-Kamera per UDP empfängt und dann per WebRTC (UDP) verteilt.
Der Testserver steht auf einem VPS-Server im Frankfurter Rechenzentrum, hat 2 Kerne und 2 Gigabyte Arbeitsspeicher.
Die Kamera befindet sich im lokalen Netzwerk unter 192.168.1.37.
Daher müssen wir als erstes Port 554 für eingehende Nachrichten an 192.168.1.37 weiterleiten TCP/RTSP Verbindungen, damit der Server sich mit unserer IP-Kamera verbinden kann. Fügen Sie dazu nur eine Regel in den Router-Einstellungen hinzu:
Die Regel weist den Router an, den gesamten eingehenden Datenverkehr auf Port 554 an 37 umzuleiten – die IP-Adresse.
Wenn Sie ein freundliches NAT haben und die externe IP-Adresse kennen, können Sie mit dem Testen mit dem Server beginnen.
Der Standard-Demo-Player im Google Chrome-Browser sieht so aus:
Um mit der Wiedergabe eines RTSP-Streams zu beginnen, müssen Sie nur seine Adresse in das Feld eingeben Strom.
In diesem Fall die Stream-Adresse: rtsp://ip-cam/live1.sdp
Hier IP-Kamera dies ist die externe IP-Adresse Ihrer Kamera. Der Server versucht, eine Verbindung zu dieser Adresse aufzubauen.
VLC vs. WebRTC-Latenztests
Nachdem wir die IP-Kamera konfiguriert und getestet haben VLC, den Server eingerichtet und getestet RTSP fließen durch den Server mit Verteilung durch WebRTC, können wir endlich Verzögerungen vergleichen.Dazu verwenden wir einen Timer, der Sekundenbruchteile auf dem Monitorbildschirm anzeigt. Schalten Sie den Timer ein und spielen Sie gleichzeitig den Videostream ab VLC lokal und auf dem Firefox-Browser über einen Remote-Server.
Ping zum Server 100ms.
Pingen Sie lokal 1ms.
Der erste Timertest sieht so aus:
Auf einem schwarzen Hintergrund befindet sich der ursprüngliche Timer, der keine Verzögerung anzeigt. Links VLC, rechts Feuerfuchs Empfang WebRTC von einem entfernten Server streamen.
| Null | VLC | Firefox, WCS | |
| Zeit | 50.559 | 49.791 | 50.238 |
| Latenz ms | 0 | 768 | 321 |
Wir haben ein paar Aufnahmen gemacht, um die Verzögerungswerte festzuhalten.