Alice ist eine erfahrene Full-Stack-Entwicklerin und kann mit PHP in einer Woche ein SAAS-Projekt-Framework in ihrem Lieblings-Framework schreiben. Am vorderen Ende bevorzugt er Vue.js.
Ein Kunde, der unbedingt eine Website entwickeln muss, die der Treffpunkt von Arbeitgeber und Arbeitnehmer für ein persönliches Gespräch ist, wird an einem Telegramm geklopft. Vollzeit - bedeutet direkten Videokontakt in Echtzeit mit Video und Sprache auf Augenhöhe.
"Warum nicht Skype?" Sie fragen. Es ist einfach so gekommen, dass ernsthafte Projekte und jedes Startup, das sich zweifellos als solches versteht, aus einer Vielzahl von Gründen versuchen, einen internen Kommunikationsdienst anzubieten, darunter:
1) Geben Sie Ihre Benutzer nicht an externe Kommunikatoren weiter (Skype,
Treffpunkte usw.). Lass sie im Dienst.
2) Überwachen Sie die Kommunikation: Anrufverlauf, Interviewergebnisse.
3) Anrufe aufzeichnen (natürlich beide Parteien über die Aufzeichnung benachrichtigen).
4) Verlassen Sie sich nicht auf Richtlinien und Aktualisierungen von Diensten von Drittanbietern. Jeder kennt diese Geschichte: Skype aktualisiert, und es begann ...
Die Aufgabe sieht einfach aus. WebRTC ist über das Thema gegoogelt und es sieht so aus, als könnten Sie eine Peer-to-Peer-Verbindung zwischen zwei Browsern einrichten. Es bleiben jedoch folgende Fragen offen:
1) Woher bekommen Sie STUN / TURN Server?
2) Ist es möglich, ohne sie auszukommen?
3) Aufzeichnen eines Peer-to-Peer-WebRTC-Anrufs
4) Was passiert, wenn Sie einen Dritten zum Anruf hinzufügen müssen, z. B. einen Personalleiter oder einen anderen Spezialisten des Arbeitgebers.
Es stellt sich heraus, dass nur WebRTC und Peer-to-Peer nicht ausreichen, und es ist nicht klar, was damit zu tun ist, um die erforderlichen Videofunktionen des Dienstes zu starten.
Artikelinhalt
Server und API
Um all diese White Spots zu schließen, werden Serverlösungen und eine Peer-Server-Peer-Architektur verwendet. Web Call Server 5.2 WCS ist eine der Serverlösungen - eine Entwicklungsplattform, mit der Sie dem Projekt solche Videofunktionen hinzufügen können, ohne sich um die Stabilität von STUN / TURN- und Peer-to-Peer-Verbindungen sorgen zu müssen.
Auf der höchsten Ebene ist WCS ein JavaScript-API + -Serverteil. Die API wird verwendet, um auf der Browserseite normales JavaScript zu entwickeln, 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 einem Server (Streaming eines Streams 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 Sie nicht nur eine Webanwendung implementieren, sondern auch umfassende Funktionen für Google Play und den App Store mit Unterstützung für Video-Streaming. Fügen Sie dem Bild der obersten Ebene mobile SDKs hinzu. Es wird sich wie folgt herausstellen:
Eingehende Streams
Der Streaming-Server (WCS) beginnt mit eingehenden Streams. Um etwas zu verschenken, muss man es haben. Um Videostreams an Zuschauer zu verteilen, ist es erforderlich, dass diese Streams in den Server gelangen, dessen RAM durchlaufen und über die Netzwerkkarte beendet werden. Daher ist die erste Frage, die Sie sich stellen sollten, wenn Sie sich mit einem Medienserver vertraut machen, folgende: Für welche Protokolle und Formate akzeptiert dieser Streams. 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 über WebRTC nicht nur ein Stream von einem Browser eingegeben werden, sondern auch von einem anderen Server. Wir zeigen die möglichen Quellen des eingehenden Verkehrs in der Tabelle an.
Wenn Sie die Quellen des eingehenden Datenverkehrs durchgehen, können Sie Folgendes hinzufügen:
Eingehendes WebRTC
Mit Web SDK können Sie nicht nur die Kamera und das Mikrofon erfassen, sondern auch die Funktionen der Browser-API für den Zugriff auf die Bildschirmfreigabe verwenden. Darüber hinaus können Sie ein beliebiges Canvas-Element erfassen, auf das für die anschließende Übertragung nur Canvas-Streaming gezeichnet wird.
Android SDK und iOS SDK können aufgrund mobiler Besonderheiten im Handumdrehen zwischen der vorderen und hinteren Kamera des Geräts wechseln. Auf diese Weise können Sie die Quelle während des Streamings wechseln, ohne den Stream zu stoppen.
Der eingehende WebRTC-Stream kann auch von einem anderen WCS-Server mit den Methoden Push, Pull und CDN abgerufen werden, auf die später noch eingegangen wird.
Inbound rtmp
Das RTMP-Protokoll wird häufig in den bevorzugten OBS-Streamern und in anderen Encodern verwendet: Wirecast, Adobe Media Ensourcer, ffmpeg usw. Mit einem dieser Encoder können Sie den Stream erfassen und an den Server senden.
Sie können einen RTMP-Stream auch von einem anderen Medienserver oder WCS-Server abrufen
mit Push-and-Pull-Methoden. Im Fall von Push ist der Initiator der Remote-Server. Im Fall von pull wenden wir uns an den lokalen, um den Stream vom fernen zu ziehen.
Eingehendes RTSP
Die Quellen des RTSP-Verkehrs sind normalerweise IP-Kameras oder Medienserver von Drittanbietern, die das RTSP-Protokoll unterstützen. Obwohl beim Herstellen einer RTSP-Verbindung WCS als Initiator fungiert, wird der Audio- und Videoverkehr von der IP-Kamera zum WCS-Server geleitet. Daher betrachten wir den Stream von der Kamera als eingehend.
Eingehende VOD
Auf den ersten Blick scheint die VOD-Funktion (Video On Demand) ausschließlich mit ausgehenden Streams und der Wiedergabe der Datei durch Browser verbunden zu sein. In unserem Fall ist das ein bisschen falsch. WCS übersetzt die mp4-Datei ehrlich vom Dateisystem in localhost. Dadurch 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 aufnimmt und ihn von Anfang an wiedergibt. Wenn nicht beschränkt, erhalten wir VOD LIVE - eine Variation von VOD, bei der die Zuschauer die gleiche Datei wie einen Stream abspielen können und eine Verbindung zu dem Wiedergabepunkt herstellen, an dem sich alle anderen gerade befinden (voraufgezeichneter Fernsehmodus).
Eingehendes SIP / RTP
Um eingehenden RTP-Verkehr innerhalb einer SIP-Sitzung zu empfangen, müssen Sie einen Anruf mit einem SIP-Gateway eines Drittanbieters einrichten. Nach erfolgreicher Verbindung wird Audio- und / oder Videodatenverkehr vom SIP-Gateway geleitet, der auf der WCS-Seite in einen eingehenden Datenstrom eingeschlossen wird.
Ausgehende Streams
Nach dem Empfang des Streams auf dem Server können Sie 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 "Streams von Zuschauern" bezeichnet, da Sitzungen mit solchen Streams immer auf der Seite des Zuschauers / Players initiiert werden. Die Wiedergabetechnologien umfassen die folgenden Protokolle / Formate: WebRTC, RTMP, RTSP, MSE, 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 stattdessen
stream.publish (), stream.play () wird zur Wiedergabe aufgerufen.
Ein Player kann auch ein WCS-Server eines Drittanbieters sein, der den Befehl erhält, mithilfe der Pull-Methode einen Stream über WebRTC von einem anderen Server abzurufen oder einen Stream innerhalb von 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, empfangen und spielen einen RTMP-Stream. Tatsache ist, dass trotz der Tatsache, dass Flash den Browser verlassen hat, das RTMP-Protokoll, das häufig für Video-Broadcasts verwendet wird, und die mangelnde native Unterstützung in Browsern die Verwendung dieses recht erfolgreichen Protokolls in anderen Client-Anwendungen nicht verhindern. Es ist bekannt, dass RTMP in VR-Playern für mobile Anwendungen für Android und iOS weit verbreitet ist.
Ausgehender 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 stellt Audio- und Videodaten auf Web-Sockets bereit. 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.
Ausgehendes HLS
Hier fungiert WCS als HLS-Server oder Webserver, der HLS (HTTP Live Streaming) unterstützt. Nachdem der eingehende Stream auf dem Server angezeigt wurde, wird eine HLS-Wiedergabeliste im .m3u8-Format generiert, die dem Player als Antwort auf eine HTTP-Anforderung übergeben wird. Die Wiedergabeliste beschreibt, welche Abschnitte des Videos der Player herunterladen und anzeigen soll. Der Player lädt Videosegmente herunter und spielt sie auf einer Browserseite, auf einem mobilen Gerät, auf einem Desktop, in einer Apple TV-Set-Top-Box und überall dort ab, wo HLS-Unterstützung in Anspruch genommen wird.
Posteingang und Postausgang
Insgesamt haben wir 5 eingehende und die gleiche Anzahl ausgehender Stream-Typen. Wir listen auf
sie in der Tabelle:
Das heißt Wir können Streams zum Server leiten und eine Verbindung zu ihnen herstellen und für diese Angelegenheit geeignete Spieler spielen. Verwenden Sie das Web SDK, um den WebRTC-Stream abzuspielen. Verwenden Sie einen HLS-Player usw., um den WebRTC-Stream als HLS abzuspielen. Ein Stream kann von vielen Zuschauern gespielt werden. Eins-zu-viele-Sendungen funktionieren.
Nun werden wir sagen, welche Aktionen mit Streams durchgeführt werden können.
Eingehende Stream-Manipulation
Ausgehende Streams, auf denen Zuschauer sitzen, manipulieren nicht besonders. Wenn der Viewer eine Sitzung mit dem Server eingerichtet hat und bereits eine Art Stream empfängt, 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 sich geändert hat, wird dann an alle verbundenen Betrachter weitergeleitet.
Operationen auf Streams umfassen:
- aufzeichnen
- Schnappschussentfernung
- Stream zum Mixer hinzufügen
- Stream-Transcodierung
- Wasserzeichen hinzufügen
- FPS-Filter hinzufügen
- Bilddrehung um 90, 180, 270 Grad
Aufnahme eingehender Streams
Vielleicht die verständlichste und am häufigsten anzutreffende Funktion. Streams müssen in vielen Fällen aufgezeichnet werden: Webinar, Englischunterricht, Beratung 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.
Snapshot-Entfernung
Ebenso häufig ist es, Bilder des aktuellen Streams aufzunehmen, um Symbole auf der Site anzuzeigen. Sie haben beispielsweise 50 Streams in einem Videoüberwachungssystem, von denen jeder eine Quelle für eine IP-Kamera hat. Das Anzeigen aller 50 Threads auf einer Seite ist nicht nur problematisch für Browser-Ressourcen, sondern auch sinnlos. Bei 30 Bildern pro Sekunde beträgt die Gesamtgeschwindigkeit des sich ändernden Bildes 1500 Bilder pro Sekunde, und das menschliche Auge akzeptiert diese Frequenz einfach nicht. Als Lösung können Sie das automatische Schneiden oder Aufnehmen von Snapshots nach Bedarf konfigurieren. In diesem Fall können Sie Bilder auf einer Site mit einer beliebigen Häufigkeit anzeigen, z. B. 1 Frame in 10 Sekunden. Snapshots können über die REST-API aus dem SDK entfernt oder automatisch aufgeteilt werden.
Der WCS-Server unterstützt die folgende REST-Methode zum Entfernen von Snapshots:
/stream/snapshot
Stream zum Mixer hinzufügen
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 erhält, um Ressourcen zu sparen, in die der Rest gemischt wird. Der Mixer 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 sich für 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. Wenn Sie beispielsweise ein Video mit einer Auflösung von 1280 x 720 eingeben, kann es für die Verteilung an Kunden aus einer geografischen Region mit einer traditionell geringen Bandbreite auf 640 x 360 transcodiert werden. Wo sind deine Gefährten, Elon Musk?
Verwendete REST-Methode:
/transcoder/startup
Hinzufügen eines Wasserzeichens
Es ist bekannt, dass jeder Inhalt gestohlen und in WebRip umgewandelt werden kann, unabhängig davon, mit welchem Schutz der Player ausgestattet ist. Wenn Ihr Inhalt wirklich so wertvoll ist, können Sie ein Wasserzeichen oder Logo einbetten, das 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 sich noch entscheiden
Füge dem Stream ein Wasserzeichen hinzu. Um das Wasserzeichen auf dem Server nicht durch Umcodierung zu verdrehen, ist es besser, es direkt zum Encoder / Streamer hinzuzufügen, der
bieten oft eine solche Gelegenheit.
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 an eine Drittanbieter-Ressource wie Youtube oder Facebook weiterleiten oder ihn mit einem empfindlichen HLS-Player abspielen. Das erneute Filtern erfordert eine Umcodierung. Berechnen Sie daher die Stärke Ihres Servers und bereiten Sie die Konfiguration sowie 2 Cores pro Stream vor, wenn ein solcher Vorgang geplant ist.
Drehen Sie das Bild um 90, 180, 270 Grad
Mobile Geräte können die Auflösung des veröffentlichten Streams in Abhängigkeit vom Drehwinkel ändern. Zum Beispiel haben sie angefangen zu streamen, das iPhone horizontal gehalten und sich dann auf die Seite gedreht. Gemäß der WebRTC-Spezifikation sollte der Streamer-Browser des Mobilgeräts und in diesem Fall iOS Safari eine Wende an den Server signalisieren. Der Server muss dieses Ereignis wiederum an alle Abonnenten senden. Sonst hätte es sich herausgestellt
so dass der streamer das telefon auf die seite legt, seine kamera aber noch aufrecht sieht, während die zuschauer auf der seite gestapelt sind. Um mit Umdrehungen auf der SDK-Seite zu arbeiten, ist die entsprechende cvoExtension-Erweiterung enthalten.
Wo ist die Kontrolle der eingehenden Streams
Automatisch - Die Konfiguration wird normalerweise serverseitig in eingestellt
Einstellungen.
Stream-Relay
Relaying ist auch eine Option zum Bearbeiten von Streams, die auf den Server gelangen, und besteht darin, den Stream auf einen Server eines Drittanbieters zu zwingen. Ein Synonym für Relaying sind solche Wörter wie: Replikation, Push, Injektion.
Das Relais 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-Relais
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 mit der 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
- die verwendete REST-Methode.
RTMP-Relais
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. Mit dem gleichen Erfolg in RTMP können Sie jeden anderen Stream weiterleiten, der auf den Server gelangt, z. B. RTSP oder VOD.
Der Videostream wird mithilfe von REST-Aufrufen an einen anderen RTMP-Server weitergeleitet
/push/startup
- REST-Aufruf verwendet.
SIP / RTP-Relais
Selten genutzte Funktion. Meistens in Unternehmen. Wenn Sie beispielsweise einen SIP-Anruf mit einem externen SIP-Konferenzserver einrichten und den Audio- oder Videostream auf diesen Anruf umleiten möchten, damit das Konferenzpublikum einige Videoinhalte sieht: "Bitte sehen Sie sich dieses Video an" oder "Kollegen", und schauen wir uns jetzt den Stream mit IP an Kameras von der Baustelle. “ Es versteht sich, dass die Konferenz selbst existiert und in diesem Fall auf einem externen VKS-Server mit SIP-Unterstützung verwaltet wird (kürzlich haben wir die Lösung von Polycom DMA getestet). Wir verbinden einfach den vorhandenen Stream und leiten ihn an diesen Server weiter. 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
Ein Server verfügt normalerweise über eine begrenzte Menge an Ressourcen. Daher ist für große Online-Sendungen, bei denen das Konto des Publikums Tausende und Zehntausende umfasst, 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, Transcoder. Origin-Server - Empfangen Sie Datenverkehr und verteilen Sie ihn an die Edge-Knoten der Edge-Server, 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. Sie 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 Sie Streams mit Playern mit fünf Protokollen abspielen: WebRTC, RTMP, RTSP, MSE, HLS. Streams können gesteuert und ausgeführt werden, z. B .: Aufzeichnen, Aufteilen von Schnappschüssen, Mischen, Transcodieren, Hinzufügen eines Wasserzeichens, Filtern von FPS, Senden von Videos auf Mobilgeräten. Streams können über WebRTC- und RTMP-Protokolle an andere Server weitergeleitet und zu SIP-Konferenzen umgeleitet werden. Server können in ein Content Delivery-Netzwerk integriert 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. Mannschaften dieser Art in
Die Befehlszeile sollte keine Verwirrung stiften:
tar -xvzf wcs5.2.tar.gz
cd wcs5.2
./install.sh
tail -f flashphoner.log
ps aux | grep WebCallServer
top
Vanilla JavaScript muss auch in der Lage sein, wenn es darum geht, für zu entwickeln
Web
// session.createStream({name:'mystream'}).publish(); // session.createStream({name:'mystream'}).play();
Die Möglichkeit, mit dem Backend zu arbeiten, ist ebenfalls nützlich.
WCS kann nicht nur Steuerbefehle über die REST-API empfangen, sondern auch Hooks senden - Benachrichtigungen über die darin auftretenden Ereignisse.
Wenn Sie beispielsweise versuchen, eine Verbindung über einen Browser oder eine mobile Anwendung herzustellen, ruft WCS den / connect-Hook auf, und wenn Sie versuchen, einen Stream abzuspielen, wird der playStream-Hook aufgerufen. Daher muss sich der Entwickler ein wenig mit dem Back-End auseinandersetzen, das sowohl einen einfachen REST-Client als auch einen kleinen REST-Server für die Verarbeitung von Hooks schreiben kann.
REST-API-Beispiel
/rest-api/stream/find_all
- Ein Beispiel für eine REST-API, in der die Liste der Streams auf einem Server aufgeführt ist
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 sind die drei Elemente, die
genug, um einen Produktionsdienst auf der WCS-Plattform zu entwickeln, der funktioniert
mit Video-Streams.
Für die Entwicklung mobiler Apps sind Kenntnisse in Java und Objective-C erforderlich
für Android bzw. iOS.
Installation und Start
Es gibt drei Möglichkeiten, WCS heute schnell zu starten:
1) Installieren Sie auf Ihrem Centos7 oder Ubuntu 16.x LTS oder Ubuntu 18.x LTS, und
etc. angeleitet von einem Artikel aus der Dokumentation .
oder
2) Nehmen Sie das fertige Bild in Amazon EC2 auf .
oder sonst
3) Nehmen Sie das fertige Server-Image auf DigitalOcean .
Starten Sie eine spannende Projektentwicklung mit Streaming-Videofunktionen.
Der Übersichtsartikel erwies sich als recht umfangreich. Danke dafür.
Geduld lesen.
Viel Spaß beim Streamen!
Referenzen
WCS 5.2 - WebRTC Server
Installation und Start
Installieren Sie WCS und führen Sie es aus
Starten Sie ein vorgefertigtes Image in Amazon AWS
DigitalOcean
SDK
Web SDK
Android SDK
iOS SDK
WebRTC CDN
Die Dokumentation
Web Call Server 5.2