RTSP ist ein einfaches Signalisierungsprotokoll, das sie schon seit vielen Jahren nicht mehr ersetzen können, und es muss zugegeben werden, dass sie sich nicht wirklich anstrengen.
Zum Beispiel haben wir eine IP-Kamera, die RTSP unterstützt. Jeder, der jemals den Datenverkehr mit einem Sharkwire-Kabel getestet hat, wird Ihnen mitteilen, dass zuerst DESCRIBE, dann PLAY und dann der Datenverkehr direkt über RTP oder beispielsweise über den TCP-Kanal übertragen wird.
Ein typisches Schema zum Herstellen einer RTSP-Verbindung sieht folgendermaßen aus:
Es ist denkbar, dass die Unterstützung des RTSP-Protokolls für Browser nicht erforderlich ist und ungefähr so häufig genutzt wird wie das fünfte Rad. Daher haben Browser es nicht eilig, es in großem Umfang zu implementieren, und das wird so gut wie nie passieren. Auf der anderen Seite könnten Browser direkte TCP-Verbindungen herstellen, und das würde die Aufgabe lösen, aber jetzt stößt es auf Sicherheitsprobleme: Haben Sie jemals einen Browser gesehen, mit dem ein Skript Transportprotokolle direkt verwenden kann?
Die Leute fordern jedoch, dass Streams in „jedem Browser ohne Installation zusätzlicher Software“ verfügbar sind, und die Start-Supper schreiben auf ihren Websites: „Sie müssen nichts installieren, es funktioniert in allen Browsern sofort“ möchte einen Stream von einer IP-Kamera anzeigen.
In diesem Artikel werden wir untersuchen, wie dies erreicht werden kann. Und da das kommende Jahr eine runde Zahl enthält, wollen wir unseren Artikel etwas aktueller gestalten und ein Label mit 2020 darauf kleben, zumal es wirklich so ist.
Welche Video-Display-Technologien für eine Webseite müssen im Jahr 2020 also vergessen werden? Es ist Flash im Browser. Es ist tot Es existiert nicht mehr, streichen Sie es von der Liste.
Drei nützliche Methoden
Die Tools, mit denen Sie heute einen Videostream in Ihrem Browser ansehen können, sind:
- WebRTC
- Hls
- Websocket + MSE
Was ist los mit WebRTC
In zwei Worten: Es ist ressourcenintensiv und kompliziert.
Sie werden wegwinken: "Was meinen Sie mit ressourcenintensiv?". Da die CPUs heutzutage leistungsstark sind, ist der Speicher billig. Wo liegt also das Problem? Erstens ist die Verschlüsselung des gesamten Datenverkehrs obligatorisch, auch wenn Sie ihn nicht benötigen. Zweitens ist WebRTC eine komplizierte bidirektionale Verbindung und ein Peer-to-Peer-Feedback-Austausch über die Kanalqualität (in diesem Fall Peer-to-Server): Zu jedem Zeitpunkt wird die Bitrate berechnet, Paketverluste erkannt und Entscheidungen getroffen Die Umleitung und die Audio-Video-Synchronisation werden in Bezug auf all das berechnet, das sogenannte Lipsync, bei dem die Lippen des Sprechers mit den Worten übereinstimmen. All diese Berechnungen sowie der eingehende Datenverkehr auf dem Server weisen in Echtzeit Gigabyte RAM zu und geben sie frei, und wenn etwas schief geht, kann ein 256-Gigabyte-Server mit einer 48-Kern-CPU trotz allem schnell aus dem Ruder laufen alle Gigaherz, Nanometer und DDR 10 an Bord.
Es ist also eine Art Eichhörnchen mit einer Iskander-Rakete zu jagen. Alles, was wir brauchen, ist ein RTSP-Stream, der dann angezeigt wird. WebRTC sagt: "Ja, komm schon, aber du musst dafür bezahlen."
Warum WebRTC gut ist
Die Latenz. Es ist wirklich niedrig. Wenn Sie bereit sind, die Leistung und Komplexität für die geringe Latenz zu opfern, ist WebRTC die am besten geeignete Variante für Sie.
Warum HLS gut ist
Mit zwei Worten: Es kann überall funktionieren
HLS ist ein langsamer Offroader in der Welt der Anzeige von Live-Inhalten. Es kann aufgrund zweier Dinge überall funktionieren: des HTTP-Transports und der Schirmherrschaft von Apple. In der Tat ist das HTTP-Protokoll allgegenwärtig, ich kann es sogar spüren, wenn ich diese Zeilen schreibe. Ganz gleich, wo Sie sich gerade befinden und mit welchem alten Tablet Sie im Internet surfen, mit HLS (HTTP Live Streaming) können Sie das Video sicher auf Ihrem Bildschirm anzeigen.
Es ist alles gut genug, aber ...
Warum HLS schlecht ist
Die Latenz. Es gibt zum Beispiel Projekte zur Videoüberwachung von Baustellen. Eine Anlage ist seit Jahren im Bau, und während dieser ganzen Zeit zeichnet die schlechte Kamera Tag und Nacht rund um die Uhr Videos von der Baustelle auf. Dies ist ein Beispiel für eine Situation, in der die niedrige Latenz nicht benötigt wird.
Ein anderes Beispiel sind Eber. Echte Eber. Die Bauern in Ohio leiden unter einer Invasion von Wildschweinen, die sich von der Ernte ernähren und sie wie Heuschrecken niederstampfen, was das finanzielle Wohlergehen der Farmen gefährdet. Unternehmer haben ein Videoüberwachungssystem von RTSP-Kameras gestartet, das das Gelände in Echtzeit überwacht und eine Falle auslöst, wenn die Eindringlinge einmarschieren. In diesem Fall ist die niedrige Latenz von entscheidender Bedeutung. Wenn HLS (mit einer Latenz von 15 Sekunden) verwendet wird, laufen die Eber weg, bevor die Falle aktiviert wird.
Hier ist ein weiteres Beispiel: Videopräsentationen, in denen Ihnen jemand ein Produkt vorführt und eine schnelle Antwort erwartet. Im Falle einer hohen Latenz zeigen sie Ihnen das Produkt auf der Kamera und fragen dann: „Wie gefällt es Ihnen?“. Das wird Sie in nur 15 Sekunden erreichen. Innerhalb von 15 Sekunden kann das Signal 12 Mal zum Mond und zurück gesendet werden. Nein, wir wollen keine solche Latenz. Es sieht eher nach einem aufgezeichneten Video aus als nach Live. Voraufgezeichnetes Video, so wie HLS funktioniert: Es zeichnet Teile eines Videos auf einer Disc oder im Speicher des Servers auf und der Player lädt die aufgezeichneten Teile herunter. So funktioniert HTTP Live, das überhaupt nicht Live ist.
Warum passiert es? Die globale Präsenz des HTTP-Protokolls und seine Einfachheit führen zu seiner Trägheit, da HTTP ursprünglich nicht zum schnellen Herunterladen und Anzeigen von Tausenden großer Videofragmente (HLS-Segmente) gedacht war. Sie werden natürlich in hoher Qualität heruntergeladen und wiedergegeben, aber sehr langsam: Es dauert mindestens 15 Sekunden, bis sie heruntergeladen, gepuffert und dekodiert sind.
Hier muss angemerkt werden, dass Apple im Herbst 2019 seine HLS Low Latency angekündigt hat, aber das ist schon eine andere Geschichte. Schauen wir uns die Ergebnisse später genauer an. Und jetzt haben wir auch MSE auf Lager.
Warum MSE gut ist
Media Source Extension ist eine native Unterstützung für die Wiedergabe von Paketvideos im Browser. Es kann als systemeigener Player für H.264 und AAC bezeichnet werden, dem Sie Videosegmente zuführen können und der im Gegensatz zu HLS nicht an ein Transportprotokoll gebunden ist. Aus diesem Grund können Sie den Transport über das Websockets-Protokoll auswählen. Mit anderen Worten, die Segmente werden nicht mehr mithilfe der alten Request-Response-Technologie (HTTP) heruntergeladen, sondern können problemlos über die Websockets-Verbindung übertragen werden, die fast ein direkter TCP-Kanal ist. Dies ist eine große Hilfe im Hinblick auf die Verringerung der Verzögerungen, die bis zu 3-5 Sekunden betragen können. Eine solche Latenz ist nicht fantastisch, aber für die meisten Projekte geeignet, die keine harte Echtzeit erfordern. Die Komplexität und Ressourcenintensität ist ebenfalls relativ gering, da ein TCP-Kanal geöffnet ist und fast die gleichen HLS-Segmente durchlaufen, die vom Player gesammelt und zum Spielen gesendet werden.
Warum ist MSE schlecht
Es kann nicht überall funktionieren. Ähnlich wie bei WebRTC ist die Durchdringung der Browser geringer. iPhones (iOS) haben eine besonders bemerkenswerte Vergangenheit, in der MSE nicht gespielt wurde, weshalb MSE kaum als alleinige Lösung für ein Startup geeignet ist.
Es ist in den folgenden Browsern vollständig verfügbar: Edge, Firefox, Chrome, Safari, Android-Browser, Opera Mobile, Chrome für Android, Firefox für Android, UC-Browser für Android.
Die eingeschränkte Unterstützung von MSE wurde vor einiger Zeit in iOS Safari eingeführt, beginnend mit iOS 13.
RTSP-Bein
Wir haben die Lieferung in Richtung Videoserver> Browser besprochen. Außerdem benötigen Sie diese beiden Dinge:
1) So senden Sie Ihr Video von der IP-Kamera an den Server.
2) Das Video in eines der oben beschriebenen Formate / Protokolle konvertieren.
Hier kommt die Serverseite ins Spiel.
Ta-dah ... Lernen Sie Web Call Server 5 (oder einfach WCS für Freunde) kennen. Jemand muss den RTSP-Verkehr empfangen, das Video korrekt entpacken, in WebRTC, HLS oder MSE konvertieren, vorzugsweise ohne vom Transcoder überkomprimiert zu werden, und es in ansehnlicher Form, ohne durch Artefakte und Einfrierungen verfälscht, an den Browser senden.
Die Aufgabe ist auf den ersten Blick nicht kompliziert, aber es kann so viele versteckte Fallstricke, chinesische Kameras und Konvertierungsnuancen geben, dass es wirklich schrecklich ist. Ohne Hacks ist das eigentlich nicht möglich, aber es funktioniert und funktioniert gut. In der Produktion.
Das Lieferschema
Infolgedessen nimmt ein vollständiges Schema für die Bereitstellung von RTSP-Inhalten mit Konvertierung auf einem Zwischenserver Gestalt an.
Eine der am häufigsten gestellten Fragen unserer indischen Kollegen lautet: „Ist es möglich? Direkt ohne Server? ”. Nein, das ist es nicht. Sie benötigen die Serverseite, die die Arbeit erledigt. In der Cloud, auf Hardware, auf Corei7 in Ihrem Balkon, aber darauf können Sie nicht verzichten.
Kommen wir zurück zu unserem Jahr 2020
Also, hier ist das Rezept zum Kochen eines RTSP in Ihrem Browser:
- Nimm ein frisches WCS (Web Call Server) .
- Fügen Sie nach Belieben WebRTC, HLS oder MSE hinzu.
Servieren Sie sie auf der Webseite.
Guten Appetit!
Nein, das ist noch nicht alles.
Die anfragenden Neuronen werden definitiv diese Frage stellen wollen: „Wie? Wirklich, wie kann das gemacht werden ? Wie wird es im Browser aussehen? “
Wir möchten Sie auf den minimalistischen WebRTC-Player aufmerksam machen, der als Küchentisch zusammengestellt wurde.
1) Verbinden Sie das Haupt-API-Skript flashphoner.js und das Skript my_player.js, die wir später erstellen, mit der Webseite.
<script type="text/javascript" src="../../../../flashphoner.js"></script> <script type="text/javascript" src=my_player.js"></script>
2) Initialisieren Sie die API im Hauptteil der Webseite
<body onload="init_api()">
3) Fügen Sie der Seite div hinzu, das als Container für die Videos dient. Stellen Sie die Größen und die Grenze dafür ein.
<div id="myVideo" style="width:320px;height:240px;border: solid 1px"></div>
4) Fügen Sie die Wiedergabetaste hinzu, auf die geklickt wird, um die Verbindung zum Server herzustellen und das Video abzuspielen
<input type="button" onclick="connect()" value="PLAY"/>
5) Jetzt erstellen wir das Skript my_player.js, das den Hauptcode unseres Players enthält. Beschreiben Sie die Konstanten und Variablen
var SESSION_STATUS = Flashphoner.constants.SESSION_STATUS; var STREAM_STATUS = Flashphoner.constants.STREAM_STATUS; var session;
6) API initialisieren, wenn eine HTML-Seite geladen wird
function init_api() { console.log("init api"); Flashphoner.init({ }); }
7) Stellen Sie über WebSocket eine Verbindung zum WCS-Server her. Ersetzen Sie "wss: //demo.flashphoner.com" durch Ihre WCS-Adresse, damit alles ordnungsgemäß funktioniert
function connect() { session = Flashphoner.createSession({urlServer: "wss://demo.flashphoner.com"}).on(SESSION_STATUS.ESTABLISHED, function(session){ console.log("connection established"); playStream(session); }); }
8) Übertragen Sie anschließend die folgenden beiden Parameter, "name" und "display", wobei "name" die RTSP-URL des wiedergegebenen Streams ist und "display" das Element von myVideo ist, in das unser Player installiert wird. Stelle auch hier die URL deines Streams ein, anstatt unserer.
function playStream() { var options = {name:"rtsp://b1.dnsdojo.com:1935/live/sys2.stream",display:document.getElementById("myVideo")}; var stream = session.createStream(options).on(STREAM_STATUS.PLAYING, function(stream) { console.log("playing"); }); stream.play(); }
Speichern Sie die Dateien und versuchen Sie, den Player zu starten. Wird Ihr RTSP-Stream abgespielt?
Als wir es getestet haben , wurde dieses gespielt: rtsp: //b1.dnsdojo.com: 1935 / live / sys2.stream.
Und so sieht es aus:
Der Spieler vor der Play-Schaltfläche wird angeklickt
Der Player mit einem Video gestartet
Es gibt nicht viel Code:
HTML
<!DOCTYPE html> <html lang="en"> <head> <script type="text/javascript" src="../../../../flashphoner.js"></script> <script type="text/javascript" src=my_player.js"></script> </head> <body onload="init_api()"> <div id="myVideo" style="width:320px;height:240px;border: solid 1px"></div> <br/><input type="button" onclick="connect()" value="PLAY"/> </body> </html>
Javascript
Als Server wird demo.flashphoner.com verwendet. Der vollständige Code des Beispiels ist unten am Fuß der Seite mit den Links verfügbar.
Viel Spaß beim Streamen!
Links
Spielercode auf Github
Integration eines RTSP-Players in eine Webseite oder eine mobile Anwendung