Alice est une développeur full-stack expérimentée et est capable d'écrire un framework de projet SAAS dans son framework préféré en utilisant php en une semaine. À l'avant, il préfère Vue.js.
Un télégramme est frappé par un client qui, par tous les moyens, doit développer un site Web, qui sera le lieu de rencontre de l'employeur et de l'employé pour mener une entrevue en personne. À temps plein - signifie un contact visuel direct, en direct avec la vidéo et la voix.
"Pourquoi pas skype?", Demandez-vous. Il se trouve que des projets sérieux, et chaque startup, se considère sans aucun doute comme telle, essaient d'offrir un service de communication interne pour diverses raisons, notamment:
1) Ne confiez pas vos utilisateurs à des communicateurs tiers (skype,
Hangouts, etc.). Laissez-les au service.
2) Surveiller les communications: historique des appels, résultats des entretiens.
3) Enregistrer les appels (bien sûr, notifier les deux parties de l'enregistrement).
4) Ne dépendez pas des politiques et des mises à jour des services tiers. Tout le monde connaît cette histoire: Skype a été mis à jour et ça a commencé ...
La tâche semble simple. WebRTC est googlé sur le sujet et il semble que vous puissiez organiser une connexion d'égal à égal entre deux navigateurs, mais des questions demeurent:
1) Où trouver les serveurs STUN / TURN
2) Est-il possible de s'en passer
3) Comment enregistrer un appel WebRTC poste à poste
4) Que se passera-t-il si vous devez ajouter un tiers à l'appel, par exemple, un responsable RH ou un autre spécialiste de l'employeur.
Il s'avère que WebRTC et peer-to-peer ne suffisent pas et que faire avec tout cela n'est pas clair pour démarrer les fonctions vidéo requises du service.
Contenu de l'article
Serveur et API
Afin de fermer tous ces points blancs, des solutions serveur et une architecture pair-serveur-pair sont utilisées. Web Call Server 5.2 WCS est l'une des solutions serveur - une plate-forme de développement qui vous permet d'ajouter de telles fonctions vidéo au projet et de ne pas vous soucier de STUN / TURN et de la stabilité de la connexion peer-to-peer.
Au plus haut niveau, WCS est une partie JavaScript API + serveur. L'API est utilisée pour développer en JavaScript normal du côté du navigateur, et le serveur traite le trafic vidéo, agissant comme un proxy avec état pour le trafic multimédia.
En plus de l'API JavaScript, il existe également le SDK Android et le SDK iOS, qui sont nécessaires pour développer des applications mobiles natives pour iOS et Android, respectivement.
Par exemple, publier un flux sur un serveur (diffuser un flux d'une webcam vers le serveur) ressemble à ceci:
Web sdk
session.createStream({name:”stream123”}).publish();
SDK Android
publishStream = session.createStream(streamOptions) publishStream.publish();
SDK iOS
FPWCSApi2Stream *stream = [session createStream:options error:&error]; if(![stream publish:&error]) { //published without errors }
En conséquence, vous pouvez mettre en œuvre non seulement une application Web, mais également des mises à jour complètes pour Google Play et l'App Store avec prise en charge du streaming vidéo. Ajoutez des SDK mobiles à l'image de niveau supérieur. Cela se passera comme ceci:
Flux entrants
Le serveur de streaming, qui est WCS, commence par les flux entrants. Pour donner quelque chose, vous devez l'avoir. Pour distribuer des flux vidéo aux téléspectateurs, il est nécessaire que ces flux entrent dans le serveur, passent par sa RAM et sortent par la carte réseau. Par conséquent, la première question qu'il serait utile de poser lorsque vous vous familiarisez avec un serveur multimédia est: pour quels protocoles et formats ce dernier accepte-t-il les flux. Dans le cas de WCS, ce sont les technologies suivantes: WebRTC, RTMP, RTSP, VOD, SIP / RTP.
Chacun des protocoles peut être utilisé par divers clients. Par exemple, via WebRTC, non seulement un flux provenant d'un navigateur peut entrer, mais également d'un autre serveur. Nous affichons les sources possibles de trafic entrant dans le tableau.
Si vous passez par les sources de trafic entrant, vous pouvez ajouter les éléments suivants:
WebRTC entrant
Le SDK Web vous permet de capturer non seulement la caméra et le microphone, mais également d'utiliser les capacités de l'API du navigateur pour accéder à l'écran - partage d'écran. De plus, vous pouvez capturer un élément Canvas arbitraire et tout ce qui est dessiné dessus pour une diffusion ultérieure est un streaming de toile.
Le SDK Android et le SDK iOS en raison de spécificités mobiles ont la possibilité de basculer entre la caméra avant et la caméra arrière de l'appareil à la volée. Cela vous permet de changer de source pendant la diffusion sans arrêter le flux.
Le flux WebRTC entrant peut également être obtenu à partir d'un autre serveur WCS par des méthodes: push, pull et CDN, qui seront discutées un peu plus tard.
Rtmp entrant
Le protocole RTMP est largement utilisé dans les streamers OBS préférés et dans d'autres encodeurs: Wirecast, Adobe Media Ensourcer, ffmpeg, etc. En prenant l'un de ces encodeurs, vous pouvez capturer le flux et l'envoyer au serveur.
Vous pouvez également récupérer un flux RTMP à partir d'un autre serveur de médias ou serveur WCS à partir de
en utilisant des méthodes push et pull. En cas de push, l'initiateur est le serveur distant. Dans le cas de pull, nous nous tournons vers le local pour extraire le flux du distant.
RTSP entrant
Les sources de trafic RTSP sont généralement des caméras IP ou des serveurs multimédias tiers prenant en charge le protocole RTSP. Malgré le fait que lors de l'initialisation d'une connexion RTSP, l'initiateur est le WCS, le trafic audio et vidéo en direction de la caméra IP se déplace vers le serveur WCS. Par conséquent, nous considérons que le flux de la caméra est entrant.
VOD entrante
À première vue, il peut sembler que la fonction VOD (Video On Demand) est associée exclusivement aux flux sortants et à la lecture du fichier par les navigateurs. Dans notre cas, c'est un peu faux. WCS traduit honnêtement le fichier mp4 du système de fichiers en localhost, par conséquent, un flux entrant est créé, comme s'il provenait d'une source tierce. De plus, si nous limitons un visualiseur à un fichier mp4, nous obtenons le VOD classique, où le visualiseur prend le flux et le lit depuis le tout début. S'il n'est pas limité, nous obtenons VOD LIVE - une variation de VOD, dans laquelle les téléspectateurs peuvent lire le même fichier en tant que flux, se connectant au point de lecture où tous les autres sont actuellement situés (mode de télévision diffusé préenregistré).
SIP / RTP entrants
Pour recevoir le trafic RTP entrant dans une session SIP, vous devez configurer un appel avec une passerelle SIP tierce. Si la connexion est établie avec succès, le trafic audio et / ou vidéo ira de la passerelle SIP, qui sera enveloppée dans le flux entrant du côté WCS.
Flux sortants
Après avoir reçu le flux sur le serveur, vous pouvez répliquer le flux reçu sur un ou plusieurs téléspectateurs sur demande. Le spectateur demande un flux au lecteur ou à un autre appareil. Ces flux sont appelés sortants ou «flux de téléspectateurs», car les sessions de ces flux sont toujours lancées du côté du spectateur / lecteur. L'ensemble des technologies de lecture comprend les protocoles / formats suivants: WebRTC, RTMP, RTSP, MSE, HLS
WebRTC sortant
Dans ce cas, le SDK Web, le SDK Android et le SDK iOS agissent comme l'API du lecteur. Un exemple de lecture de flux WebRTC ressemble à ceci:
Web sdk
session.createStream({name:”stream123”}).play();
SDK Android
playStream = session.createStream(streamOptions); playStream.play();
SDK iOS
FPWCSApi2Stream *stream = [session createStream:options error:nil]; if(![stream play:&error]) { //published without errors }
C'est très similaire à l'API de publication, la seule différence étant qu'à la place
stream.publish (), stream.play () est appelé pour la lecture.
Un joueur peut également être un serveur WCS tiers, qui sera chargé de récupérer un flux via WebRTC à partir d'un autre serveur en utilisant la méthode Pull ou de récupérer un flux à l'intérieur du CDN.
Rtmp sortant
Ici, il y aura principalement des lecteurs RTMP - à la fois le célèbre Flash Player et les applications de bureau et mobiles qui utilisent le protocole RTMP, reçoivent et lisent un flux RTMP. Le fait est que malgré le fait que Flash ait quitté le navigateur, il a quitté le protocole RTMP, qui est largement utilisé pour les diffusions vidéo et le manque de support natif dans les navigateurs n'empêche pas l'utilisation de ce protocole assez réussi dans d'autres applications clientes. Il est connu que RTMP est largement utilisé dans les lecteurs VR pour les applications mobiles pour Android et iOS.
RTSP sortant
Le serveur WCS peut agir comme un serveur RTSP et distribuer le flux reçu via RTSP comme une caméra IP standard. Dans ce cas, le joueur doit établir une connexion RTSP avec le serveur et récupérer le flux pour la lecture, comme s'il s'agissait d'une caméra IP.
MSE sortant
Dans ce cas, le lecteur demande un flux au serveur en utilisant le protocole Websocket. Le serveur fournit des données audio et vidéo sur des sockets Web. Les données atteignent le navigateur et sont converties en morceaux que le navigateur peut jouer grâce à l'extension native MSE prise en charge dès la sortie de la boîte. Le lecteur fonctionne finalement sur la base de l'élément vidéo HTML5.
HLS sortant
Ici, WCS agit comme un serveur HLS ou un serveur Web qui prend en charge HLS (HTTP Live Streaming). Une fois le flux entrant apparu sur le serveur, une liste de lecture HLS est générée au format .m3u8, qui est remise au lecteur en réponse à une requête HTTP. La liste de lecture décrit les segments de la vidéo que le lecteur doit télécharger et afficher. Le lecteur télécharge des segments vidéo et les lit sur la page du navigateur, sur l'appareil mobile, sur le bureau, dans le décodeur Apple TV et partout où le support HLS est revendiqué.
Boîte de réception et boîte d'envoi
Au total, nous avons 5 types de flux entrants et le même nombre de flux sortants. Nous listons
les dans le tableau:
C'est-à-dire nous pouvons conduire des flux vers le serveur et nous connecter à eux et jouer à des joueurs adaptés à cette question. Pour lire le flux WebRTC, utilisez le SDK Web. Pour lire le flux WebRTC en tant que HLS, utilisez un lecteur HLS, etc. Un flux peut être joué par de nombreux spectateurs. Les diffusions un à plusieurs fonctionnent.
Nous allons maintenant indiquer quelles actions peuvent être effectuées avec les flux.
Manipulation de flux entrant
Les flux sortants sur lesquels les spectateurs sont assis ne sont pas particulièrement manipulateurs. En effet, si le spectateur a établi une session avec le serveur et prend déjà une sorte de flux, il n'y a aucun moyen d'y apporter des modifications sans interrompre la session. Pour cette raison, toutes les manipulations et modifications ont lieu sur les flux entrants, au point où sa réplication ne s'est pas encore produite. Le flux qui a subi des modifications est ensuite diffusé à tous les téléspectateurs connectés.
Les opérations sur les flux comprennent:
- enregistrer
- suppression d'instantanés
- ajouter un flux au mélangeur
- transcodage de flux
- ajouter un filigrane
- ajouter un filtre FPS
- rotation de l'image de 90, 180, 270 degrés
Enregistrement de flux entrant
Peut-être la fonction la plus compréhensible et la plus fréquemment rencontrée. En effet, les flux nécessitent un enregistrement dans de nombreux cas: webinaire, cours d'anglais, consultation, etc.
L'enregistrement peut être lancé avec le Web SDK ou l'API REST avec une demande spéciale:
/stream/startRecording {}
Le résultat est enregistré dans le système de fichiers en tant que fichier mp4.
Suppression d'instantanés
Une tâche tout aussi courante consiste à prendre des photos du flux actuel pour afficher des icônes sur le site. Par exemple, vous avez 50 flux dans un système de vidéosurveillance, chacun ayant une source d'une caméra IP. L'affichage des 50 discussions sur une seule page est non seulement problématique pour les ressources du navigateur, mais aussi inutile. Dans le cas de 30 FPS, le FPS total de l'image changeante sera de 1500 images par seconde et l'œil humain n'acceptera tout simplement pas cette fréquence. Comme solution, vous pouvez configurer le découpage automatique ou manger des instantanés à la demande, dans ce cas, vous pouvez afficher des images sur un site avec une fréquence arbitraire, par exemple, 1 image en 10 secondes. Les instantanés peuvent être supprimés du SDK, via l'API REST, ou découpés automatiquement.
Le serveur WCS prend en charge la méthode REST suivante pour supprimer les instantanés:
/stream/snapshot
Ajout de flux au mélangeur
Une image provenant de deux sources ou plus peut être combinée en une seule pour être affichée aux téléspectateurs finaux. Cette procédure est appelée mélange. Exemples de base: 1) Surveillance vidéo de plusieurs caméras sur l'écran en une seule image. 2) Vidéoconférence, où chaque utilisateur reçoit un flux pour économiser des ressources, dans lequel le reste est mélangé. Le mélangeur est contrôlé via l'API REST et dispose d'un mode de fonctionnement MCU pour la création de visioconférence.
Commande REST pour ajouter un flux au mélangeur:
/mixer/startup
Transcodage de flux
Les flux doivent parfois être compressés afin de s'adapter à certains groupes de périphériques clients par résolution et débit binaire. Pour cela, le transcodage est utilisé. Le transcodage peut être activé du côté du SDK Web, via l'API REST ou automatiquement via un nœud de transcodage spécial dans le CDN. Par exemple, lors de la saisie d'une vidéo de 1280x720, elle peut être transcodée en 640x360 pour être distribuée aux clients d'une région géographique avec une bande passante traditionnellement faible. Où sont tes compagnons, Elon Musk?
Méthode REST utilisée:
/transcoder/startup
Ajout d'un filigrane
Il est connu que tout contenu peut être volé et transformé en WebRip, quelle que soit la protection dont le joueur dispose. Si votre contenu est vraiment si précieux, vous pouvez y incorporer un filigrane ou un logo qui compliquera considérablement son utilisation ultérieure et son affichage public. Pour ajouter un filigrane, téléchargez simplement une image PNG et elle sera insérée dans le flux vidéo par transcodage. Par conséquent, vous devrez préparer quelques cœurs de processeur côté serveur au cas où vous décideriez toujours
ajoutez un filigrane au flux. Afin de ne pas tordre le filigrane sur le serveur par transcodage, il est préférable de l'ajouter directement à l'encodeur / streamer, qui
offrent souvent une telle opportunité.
Ajout d'un filtre FPS
Dans certains cas, il est nécessaire que le flux soit avec un FPS pair (images par seconde). Cela peut être utile si nous relayons le flux vers une ressource tierce comme Youtube ou Facebook, ou si nous le jouons avec un lecteur HLS sensible. Le filtrage nécessite à nouveau un transcodage, alors calculez la puissance de votre serveur et préparez la configuration plus 2 cœurs par flux si une telle opération est prévue.
Faire pivoter l'image de 90, 180, 270 degrés
Les appareils mobiles ont la possibilité de modifier la résolution du flux publié en fonction de l'angle de rotation. Par exemple, ils ont commencé à diffuser, tenant l'iPhone horizontalement, puis se sont tournés sur le côté. Selon la spécification WebRTC, le navigateur de streamer de l'appareil mobile, et dans ce cas iOS Safari devrait signaler un virage au serveur. Le serveur, à son tour, doit envoyer cet événement à tous les abonnés. Sinon, il se serait avéré
de sorte que le streamer met le téléphone sur le côté, mais voit sa caméra toujours debout, tandis que les téléspectateurs sont empilés sur le côté. Pour travailler avec les virages du côté du SDK, l'extension cvoExtension correspondante est incluse.
Où est le contrôle des flux entrants
Automatique - la configuration est généralement définie côté serveur dans
paramètres.
Relais de flux
Le relais est également une option pour manipuler les flux qui pénètrent dans le serveur et consiste à forcer le flux vers un serveur tiers. Un synonyme de relais est des mots tels que: réplication, push, injection.
Le relais peut être implémenté en utilisant l'un des protocoles suivants: WebRTC, RTMP, SIP / RTP. Le tableau indique la direction dans laquelle le flux peut être relayé.
Relais WebRTC
Un flux peut être relayé vers un autre serveur WCS si, pour une raison quelconque, il est nécessaire de rendre le flux disponible sur un autre serveur. Le relais est effectué via l'API REST à l'aide de la méthode / push. À la réception d'une telle demande REST, WCS se connecte au serveur spécifié et y publie un flux serveur-serveur. Après cela, le flux devient disponible pour la lecture sur une autre machine.
/pull/push
- la méthode REST utilisée.
Relais RTMP
Comme pour le relais WebRTC, le relais RTMP vers un autre serveur est également possible. La différence ne concernera que le protocole de relais. Le relais RTMP est également effectué via / push et vous permet de transférer le flux vers des serveurs RTMP tiers et vers des services prenant en charge RTMP Ingest: Youtube, streaming Facebook, etc. Ainsi, le flux WebRTC peut être relayé vers RTMP. Avec le même succès dans RTMP, vous pouvez relayer n'importe quel autre flux entrant dans le serveur, par exemple, RTSP ou VOD.
Le flux vidéo est relayé vers un autre serveur RTMP à l'aide d'appels REST
/push/startup
- Appel REST utilisé.
Relais SIP / RTP
Fonction rarement utilisée. Le plus souvent en entreprise. Par exemple, lorsque vous devez configurer un appel SIP avec un serveur de conférence SIP externe et rediriger le flux audio ou vidéo vers cet appel afin que le public de la conférence voit du contenu vidéo: "Veuillez regarder cette vidéo" ou "Collègues, et maintenant regardons le flux avec IP- caméras du chantier. " Vous devez comprendre que la conférence elle-même existe et est gérée dans ce cas sur un serveur VKS externe avec prise en charge SIP (récemment, nous avons testé la solution de Polycom DMA), nous connectons et relayons simplement le flux existant à ce serveur. La fonction API REST est appelée / inject et ne sert que dans ce cas.
Commande REST API:
/call/inject_stream/startup
Connexion de serveurs à un réseau de traitement de contenu CDN
Un serveur a généralement une quantité limitée de ressources. Par conséquent, pour les diffusions en ligne de grande envergure, où le compte du public atteint des milliers et des dizaines de milliers, une mise à l'échelle est nécessaire. Plusieurs serveurs WCS peuvent être combinés en un seul réseau de distribution de contenu CDN. En interne, CDN travaillera via WebRTC pour maintenir une faible latence pendant la diffusion.
Le serveur peut être configuré dans l'un des rôles suivants: origine, périphérie, transcodeur. Serveurs de type origine - recevez le trafic et distribuez-le aux nœuds périphériques des serveurs Edge chargés de fournir le flux aux utilisateurs. S'il est nécessaire de préparer un flux dans plusieurs résolutions, les nœuds de transcodeur sont inclus dans le schéma, qui assument la mission consommatrice de ressources de transcodage des flux.
Pour résumer
WCS 5.2 est un serveur de développement d'applications avec prise en charge audio et vidéo en temps réel pour les navigateurs et les appareils mobiles. Quatre API sont fournies pour le développement: Web SDK, iOS SDK, Android SDK, REST API. Vous pouvez publier (alimenter) des flux vidéo sur le serveur à l'aide de cinq protocoles: WebRTC, RTMP, RTSP, VOD, SIP / RTP. Depuis le serveur, vous pouvez lire des flux avec des lecteurs à l'aide de cinq protocoles: WebRTC, RTMP, RTSP, MSE, HLS. Les flux peuvent être contrôlés et exécutés sur ces opérations telles que: enregistrement, découpage de clichés, mixage, transcodage, ajout d'un filigrane, filtrage FPS, diffusion de tours vidéo sur des appareils mobiles. Les flux peuvent être relayés vers d'autres serveurs via les protocoles WebRTC et RTMP, ainsi que redirigés vers des conférences SIP. Les serveurs peuvent être intégrés dans un réseau de diffusion de contenu et mis à l'échelle pour traiter un nombre arbitraire de flux vidéo.
Ce qu'Alice doit savoir pour travailler avec le serveur
Le développeur doit pouvoir utiliser Linux. Des équipes de ce type
La ligne de commande ne doit pas créer de confusion:
tar -xvzf wcs5.2.tar.gz
cd wcs5.2
./install.sh
tail -f flashphoner.log
ps aux | grep WebCallServer
top
Vanilla JavaScript doit également être en mesure de développer pour
Web
// session.createStream({name:'mystream'}).publish(); // session.createStream({name:'mystream'}).play();
La possibilité de travailler avec le backend est également utile.
WCS peut non seulement recevoir des commandes de contrôle via l'API REST, mais également envoyer des hooks - des notifications sur les événements qui s'y produisent.
Par exemple, lorsque vous essayez d'établir une connexion à partir d'un navigateur ou d'une application mobile, WCS appellera le hook / connect, et lorsqu'il essaiera de lire un flux, il appellera le hook playStream. Par conséquent, le développeur devra rester un peu dans la peau du back-end, qui est capable d'écrire à la fois un simple client REST et un petit serveur REST pour le traitement des hooks.
Exemple d'API REST
/rest-api/stream/find_all
- un exemple d'API REST listant la liste des flux sur un serveur
Exemple de crochet REST
https://myback-end.com/hook/connect
- Traitement REST hook / connect côté backend.
Linux, JavaScript, REST Client / Server sont les trois éléments qui
assez pour développer un service de production sur la plate-forme WCS qui fonctionne
avec des flux vidéo.
Le développement d'applications mobiles nécessite une connaissance de Java et d'Objective-C
pour Android et iOS respectivement.
Installation et lancement
Il existe trois façons de lancer rapidement WCS aujourd'hui:
1) Installez sur votre Centos7 ou Ubuntu 16.x LTS ou Ubuntu 18.x LTS, et
etc. guidé par un article de la documentation .
ou
2) Prenez l' image finie sur Amazon EC2 .
ou bien
3) Prenez l' image du serveur terminée sur DigitalOcean .
Et commencez un développement de projet passionnant avec des fonctionnalités de streaming vidéo.
L'article de revue s'est avéré assez volumineux. Merci pour ça.
lire la patience.
Bon streaming!
Les références
WCS 5.2 - Serveur WebRTC
Installation et lancement
Installer et exécuter WCS
Lancer une image préconstruite sur Amazon AWS
DigitalOcean
SDK
Web SDK
Android SDK
iOS SDK
WebRTC CDN
La documentation
Web Call Server 5.2