Alice ist eine erfahrene Full-Stack-Entwicklerin, die in der Lage ist, in einer Woche ein SAAS-Projektframework auf ihrem Lieblingsframework mit PHP zu schreiben. Bezüglich des Frontends bevorzugt sie Vue.js.
Ein Kunde kontaktiert Sie per Telegramm und bittet Sie, eine Website zu entwickeln, auf der sich Arbeitgeber und Arbeitnehmer treffen, um ein persönliches Interview zu führen. Persönlich bedeutet Face-to-Face, ein direkter Videokontakt in Echtzeit mit Video und Sprache. "Warum nicht Skype benutzen?", Mögen einige fragen. Zufällig versuchen seriöse Projekte - und jedes Startup versteht sich zweifellos als seriöses Projekt - aus verschiedenen Gründen, einen internen Kommunikationsdienst anzubieten, darunter:
1) Sie möchten ihre Benutzer nicht an Kommunikationspartner von Drittanbietern (Skype, Hangouts usw.) verleihen und sie im Dienst behalten.
2) Sie möchten ihre Kommunikation überwachen, z. B. Anrufverlauf und Interviewergebnisse.
3) Anrufe aufzeichnen (natürlich beide Parteien über die Aufzeichnung benachrichtigen).
4) Sie möchten nicht auf Richtlinien und Aktualisierungen von Diensten Dritter angewiesen sein. Jeder kennt diese Geschichte: Skype wurde aktualisiert und alles geht in Rauch auf ...
Es scheint eine leichte Aufgabe zu sein. WebRTC taucht auf, wenn Sie über das Thema googeln, und es scheint, als könnten Sie eine Peer-to-Peer-Verbindung zwischen zwei Browsern einrichten, aber es gibt noch einige Fragen:
1) Woher bekomme ich STUN / TURN Server?
2) Können wir ohne sie auskommen?
3) Wie zeichnet man einen Peer-to-Peer-WebRTC-Anruf auf?
4) Was passiert, wenn wir dem Anruf einen Dritten hinzufügen müssen, z. B. einen Personalleiter oder einen anderen Spezialisten des Arbeitgebers?
Es stellt sich heraus, dass WebRTC und Peer-to-Peer allein nicht ausreichen, und es ist nicht klar, was mit all dem zu tun ist, um die erforderlichen Videofunktionen des Dienstes zu starten.
Artikelinhalt
Server und API
Um diese Lücken zu schließen, werden Serverlösungen und eine Peer-Server-Peer-Architektur verwendet. Web Call Server 5.2 (im Folgenden: WCS) ist eine der Serverlösungen. Es ist eine Entwicklungsplattform, mit der Sie dem Projekt solche Videofunktionen hinzufügen können, ohne sich um STUN / TURN und die Stabilität von Peer-to-Peer-Verbindungen sorgen zu müssen.
Auf der höchsten Ebene ist WCS ein JavaScript-API + -Serverteil. Die API wird für die Entwicklung mit regulärem JavaScript auf der Browserseite verwendet, und der Server verarbeitet den Videoverkehr und fungiert als Stateful Proxy für den Medienverkehr.
Neben der JavaScript-API gibt es auch das Android SDK und das iOS SDK, die für die Entwicklung nativer mobiler Anwendungen für iOS bzw. Android erforderlich sind.
Das Veröffentlichen eines Streams auf dem Server (Streaming von einer Webcam zum Server) sieht beispielsweise folgendermaßen aus:
Web SDK
session.createStream({name:”stream123”}).publish();
Android SDK
publishStream = session.createStream(streamOptions) publishStream.publish();
iOS SDK
FPWCSApi2Stream *stream = [session createStream:options error:&error]; if(![stream publish:&error]) { //published without errors }
Auf diese Weise können wir nicht nur eine Webanwendung, sondern auch umfassende Funktionen für Google Play und den App Store mit Unterstützung für Video-Streaming implementieren. Wenn wir dem Bild auf oberster Ebene ein mobiles SDK hinzufügen, erhalten wir Folgendes:
Eingehende Streams
Der Streaming-Server (WCS) beginnt mit eingehenden Streams. Um etwas zu verbreiten, müssen wir es haben. Um Videostreams an die Zuschauer zu verteilen, müssen diese Streams auf den Server gelangen, den Arbeitsspeicher durchlaufen und über die Netzwerkkarte beendet werden. Daher ist die erste Frage, die wir stellen müssen, wenn wir uns mit dem Medienserver vertraut machen, welche Protokolle und Formate dieser verwendet, um Datenströme zu akzeptieren. Im Fall von WCS sind dies die folgenden Technologien: WebRTC, RTMP, RTSP, VOD, SIP / RTP.
Jedes der Protokolle kann von verschiedenen Clients verwendet werden. Beispielsweise kann nicht nur der Stream vom Browser über WebRTC eingegeben werden, sondern auch von einem anderen Server. In der folgenden Tabelle sind die möglichen Quellen für eingehenden Datenverkehr aufgeführt.
Wenn wir die Quellen des eingehenden Verkehrs durchgehen, können wir Folgendes hinzufügen:
Eingehendes WebRTC
Mit dem Web SDK können Sie nicht nur Kamera und Mikrofon erfassen, sondern auch die Funktionen der Browser-API nutzen, um über die Bildschirmfreigabe auf den Bildschirm zuzugreifen. Darüber hinaus können wir ein beliebiges Canvas-Element erfassen, auf das für die anschließende Übertragung nur Canvas-Streaming gezeichnet wird:
Aufgrund der Besonderheiten des Mobiltelefons können Android SDK und iOS SDK unterwegs zwischen der vorderen und hinteren Kamera des Geräts wechseln. Dies ermöglicht es uns, die Quelle während des Streamings zu wechseln, ohne den Stream anhalten zu müssen.
Der eingehende WebRTC-Stream kann auch von einem anderen WCS-Server mithilfe der Push-, Pull- und CDN-Methoden abgerufen werden, die später erläutert werden.
Eingehende rtmp
Das RTMP-Protokoll wird häufig in den bevorzugten OBS der Streamer sowie in anderen Encodern verwendet: Wirecast, Adobe Media Encoder, ffmpeg usw. Mit einem dieser Encoder können wir den Stream erfassen und an den Server senden.
Mithilfe der Push- und Pull-Methoden können wir auch einen RTMP-Stream von einem anderen Medienserver oder WCS-Server abrufen. Im Fall von Push ist der Initiator der Remote-Server. Im Fall von pull wenden wir uns an den lokalen Server, um den Stream vom Remote-Server abzurufen.
Eingehende rtsp
RTSP-Datenverkehrsquellen sind normalerweise IP-Kameras oder Medienserver von Drittanbietern, die das RTSP-Protokoll unterstützen. Obwohl der Initiator beim Herstellen einer RTSP-Verbindung WCS ist, wird der Audio- und Videodatenverkehr von der IP-Kamera zum WCS-Server geleitet. Daher betrachten wir den Stream von der Kamera als eingehend.
Eingehender Vod
Auf den ersten Blick scheint die VOD-Funktion (Video On Demand) ausschließlich mit ausgehenden Streams und der Wiedergabe von Dateien durch Browser verbunden zu sein. In unserem Fall ist dies jedoch nicht ganz richtig. WCS sendet eine mp4-Datei vom Dateisystem an localhost. Infolgedessen wird ein eingehender Stream erstellt, als stamme er aus einer Quelle eines Drittanbieters. Wenn wir einen Viewer auf eine mp4-Datei beschränken, erhalten wir den klassischen VOD, bei dem der Viewer den Stream erhält und ihn von Anfang an wiedergibt. Wenn wir einen Betrachter nicht auf eine mp4-Datei beschränken, erhalten wir VOD LIVE - eine Variante von VOD, bei der der Betrachter dieselbe Datei wie einen Stream abspielen kann und eine Verbindung zu dem Wiedergabepunkt herstellt, an dem sich alle anderen aktuell befinden (vor der Wiedergabe). aufgezeichneten Fernsehsendungsmodus).
Eingehendes SIP / RTP
Um eingehenden RTP-Verkehr innerhalb einer SIP-Sitzung zu empfangen, müssen wir einen Anruf mit einem SIP-Gateway eines Drittanbieters einrichten. Wenn die Verbindung erfolgreich hergestellt wurde, wird der Audio- und / oder Videodatenverkehr vom SIP-Gateway geleitet, der auf der WCS-Seite in den eingehenden Datenstrom eingeschlossen wird.
Ausgehende Streams
Nach dem Empfang des Streams auf dem Server können wir den empfangenen Stream auf Anfrage an einen oder mehrere Viewer replizieren. Der Viewer fordert einen Stream vom Player oder einem anderen Gerät an. Solche Streams werden als ausgehende Streams oder "Viewer-Streams" bezeichnet, da Sitzungen mit solchen Streams immer auf der Seite des Viewers / Players initiiert werden. Die Wiedergabetechnologien umfassen die folgenden Protokolle / Formate: WebRTC, RTMP, RTSP, MSE und HLS.
Ausgehendes WebRTC
In diesem Fall fungieren das Web SDK, Android SDK und iOS SDK als API für den Player. Ein Beispiel für das Abspielen eines WebRTC-Streams sieht folgendermaßen aus:
Web SDK
session.createStream({name:”stream123”}).play();
Android SDK
playStream = session.createStream(streamOptions); playStream.play();
iOS SDK
FPWCSApi2Stream *stream = [session createStream:options error:nil]; if(![stream play:&error]) { //published without errors }
Dies ist der Veröffentlichungs-API sehr ähnlich, mit dem einzigen Unterschied, dass stream.play () anstelle von stream.publish () zum Abspielen aufgerufen wird.
Ein WCS-Server eines Drittanbieters kann der Player sein, der angewiesen wird, den Stream mithilfe der Pull-Methode über WebRTC von einem anderen Server abzurufen oder den Stream im CDN abzurufen.
Ausgehende rtmp
Hier wird es hauptsächlich RTMP-Player geben - sowohl den bekannten Flash Player als auch Desktop- und Mobilanwendungen, die das RTMP-Protokoll verwenden und einen RTMP-Stream empfangen und wiedergeben. Trotz der Tatsache, dass Flash den Browser verlassen hat, wurde das für Videoübertragungen weit verbreitete RTMP-Protokoll beibehalten, und die fehlende native Unterstützung in Browsern verhindert nicht die Verwendung dieses recht erfolgreichen Protokolls in anderen Clientanwendungen. Es ist bekannt, dass RTMP in VR-Playern für mobile Anwendungen auf Android und iOS weit verbreitet ist.
Ausgehende rtsp
Der WCS-Server kann als RTSP-Server fungieren und den empfangenen Stream über RTSP als reguläre IP-Kamera verteilen. In diesem Fall muss der Player eine RTSP-Verbindung zum Server herstellen und den Stream zur Wiedergabe abrufen, als wäre es eine IP-Kamera.
Ausgehende mse
In diesem Fall fordert der Player mithilfe des Websocket-Protokolls einen Stream vom Server an. Der Server verteilt Audio- und Videodaten über Web-Sockets. Die Daten erreichen den Browser und werden in Blöcke konvertiert, die der Browser dank der standardmäßig unterstützten nativen MSE-Erweiterung wiedergeben kann. Der Player arbeitet letztendlich auf der Basis des HTML5-Videoelements.
Ausgehende hls
Hier fungiert WCS als HLS-Server oder Webserver, der HLS (HTTP Live Streaming) unterstützt. Sobald der eingehende Stream auf dem Server angezeigt wird, wird eine .m3u8 HLS-Wiedergabeliste generiert, die dem Player als Antwort auf eine HTTP-Anforderung übergeben wird. Die Wiedergabeliste beschreibt, welche Videosegmente der Player herunterladen und anzeigen soll. Der Player lädt Videosegmente herunter und spielt sie auf der Browserseite, auf dem Mobilgerät, auf dem Desktop, in der Apple TV-Set-Top-Box und überall dort ab, wo HLS-Unterstützung in Anspruch genommen wird.
Ein- und ausgehend
Insgesamt haben wir 5 Arten von eingehenden und ausgehenden Streams. Sie sind in der Tabelle aufgeführt:
Das heißt, wir können die Streams auf den Server hochladen, eine Verbindung zu ihnen herstellen und sie mit geeigneten Playern abspielen. Verwenden Sie das Web SDK, um einen WebRTC-Stream abzuspielen. Verwenden Sie einen HLS-Player usw., um einen WebRTC-Stream als HLS abzuspielen. Ein Stream kann von vielen Zuschauern gespielt werden. Eins-zu-viele-Sendungen funktionieren.
Beschreiben wir nun, welche Aktionen mit Streams ausgeführt werden können.
Eingehende Stream-Manipulation
Ausgehende Streams mit Zuschauern sind nicht einfach zu manipulieren. Wenn der Viewer eine Sitzung mit dem Server aufgebaut hat und bereits einen Stream abruft, können keine Änderungen daran vorgenommen werden, ohne die Sitzung zu unterbrechen. Aus diesem Grund finden alle Manipulationen und Änderungen an eingehenden Streams zu dem Zeitpunkt statt, an dem die Replikation noch nicht erfolgt ist. Der Stream, der geändert wurde, wird dann an alle verbundenen Viewer verteilt.
Stream-Optionen umfassen:
- Aufnahme
- einen Schnappschuss machen
- Hinzufügen eines Streams zum Mixer
- Stream-Transcodierung
- Hinzufügen eines Wasserzeichens
- Hinzufügen eines FPS-Filters
- Bilddrehung um 90, 180, 270 Grad
Aufzeichnung eingehender Streams
Vielleicht die verständlichste und am häufigsten anzutreffende Funktion. In der Tat müssen in vielen Fällen Streams aufgezeichnet werden: Webinare, Englischunterricht, Konsultationen usw.
Die Aufzeichnung kann entweder mit dem Web SDK oder der REST-API mit einer speziellen Anforderung gestartet werden:
/stream/startRecording {}
Das Ergebnis wird als mp4-Datei im Dateisystem gespeichert.
Einen Schnappschuss machen
Ebenso häufig ist es, Bilder des aktuellen Streams aufzunehmen, um Symbole auf der Site anzuzeigen. Zum Beispiel haben wir 50 Streams in einem Videoüberwachungssystem, von denen jeder eine IP-Kamera als Quelle hat. Das Anzeigen aller 50 Threads auf einer Seite ist nicht nur problematisch für Browser-Ressourcen, sondern auch sinnlos. Im Fall von 30 FPS beträgt die Gesamt-FPS des sich ändernden Bildes 1500, und das menschliche Auge akzeptiert eine solche Anzeigefrequenz einfach nicht. Als Lösung können wir automatisches Slicing oder Snapshot-Erstellung nach Bedarf konfigurieren. In diesem Fall können Bilder mit einer beliebigen Frequenz auf der Site angezeigt werden, z. B. 1 Bild in 10 Sekunden. Snapshots können über die REST-API aus dem SDK entfernt oder automatisch aufgeteilt werden.
Der WCS-Server unterstützt die REST-Methode zum Empfangen von Snapshots:
/stream/snapshot
Hinzufügen eines Streams zum Mixer
Ein Bild aus zwei oder mehr Quellen kann zu einem Bild kombiniert werden, um es den Betrachtern anzuzeigen. Dieser Vorgang wird als Mischen bezeichnet. Grundlegende Beispiele: 1) Videoüberwachung von mehreren Kameras auf dem Bildschirm in einem Bild. 2) Videokonferenz, bei der jeder Benutzer einen Stream empfängt, in den der Rest eingemischt ist, um Ressourcen zu sparen. Der Mischer wird über die REST-API gesteuert und verfügt über einen MCU-Betriebsmodus zum Erstellen von Videokonferenzen.
REST-Befehl zum Hinzufügen eines Streams zum Mixer:
/mixer/startup
Stream-Transcodierung
Streams müssen manchmal komprimiert werden, um sie an bestimmte Gruppen von Clientgeräten nach Auflösung und Bitrate anzupassen. Hierfür wird die Transcodierung verwendet. Die Transkodierung kann auf der Web-SDK-Seite, über die REST-API oder automatisch über einen speziellen Transkodierungsknoten im CDN aktiviert werden. Beispielsweise kann ein Video mit einer Auflösung von 1280 x 720 auf 640 x 360 transkodiert werden, um es aus einer geografischen Region mit traditionell geringer Bandbreite an Kunden zu verteilen. Wo sind deine Satelliten, Elon Musk?
Verwendete REST-Methode:
/transcoder/startup
Hinzufügen eines Wasserzeichens
Es ist bekannt, dass Inhalte gestohlen und in WebRip umgewandelt werden können, unabhängig vom Schutz des Players. Wenn Ihr Inhalt wertvoll ist, können Sie ein Wasserzeichen oder Logo einbetten, was die weitere Verwendung und öffentliche Anzeige erheblich erschwert. Um ein Wasserzeichen hinzuzufügen, laden Sie einfach ein PNG-Bild hoch und es wird durch Transcodierung in den Videostream eingefügt. Daher müssen Sie auf der Serverseite einige CPU-Kerne vorbereiten, falls Sie dem Stream dennoch ein Wasserzeichen hinzufügen möchten. Um das Wasserzeichen nicht durch Umcodierung auf dem Server zu erstellen, ist es besser, es direkt auf dem Encoder / Streamer hinzuzufügen, was häufig eine solche Möglichkeit bietet.
Hinzufügen eines FPS-Filters
In einigen Fällen ist es erforderlich, dass der Stream eine gerade FPS (Frames pro Sekunde) aufweist. Dies kann nützlich sein, wenn wir den Stream zu einer Drittanbieter-Ressource wie Youtube oder Facebook streamen oder ihn mit einem empfindlichen HLS-Player abspielen. Das Filtern erfordert auch eine Transcodierung. Stellen Sie daher sicher, dass Sie die Leistung Ihres Servers richtig einschätzen und 2 Kerne pro Stream vorbereiten, wenn ein solcher Vorgang geplant ist.
Bilddrehung um 90, 180, 270 Grad
Mobile Geräte können die Auflösung des veröffentlichten Streams in Abhängigkeit vom Drehwinkel ändern. Sie haben beispielsweise mit dem Streaming begonnen, das iPhone horizontal gehalten und es dann gedreht. Gemäß der WebRTC-Spezifikation sollte der Streamer-Browser des Mobilgeräts (in diesem Fall iOS Safari) dem Server die Rotation signalisieren. Der Server muss dieses Ereignis wiederum an alle Abonnenten senden. Andernfalls wäre es so: Der Streamer legt das Telefon auf die Seite, sieht die Kamera jedoch immer noch vertikal, während der Betrachter ein gedrehtes Bild sieht. Um mit Rotationen auf der SDK-Seite zu arbeiten, ist die entsprechende cvoExtension-Erweiterung enthalten.
Verwaltung eingehender Streams
Automatisch - Die Konfiguration wird normalerweise in den Einstellungen serverseitig festgelegt.
Stream-Relaying
Relaying ist auch eine Option zum Manipulieren von Streams, die auf den Server gelangen. Es besteht darin, den Stream auf einen Server eines Drittanbieters zu zwingen. Relaying ist gleichbedeutend mit Neuveröffentlichung, Push, Injection.
Die Weiterleitung kann mit einem der folgenden Protokolle implementiert werden: WebRTC, RTMP, SIP / RTP. Die Tabelle zeigt die Richtung, in die der Stream weitergeleitet werden kann.
WebRTC-Weiterleitung
Ein Stream kann an einen anderen WCS-Server weitergeleitet werden, wenn es aus irgendeinem Grund erforderlich ist, den Stream auf einem anderen Server verfügbar zu machen. Die Weitergabe erfolgt über die REST-API über die Methode / push. Nach Erhalt einer solchen REST-Anforderung stellt WCS eine Verbindung zum angegebenen Server her und veröffentlicht einen Server-Server-Stream an diesen. Danach steht der Stream für die Wiedergabe auf einem anderen Computer zur Verfügung.
/pull/push
- Verwendete REST-Methode
RTMP-Relaying
Wie bei der WebRTC-Weiterleitung ist auch eine RTMP-Weiterleitung an einen anderen Server möglich. Der Unterschied besteht nur im Relaisprotokoll. RTMP-Relaying wird auch über / push ausgeführt und ermöglicht die Übertragung des Streams an RTMP-Server von Drittanbietern sowie an Dienste, die RTMP-Ingest unterstützen: Youtube, Facebook-Streaming usw. Somit kann der WebRTC-Stream an RTMP weitergeleitet werden. Wir können ebenso gut jeden anderen Stream, der in den Server gelangt, zum Beispiel RTSP oder VOD, an RTMP weiterleiten.
Der Videostream wird mithilfe von REST-Aufrufen an einen anderen RTMP-Server weitergeleitet.
/push/startup
- REST-Aufruf verwendet
SIP / RTP-Relaying
Es wird selten Funktion verwendet. Am häufigsten wird es in Unternehmen eingesetzt. Zum Beispiel, wenn wir einen SIP-Anruf mit einem externen SIP-Konferenzserver herstellen und den Audio- oder Videostream auf diesen Anruf umleiten müssen, damit das Konferenzpublikum eine Art Videoinhalt sieht: „Bitte sehen Sie sich dieses Video an“ oder „Kollegen“ Sehen wir uns jetzt einen IP-Kamerastream von der Baustelle an. “ Wir müssen berücksichtigen, dass in diesem Fall die Konferenz selbst existiert und auf einem externen VKS-Server mit SIP-Unterstützung verwaltet wird (kürzlich haben wir die Lösung von Polycom DMA getestet), während wir nur den vorhandenen Stream verbinden und weiterleiten dieser Server. Die REST-API-Funktion heißt / inject und dient nur für diesen Fall.
REST-API-Befehl:
/call/inject_stream/startup
Verbinden von Servern mit einem CDN-Netzwerk zur Inhaltsverarbeitung
Normalerweise verfügt ein Server über eine begrenzte Menge an Ressourcen. Daher ist für große Online-Sendungen, bei denen das Publikum Tausende und Zehntausende zählt, eine Skalierung erforderlich. Mehrere WCS-Server können zu einem CDN-Netzwerk für die Bereitstellung von Inhalten zusammengefasst werden. Intern arbeitet CDN über WebRTC, um die Latenz während des Streamings gering zu halten.
Der Server kann in einer der folgenden Rollen konfiguriert werden: Origin, Edge oder Transcoder. Origin-Server empfangen Datenverkehr und verteilen ihn an die Edgeserver, die für die Übermittlung des Streams an die Betrachter verantwortlich sind. Wenn es erforderlich ist, einen Stream in mehreren Auflösungen vorzubereiten, werden Transcoder-Knoten in das Schema aufgenommen, die die ressourcenintensive Aufgabe des Transcodierens von Streams übernehmen.
Um es zusammenzufassen
WCS 5.2 ist ein Server für die Entwicklung von Anwendungen mit Audio- und Video-Echtzeitunterstützung für Browser und Mobilgeräte. Für die Entwicklung stehen vier APIs zur Verfügung: Web-SDK, iOS-SDK, Android-SDK und REST-API. Wir können Videostreams mithilfe von fünf Protokollen auf dem Server veröffentlichen (Feed): WebRTC, RTMP, RTSP, VOD, SIP / RTP. Vom Server aus können wir Streams mit Playern unter Verwendung von fünf Protokollen abspielen: WebRTC, RTMP, RTSP, MSE, HLS. Streams können gesteuert werden und Vorgänge wie Aufzeichnen, Aufteilen von Schnappschüssen, Mischen, Transcodieren, Hinzufügen eines Wasserzeichens, Filtern von FPS und Übertragen von Videodrehs auf Mobilgeräten durchlaufen. Streams können über WebRTC- und RTMP-Protokolle an andere Server weitergeleitet und zu SIP-Konferenzen umgeleitet werden. Server können zu einem Content Delivery-Netzwerk zusammengefasst und für die Verarbeitung einer beliebigen Anzahl von Videostreams skaliert werden.
Was Alice wissen muss, um mit dem Server zu arbeiten
Der Entwickler muss Linux beherrschen. Die folgenden Befehle in der Befehlszeile sollten keine Verwirrung stiften:
tar -xvzf wcs5.2.tar.gz
cd wcs5.2
./install.sh
tail -f flashphoner.log
ps aux | grep WebCallServer
top
Man muss auch Vanilla JavaScript kennen, wenn es um Webentwicklung geht.
//publishing the stream session.createStream({name:'mystream'}).publish(); //playing the stream session.createStream({name:'mystream'}).play();
Die Möglichkeit, mit dem Back-End zu arbeiten, kann sich ebenfalls als nützlich erweisen.
WCS kann nicht nur Steuerbefehle über die REST-API empfangen, sondern auch Hooks senden, d. H. Benachrichtigungen über Ereignisse, die auf der REST-API auftreten. Wenn Sie beispielsweise versuchen, eine Verbindung über einen Browser oder eine mobile Anwendung herzustellen, löst WCS den Hook / connect aus, und wenn Sie versuchen, einen Stream abzuspielen, löst es den Hook playStream aus. Daher muss der Entwickler ein wenig in die Fußstapfen des Back-Enders treten, der in der Lage ist, sowohl einen einfachen REST-Client als auch einen kleinen REST-Server für die Verarbeitung von Hooks zu erstellen.
REST-API-Beispiel
/rest-api/stream/find_all
- Beispiel einer REST-API zum Auflisten von Streams auf dem Server
Beispiel für einen REST-Hook
https://myback-end.com/hook/connect
- REST Hook / Connect-Verarbeitung auf der Backend-Seite.
Linux, JavaScript, REST-Client / Server - drei Elemente, die ausreichen, um einen Produktionsdienst auf der WCS-Plattform zu entwickeln, der mit Videostreams arbeitet.
Für die Entwicklung mobiler Anwendungen sind Kenntnisse in Java und Objective-C für Android bzw. iOS erforderlich.
Installation und Start
Es gibt drei Möglichkeiten, WCS heute schnell zu starten:
1) Installieren Sie Ubuntu 16.x LTS oder Ubuntu 18.x LTS usw. auf Ihrem Centos7. oder sich von einem Artikel aus der Dokumentation leiten lassen.
oder
2) Holen Sie sich ein fertiges Image auf Amazon EC2 .
oder
3) Holen Sie sich ein fertiges Server-Image auf Digital Ocean .
Starten Sie eine spannende Projektentwicklung mit Streaming-Videofunktionen.
Der Übersichtsartikel erwies sich als ziemlich groß. Vielen Dank für die Geduld, es zu lesen.
Viel Spaß beim Streamen!
Links
WCS 5.2 - WebRTC Server
Installation und Start
Installation und Start von WCS
Starten Sie ein fertiges Image auf Amazon EC2
Starten Sie das vorgefertigte Image des Servers auf DigitalOcean
SDK
Dokumentations-Web-SDK
Dokumentation Android SDK
Dokumentation iOS SDK
Fälle
Eingehende Streams
Ausgehende Streams
Verwaltung von Streams
Stream-Relaying
CDN für WebRTC-Streaming mit niedriger Latenz
Dokumentation
Dokumentation Web Call Server 5.2