Alice est un développeur expérimenté de pile complète, capable d'écrire un cadre de projet SAAS sur son cadre préféré en utilisant php en une semaine. Quant au frontend, elle préfère Vue.js.
Un client vous contacte via Telegram, vous demandant de développer un site Web qui sera le lieu de rencontre pour l'employeur et l'employé pour mener une entrevue en personne. En personne signifie en face à face, un contact vidéo direct en temps réel avec vidéo et voix. "Pourquoi ne pas utiliser Skype?" Il se trouve que des projets sérieux - et chaque startup se considère sans aucun doute comme un projet sérieux - essaient d'offrir un service de communication interne pour diverses raisons, notamment:
1) Ils ne veulent pas prêter ses utilisateurs à des communicateurs tiers (Skype, Hangouts, etc.) et souhaitent les conserver dans le service.
2) Le désir de surveiller leurs communications, comme l'historique des appels et les résultats des entretiens.
3) Enregistrez les appels (naturellement, informez les deux parties de l'enregistrement).
4) Ils ne veulent pas dépendre des politiques et des mises à jour des services tiers. Tout le monde connaît cette histoire: Skype a été mis à jour, et tout part en fumée ...
Cela semble être une tâche facile. WebRTC apparaît lors de la recherche sur le sujet, et il semble que vous pouvez organiser une connexion d'égal à égal entre deux navigateurs, mais il reste des questions:
1) Où trouver les serveurs STUN / TURN?
2) Peut-on s'en passer?
3) Comment enregistrer un appel WebRTC poste à poste?
4) Que se passera-t-il si nous devons 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 seuls ne suffisent pas, et on ne sait pas quoi faire avec tout cela pour lancer les fonctions vidéo requises du service.
Contenu de l'article
Serveur et API
Pour combler ces lacunes, des solutions serveur et une architecture pair-serveur-pair sont utilisées. Web Call Server 5.2 (ci-après - WCS) est l'une des solutions serveur; c'est 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 la 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 le développement en utilisant du JavaScript normal du côté du navigateur, et le serveur traite le trafic vidéo, agissant comme un proxy dynamique 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, la publication d'un flux sur le serveur (streaming 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, nous pouvons mettre en œuvre non seulement une application Web, mais également des mises à jour à part entière pour Google Play et l'App Store avec prise en charge du streaming vidéo. Si nous ajoutons le SDK mobile à l'image de niveau supérieur, nous obtiendrons ceci:
Flux entrants
Le serveur de streaming, qui est WCS, démarre avec les flux entrants. Pour distribuer quelque chose, nous devons 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 que nous devons nous poser lorsque nous nous familiarisons avec le serveur multimédia est de savoir quels protocoles et formats ce dernier utilise pour accepter 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, non seulement le flux du navigateur peut entrer via WebRTC, mais aussi à partir d'un autre serveur. Le tableau ci-dessous répertorie les sources possibles de trafic entrant.
Si nous passons par les sources de trafic entrant, nous pouvons ajouter ce qui suit:
WebRTC entrant
Le SDK Web permet non seulement de capturer la caméra et le microphone, mais également d'utiliser les capacités de l'API du navigateur pour accéder à l'écran via le partage d'écran. De plus, nous pouvons capturer un élément Canvas arbitraire, et tout ce qui est dessiné dessus pour une diffusion ultérieure est un streaming de toile:
En raison des spécificités mobiles, le SDK Android et le SDK iOS ont la possibilité de basculer entre les caméras avant et arrière de l'appareil lors de vos déplacements. Cela nous permet de changer de source pendant la diffusion sans avoir à interrompre le flux.
Le flux WebRTC entrant peut également être obtenu à partir d'un autre serveur WCS en utilisant les méthodes push, pull et CDN, qui seront discutées plus loin.
Rtmp entrant
Le protocole RTMP est largement utilisé dans l'OBS préféré des streamers, ainsi que dans d'autres encodeurs: Wirecast, Adobe Media Encoder, ffmpeg, etc. En utilisant l'un de ces encodeurs, nous pouvons capturer le flux et l'envoyer au serveur.
Nous pouvons également récupérer un flux RTMP à partir d'un autre serveur multimédia ou serveur WCS en utilisant les 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 serveur local pour extraire le flux du serveur 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 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 entrant
À première vue, il peut sembler que la fonction VOD (Video On Demand) est exclusivement associée aux flux sortants et à la lecture des fichiers par les navigateurs. Mais dans notre cas, ce n'est pas entièrement vrai. WCS diffuse un fichier mp4 du système de fichiers vers localhost; en conséquence, 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 obtient le flux et le lit depuis le tout début. Si nous ne limitons pas une visionneuse à un seul fichier mp4, nous obtenons VOD LIVE - une variation de VOD, dans laquelle les 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 (pré- mode de diffusion télévisée enregistré).
SIP / RTP entrants
Pour recevoir le trafic RTP entrant dans une session SIP, nous devons établir 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, nous pouvons 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 flux sortants ou «flux de visionneuse», car les sessions de ces flux sont toujours lancées du côté de la visionneuse / du lecteur. L'ensemble des technologies de lecture comprend les protocoles / formats suivants: WebRTC, RTMP, RTSP, MSE et 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 }
Ceci est très similaire à l'API de publication, à la seule différence qu'au lieu de stream.publish (), stream.play () est appelé à jouer.
Un serveur WCS tiers peut être le lecteur, qui sera chargé de récupérer le flux via WebRTC à partir d'un autre serveur à l'aide de la méthode d'extraction ou de récupérer le flux dans 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. Malgré le fait que Flash ait quitté le navigateur, il a conservé 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 sur 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 distribue des données audio et vidéo via 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 sortants
Ici, WCS agit comme un serveur HLS ou un serveur Web qui prend en charge HLS (HTTP Live Streaming). Une fois que le flux entrant apparaît sur le serveur, une liste de lecture HLS .m3u8 est générée, qui est remise au lecteur en réponse à une demande HTTP. La liste de lecture décrit les segments 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é.
Entrant et sortant
Au total, nous avons 5 types de flux entrants et sortants. Ils sont répertoriés dans le tableau:
Autrement dit, nous pouvons télécharger les flux sur le serveur, nous y connecter et les lire avec des lecteurs appropriés. Pour lire un flux WebRTC, utilisez le SDK Web. Pour lire un 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.
Décrivons maintenant quelles actions peuvent être effectuées avec les flux.
Manipulation de flux entrant
Les flux sortants avec des spectateurs ne sont pas faciles à manipuler. En effet, si le visualiseur a établi une session avec le serveur et reçoit 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 distribué à tous les téléspectateurs connectés.
Les présentations de flux incluent:
- enregistrement
- prendre un instantané
- ajouter un flux au mélangeur
- transcodage de flux
- ajouter un filigrane
- ajout d'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, dans de nombreux cas, les flux doivent être enregistrés: webinaires, cours d'anglais, consultations, 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.
Prendre un instantané
Une tâche tout aussi courante consiste à prendre des photos du flux actuel pour afficher des icônes sur le site. Par exemple, nous avons 50 flux dans un système de vidéosurveillance, dont chacun a une caméra IP comme source. 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, et l'œil humain n'acceptera tout simplement pas une telle fréquence d'affichage. Comme solution, nous pouvons configurer le découpage automatique ou la prise d'instantanés à la demande; dans ce cas, des images avec une fréquence arbitraire peuvent être affichées sur le site, 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 pour recevoir des instantanés:
/stream/snapshot
Ajout d'un 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, dans lequel les autres sont mélangés, pour économiser des ressources. Le mélangeur est contrôlé via l'API REST et dispose d'un mode de fonctionnement MCU pour créer des vidéoconférences.
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, une vidéo de 1280x720 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 satellites, 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 du joueur. Si votre contenu est 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 d'ajouter un filigrane au flux. Afin de ne pas créer le filigrane sur le serveur par transcodage, il est préférable de l'ajouter directement sur l'encodeur / streamer, ce qui offre souvent une telle opportunité.
Ajout d'un filtre FPS
Dans certains cas, il est nécessaire que le flux ait un FPS pair (images par seconde). Cela peut être utile si nous retransmettons le flux vers une ressource tierce comme Youtube ou Facebook ou si nous le lisons avec un lecteur HLS sensible. Le filtrage nécessite également un transcodage, alors assurez-vous d'évaluer correctement la puissance de votre serveur et préparez 2 cœurs par flux si une telle opération est prévue.
Rotation de 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, vous avez commencé à diffuser, en tenant l'iPhone horizontalement, puis en le faisant pivoter. Selon la spécification WebRTC, le navigateur de streamer de l'appareil mobile (dans ce cas iOS Safari) devrait signaler la rotation au serveur. À son tour, le serveur doit envoyer cet événement à tous les abonnés. Sinon, ce serait comme ça - le streamer a mis le téléphone sur le côté, mais voit toujours son appareil photo verticalement, tandis que les téléspectateurs voient une image pivotée. Pour travailler avec des rotations du côté du SDK, l'extension cvoExtension correspondante est incluse.
Gestion des flux entrants
Automatique - la configuration est généralement définie côté serveur dans les paramètres.
Relais de flux
Le relais est également une option pour manipuler les flux entrant dans le serveur; il consiste à forcer le flux vers un serveur tiers. Relayer est synonyme de mots tels que republier, pousser, injecter.
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 se fait via la méthode via / push de l'API REST. À 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
- 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 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. Nous pourrions aussi bien relayer tout autre flux entrant dans le serveur, par exemple RTSP ou VOD, à RTMP.
Le flux vidéo est relayé vers un autre serveur RTMP à l'aide d'appels REST.
/push/startup
- appel REST utilisé
Relais SIP / RTP
C'est une fonction rarement utilisée. Le plus souvent, il est utilisé en entreprise. Par exemple, lorsque nous devons établir 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 une sorte de contenu vidéo: «Veuillez regarder cette vidéo» ou «Collègues , regardons maintenant un flux de caméras IP depuis le chantier ». Nous devons garder à l'esprit que dans ce cas, la conférence elle-même existe et est gérée sur un serveur VKS externe avec prise en charge SIP (récemment, nous avons testé la solution de Polycom DMA), alors que nous 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
Habituellement, un serveur a une quantité limitée de ressources. Par conséquent, pour les grandes diffusions en ligne où l'audience compte pour 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 ou transcodeur. Les serveurs de type origine reçoivent le trafic et le distribuent aux serveurs Edge, qui sont chargés de fournir le flux aux téléspectateurs. 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. Nous pouvons publier (alimenter) des flux vidéo sur le serveur en utilisant cinq protocoles: WebRTC, RTMP, RTSP, VOD, SIP / RTP. Depuis le serveur, nous pouvons lire des flux avec des joueurs en utilisant cinq protocoles: WebRTC, RTMP, RTSP, MSE, HLS. Les flux peuvent être contrôlés et subir des opérations telles que l'enregistrement, le découpage d'instantanés, le mixage, le transcodage, l'ajout d'un filigrane, le filtrage FPS et la 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 combinés en 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. Les commandes suivantes dans la ligne de commande ne doivent 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
Il faut également connaître Vanilla JavaScript en matière de développement Web.
//publishing the stream session.createStream({name:'mystream'}).publish(); //playing the stream session.createStream({name:'mystream'}).play();
La possibilité de travailler avec le back-end peut également être utile.
WCS peut non seulement recevoir des commandes de contrôle via l'API REST, mais également envoyer des hooks - c'est-à-dire 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 déclenchera le hook / connect, et lorsque vous essayez de lire un flux, il déclenchera le hook playStream. Par conséquent, le développeur devra marcher un peu dans la peau du back ender, qui est capable de créer à 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
- exemple d'API REST pour lister les flux sur le serveur
Exemple de crochet REST
https://myback-end.com/hook/connect
- Traitement REST hook / connect côté backend.
Linux, JavaScript, REST Client / Serveur - trois éléments suffisants pour développer un service de production sur la plate-forme WCS fonctionnant avec des flux vidéo.
Le développement d'applications mobiles nécessitera une connaissance de Java et Objective-C pour Android et iOS, respectivement.
Installation et lancement
Il existe trois façons de lancer rapidement WCS aujourd'hui:
1) Installez Ubuntu 16.x LTS ou Ubuntu 18.x LTS etc. sur votre Centos7. ou être guidé par un article de la documentation .
ou
2) Obtenez une image prête à l'emploi sur Amazon EC2 .
ou
3) Obtenez une image prête à l'emploi du serveur sur Digital Ocean .
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 la patience de le lire.
Bon streaming!
Les liens
WCS 5.2 - Serveur WebRTC
Installation et lancement
Installation et lancement de WCS
Lancer une image prête à l'emploi sur Amazon EC2
Lancer l'image prête à l'emploi du serveur sur DigitalOcean
SDK
SDK Web de documentation
Documentation SDK Android
Documentation iOS SDK
Étuis
Flux entrants
Flux sortants
Gestion des flux
Relais de flux
CDN pour le streaming WebRTC à faible latence
La documentation
Documentation Web Call Server 5.2