Implémentation de WebRTC dans un serveur multimédia - pratique et politique

1. Streaming vers les navigateurs en temps réel - pas de solution. Ou y en a-t-il?

Depuis environ 20 ans, la bande passante du réseau et les capacités informatiques des ordinateurs permettent la compression et la diffusion du son et de la vidéo sur le protocole IP en mode temps quasi réel. Pendant ce temps, des organisations centrales de normalisation telles que le W3C et l'IETF, ainsi que de nombreuses grandes et petites entreprises, ont développé des centaines de normes et de protocoles pour compresser, compresser, transférer, synchroniser et lire efficacement du contenu audio-vidéo sur des ordinateurs et des appareils mobiles. Une attention particulière a été accordée à la capture, à la compression et à la diffusion vidéo en temps réel sur IP, car, premièrement, l'IP est la moins chère et la plus accessible à tous les niveaux, et deuxièmement, les technologies de vidéoconférence et de vidéosurveillance sont vitales et sont très demandées.

Il semblerait que tant d'années se soient écoulées et que tant de travail ait été accompli. Quelles merveilleuses réalisations dans ce domaine pouvons-nous observer après 20 ans? Enlevons le couvercle de la boîte (bien sûr, ce n'est pas la boîte de Pandore et non la «boîte de vers») et voyons quelles merveilleuses technologies et opportunités sont devenues disponibles après de nombreuses années de travail de dizaines de milliers d'ingénieurs logiciels talentueux. Un programmeur de 1998, qui a d'abord envoyé le son sur le réseau, un médecin qui veut une solution de télémédecine simple, bon marché et fiable, un enseignant qui a besoin de donner une leçon à distance - maintenant ils ouvrent cette couverture, pleine d'espoirs brillants, et que voient-ils? Dans une casserole bouillonnante offensive pleine de marketing époustouflant, de capitalisme cynique et de tentatives désespérées d'amateurs pour améliorer les choses, toutes sortes de codecs, protocoles, formats et applications flottent.C'est ce que la soupe informatique «communautaire» offre au consommateur en temps réel. Attrapez-vous qui sent moins, essayez, testez, achetez. Il n'y a pas de solution simple et efficace. Contrairement au streaming, qui ne nécessite pas de temps réel: il existe encore depuis 5 ans une norme HLS qui fonctionne sur tous les navigateurs et appareils où le fournisseur de solution peut simplement installer le segmenteur HLS sur votre serveur et dormir paisiblement.

Voici RTSP - beaucoup de consoles et d'équipements professionnels le jouent, mais les navigateurs ne jouent pas. Voici RTMP - Safari ne veut pas le lire sur iOS et tous les Androids ne le jouent pas. Chrome l'interdit comme non fiable. Voici MPEG2-TS - les navigateurs ne le lisent pas non plus. Extensions HTML5 Media Source (MSE) - bonnes pour les segments vidéo de 5 à 10 secondes (c'est-à-dire pour HLS / Dash), mais pour les segments courts de moins d'une seconde - pas toujours stables, fonctionnent différemment dans différents navigateurs et encore non pris en charge sur iOS.

Comment, se demande-t-on, le jardin d'enfants envoie-t-il des vidéos de caméras installées en groupe aux parents qui souhaitent ouvrir le navigateur à tout moment sur n'importe quel appareil, et sans installer de plug-ins pour regarder leurs enfants en temps réel? Pourquoi tous les jardins d'enfants n'offrent pas de tels services? Oui, car fournir un tel service coûte très cher. Nous devons développer des applications pour les appareils mobiles, où la vidéo sera lue, car les navigateurs ne sont pas lus. Besoin de beaucoup plus.

Définissons le concept de «proche du temps réel». Il s'agit d'un délai inférieur à 5 secondes pour la vidéosurveillance et inférieur à 1 seconde pour la vidéoconférence. Le délai moyen du protocole HLS est de 20 à 30 secondes. Peut-être convient-il en quelque sorte aux jardins d'enfants, mais pour la vidéosurveillance de sécurité, les vidéoconférences et les webinaires, une autre technologie est nécessaire.

Ainsi, jusqu'à présent, plus précisément jusqu'à l'été 2017, il n'existait pas de norme ou de protocole unique pour diffuser de l'audio-vidéo vers un navigateur sur un appareil en temps réel. Les raisons de cette situation, nous examinerons plus loin dans cet article. Ils ne sont pas de nature technique, ces raisons. En attendant, voyons ce qui s'est passé à l'été 2017, qui à tout le moins, mais a toujours fourni une technologie qui nous permet de résoudre les problèmes ci-dessus. Cette technologie est WebRTC, beaucoup a été écrit à ce sujet sur cette ressource et sur le réseau en général. Il ne peut plus être qualifié de complètement nouveau et au moment de la rédaction de ce document, le W3C considère WebRTC 1.0 comme un projet terminé. Nous ne parlerons pas ici de ce qu'est WebRTC; si le lecteur n'est pas familier avec cette technologie, nous vous suggérons de faire une recherche sur le hub ou dans google et de vous familiariser,à quoi il sert et comment il fonctionne en termes généraux. Ici, nous disons simplement que cette technologie a été développée pour la communication peer-to-peer dans les navigateurs, avec elle, vous pouvez implémenter des applications de chat vidéo et vocales sans aucun serveur - le navigateur communique directement avec le navigateur. WebRTC est pris en charge par tous les navigateurs sur tous les appareils, et à l'été 2017, Apple est finalement descendu vers nous et l'a ajouté à son Safari sur iOS. C'est cet événement qui a fait de WebRTC la technologie la plus universelle et généralement acceptée pour la diffusion en temps réel vers les navigateurs, depuis le coucher du soleil du RTMP, qui a commencé en 2015.WebRTC est pris en charge par tous les navigateurs sur tous les appareils, et à l'été 2017, Apple est finalement descendu vers nous et l'a ajouté à son Safari sur iOS. C'est cet événement qui a fait de WebRTC la technologie la plus universelle et généralement acceptée pour la diffusion en temps réel vers les navigateurs, depuis le coucher du soleil du RTMP, qui a commencé en 2015.WebRTC est pris en charge par tous les navigateurs sur tous les appareils, et à l'été 2017, Apple est finalement descendu vers nous et l'a ajouté à son Safari sur iOS. C'est cet événement qui a fait de WebRTC la technologie la plus universelle et généralement acceptée pour la diffusion en temps réel vers les navigateurs, depuis le coucher du soleil du RTMP, qui a commencé en 2015.

Cependant, qu'est-ce que le streaming vers les navigateurs à partir des caméras a à voir avec cela? Mais le fait est que WebRTC est très flexible dans ses fonctionnalités, et vous permet d'envoyer de l'audio-vidéo à un seul des deux participants (pairs), et à n'accepter que l'autre. Par conséquent, l'idée est née d'adapter WebRTC aux serveurs multimédias. Le serveur multimédia peut recevoir des vidéos de la caméra, établir une communication avec le navigateur et accepter que seule elle sera envoyée et que le navigateur recevra. Ainsi, le serveur multimédia peut envoyer simultanément des vidéos de la caméra à de nombreux navigateurs / téléspectateurs. À l'inverse, un serveur multimédia peut recevoir un flux provenant d'un navigateur et le transmettre, par exemple, à de nombreux autres navigateurs, en mettant en œuvre la fonction «un-à-plusieurs» tant souhaitée.

Alors, finalement tout s'est formé? Akuna Matata et le jardin d'enfants pourront installer un tel serveur multimédia quelque part sur l'hébergement ou sur AWS, envoyer un flux depuis chaque caméra là-bas, et à partir de là, il sera déjà distribué aux navigateurs des parents, le tout avec un retard ne dépassant pas une seconde. En général - oui, la vie s'améliore. Mais il y a des problèmes. Et ces problèmes sont liés au fait que WebRTC est, pour ainsi dire, tiré par les cheveux pour de telles tâches; il n'a pas été conçu pour eux et ne leur convenait pas tout à fait. Des problèmes, en plus de la compatibilité des codecs, existent principalement avec l'évolutivité d'un tel serveur multimédia. Autrement dit, en même temps, 100 parents peuvent être servis à partir d'un ordinateur serveur, et 500 est déjà difficile. Bien que le réseau le permette. Et regardez la charge du processeur sur le serveur avec 100 connexions - elle est déjà proche de 90%. Comment? Après tout, envoyez simplement une vidéo audio.

Avec le même flux, s'il est envoyé via le protocole RTMP au lecteur Flash, vous pouvez facilement prendre en charge 2000 connexions simultanées à partir d'un serveur. WebRTC est-il seulement 100?
Pourquoi? Il y a deux raisons: premièrement, le protocole WebRTC est beaucoup plus coûteux en termes de calcul - là, par exemple, toutes les données sont cryptées et prennent beaucoup de temps processeur. Et la deuxième raison, dont nous discuterons plus en détail, est l'implémentation extrêmement inefficace du protocole par son créateur - Google, qui fournit le code source c ++ pour cette implémentation pour l'adaptation dans les serveurs, passerelles et autres applications qui souhaitent prendre en charge WebRTC: webrtc.org/native-code

2 API WebRTC native de Google et compatibilité avec le serveur multimédia

Rappelons que WebRTC a été créé pour transférer de l'audio-vidéo du navigateur vers le navigateur et qu'il n'y avait aucune tâche pour prendre en charge de nombreuses connexions simultanées. Par conséquent, et pas seulement par conséquent, la mise en œuvre de WebRTC dans le navigateur n'a pas complètement dérangé le principe de base de la conception et de l'architecture des systèmes techniques - élégance (rien de plus), efficacité, hautes performances. L'accent a été mis sur la fiabilité et la gérabilité avec les erreurs et les situations extrêmes dans le réseau - perte de paquets, de connexions, etc. Ce qui, bien sûr, est bon. Cependant, après un examen plus approfondi, il s'avère que c'est la seule chose qui est bonne dans l'implémentation Google de WebRTC.

Examinons les principaux points à cause desquels l'utilisation de l'implémentation Google de WebRTC pour les serveurs multimédias est extrêmement problématique.

2.a Le code est 10 fois plus qu'il ne devrait l'être et il est extrêmement inefficace,

c'est un chiffre qui a fait ses preuves. Pour commencer, vous téléchargez environ 5 gigaoctets de code, dont seulement 500 mégaoctets concernent WebRTC. Ensuite, vous essayez de vous débarrasser du code inutile. Après tout, pour les besoins d'un serveur multimédia, vous n'avez pas besoin d'encodage / décodage; le serveur ne doit recevoir que du contenu et le transmettre à tout le monde. Lorsque vous avez supprimé tous les éléments inutiles que vous pouviez (et vous pourriez en supprimer beaucoup moins que vous ne le souhaiteriez), vous disposez toujours de 100 mégaoctets de code. C'est une figure monstrueuse. C'est elle qui est 10 fois plus grosse qu'elle ne devrait l'être.

À propos, à ce stade, beaucoup diront - comment l'encodage / décodage n'est-il pas nécessaire? Qu'en est-il du transcodage d'AAC vers Opus et vice versa? Qu'en est-il du transcodage VP9-> H264? Si vous comptez effectuer un tel transcodage sur le serveur, vous ne pouvez pas non plus tirer 5 connexions simultanées. S'il est vraiment nécessaire, le transcodage doit être effectué non pas par un serveur multimédia, mais par un autre programme.

Mais revenons au problème du code gonflé et illustrons-le. Selon vous, quelle est la profondeur de la pile d'appels de fonctions lors de l'envoi d'une image vidéo déjà compressée? Un appel à Winsock (sous Windows) de la fonction send ou sendto (WSASend / WSASendTo)? Non, bien sûr, il reste du travail à faire. Dans le cas de WebRTC, vous devez emballer la trame sur le protocole RTP et la crypter, ce qui nous donne au total le protocole SRTP. Il est nécessaire de sauvegarder la trame en cas de perte de paquet afin de la renvoyer ultérieurement. Combien d'objets et de threads c ++ doivent être impliqués dans cela?

Voici comment WebRTC 61 le



fait : Comme vous pouvez le voir sur cette capture d'écran, à partir du moment où nous alimentons le cadre compressé vers WebRTC jusqu'à la file d'attente de l'objet Paced_Sender, la profondeur de la pile d'appels est de 8 (!) Et 7 objets sont impliqués!

Ensuite, un thread séparé (thread) PacedSender extrait notre trame de la file d'attente et l'envoie plus loin pour le traitement:



Et enfin, nous sommes arrivés à l'étape 4, où la trame déjà compressée et RTP repose sur la file d'attente à envoyer au réseau, qui est engagé dans un autre thread. À ce stade, la profondeur de la pile d'appels (sur le thread PacedSender) est de 7, et 3 nouveaux objets supplémentaires sont impliqués. L'envoi occupé du thread appellera le WSASend / WSASendTo final également après 3-4 appels de fonction imbriqués et impliquera 3-4 nouveaux objets.

Nous avons donc vu 3 fils, chacun faisant un excellent travail. Tous ceux qui ont programmé de tels systèmes ont une idée de la façon dont ces choses sont faites et de ce qui doit vraiment être fait. Selon nos estimations, au moins 90% des objets et du code ici sont superflus et violent les principes de la programmation orientée objet.

2.b 4-5 threads sont alloués par connexion

Sans doute, avec le nombre de threads dans cet exemple, tout est en ordre. Il est nécessaire de fournir un traitement asynchrone, de ne bloquer personne, et les 3 threads sont nécessaires. En général, un PeerConnection WebRTC alloue 4 à 5 threads. Eh bien, il serait possible de rester dans les 3. Mais pas moins. Le problème est que c'est pour chaque connexion! Dans le serveur, par exemple, vous pouvez enregistrer 3 threads, mais ils serviront toutes les connexions ensemble et n'alloueront pas 3 threads à chaque connexion. Le pool de threads est une solution serveur incontestable pour de telles tâches.

2.c Sockets asynchrones fonctionnant à travers les messages Windows

Le code Google WebRTC sous Windows utilise des sockets asynchrones via WSAAsyncSelect. Les programmeurs de serveurs savent que l'utilisation de la fonction de sélection sur le serveur est un suicide et WSAAsyncSelect, bien qu'elle améliore la situation, mais pas d'un ordre de grandeur. Si vous souhaitez prendre en charge des centaines et des milliers de connexions, il existe une meilleure solution sur Windows que les sockets asynchrones. Les sockets et les ports d'achèvement d'E / S superposés doivent être activés, envoyant des notifications au pool de threads qui effectue le travail.

2.d Conclusion

Ainsi, nous pouvons conclure: appliquer le code WebRTC de Google, sans changements majeurs, à un serveur multimédia est possible, mais le serveur ne pourra pas tirer des centaines de connexions simultanées. Il peut y avoir deux solutions:

Apporter des modifications majeures au code Google est, sans exagération, presque impossible - après tout, tous ces objets sont très étroitement liés les uns aux autres, n'encapsulent pas de fonctionnalités, ne sont pas des blocs indépendants qui effectuent certains travaux, comme il se doit. Leur implication inchangée dans d'autres scénarios est impossible.

N'utilisez pas du tout le code Google, mais implémentez tout vous-même à l'aide de bibliothèques ouvertes telles que libsrtp et similaires. C'est peut-être la bonne façon, mais outre le fait qu'il s'agit également d'un travail énorme, vous pouvez rencontrer le fait que votre mise en œuvre ne sera pas entièrement compatible avec Google et, par conséquent, ne fonctionnera pas, ou ne fonctionnera pas dans tous les cas, pour par exemple, avec du chrome, qui ne peut être toléré. Vous pouvez ensuite discuter longtemps avec les gars de Google, prouver que vous avez suivi la norme, mais ils ne l'ont pas fait, et vous aurez raison mille fois. Mais ils, au mieux, diront - "nous allons le réparer, peut-être en quelque sorte plus tard." Vous devez vous ajuster au chrome dès maintenant. Et le point.

3. Pourquoi tout est-il si triste

Cette situation avec le streaming vers les navigateurs en temps réel est une illustration très caractéristique de ce que conduit parfois la «technologie orientée métier». La technologie motivée par les affaires évolue dans le sens où elle est nécessaire aux affaires et dans la mesure où elle plaît à cette entreprise. C'est grâce à l'approche commerciale que nous avons maintenant des ordinateurs personnels et des téléphones portables - aucun gouvernement ou ministère central de la planification ne pourra jamais être aussi intéressé par le développement et l'introduction de toutes ces technologies grand public auprès des masses. L'entreprise privée, motivée par le gain personnel de ses propriétaires, l'a fait dès qu'une opportunité technique s'est présentée.

Il est connu, compris et accepté depuis longtemps que les biens et services de consommation non essentiels, ceux sans lesquels vous pouvez vivre en paix, sont mieux développés par les entreprises privées, puis les choses vitales pour une personne - énergie, routes, police et éducation scolaire - devraient être développées de manière centralisée. institutions contrôlées par l'État.

Nous, les enfants de l'Union soviétique et la mentalité «faisons de la technologie techniquement correcte et forte pour que les gens puissent l'utiliser et tout est bon», pourrait bien sûr dire que dans un système soviétique planifié (si le gouvernement décidait soudainement), la technologie de streaming La propriété intellectuelle en temps réel pourrait être développée et mise en œuvre en un an et serait un ordre de grandeur supérieur à ce que l'entreprise a maintenant gagné en 20 ans. Mais nous comprenons également qu’elle ne se développerait pas, ne deviendrait pas obsolète et, à la longue, à long terme, perdrait encore une partie de la technologie commerciale occidentale.

Par conséquent, puisqu'il est tout à fait possible de s'entendre sans calage en continu, il est à juste titre laissé à la merci des entreprises privées. Ce qui le développe dans leur propre intérêt, et non dans l'intérêt du consommateur. Comment n'est-ce pas dans l'intérêt du consommateur? Mais qu'en est-il de l'offre et de la demande? De quoi le consommateur a-t-il besoin, alors l'entreprise offrira? Mais il n'offre pas. Tous les consommateurs crient - Google, prend en charge l'audio AAC dans WebRTC, mais Google ne le fera jamais, bien qu'il crache juste pour le faire. Apple ne s'en soucie absolument pas et n'implémente rien des technologies de streaming indispensables dans ses gadgets. Pourquoi? Oui, car l'entreprise ne fait pas toujours ce dont le consommateur a besoin. Il ne le fait pas lorsqu'il est monopoliste et n'a pas peur que le consommateur perde. Ensuite, l'entreprise s'affaire à renforcer sa position. Google a donc acheté ces dernières années un tas de fabricants de codecs sonores.Et maintenant, il pousse l'audio Opus et force le monde entier à transcoder AAC-> Opus pour correspondre à WebRTC, car toute la technologie est depuis longtemps passée à l'audio AAC. Google justifie cela prétendument par le fait que l'AAC est une technologie payante, et Opus est gratuit. Mais en fait, cela est fait afin d'établir sa technologie comme norme. Comme Apple l'a fait avec son misérable HLS, ce qui nous a fait aimer, ou comme Adobe l'a fait avec son protocole RTMP irresponsable encore plus tôt. Les gadgets et les navigateurs sont encore des choses assez difficiles à développer techniquement, à partir de là surgissent des monopoles, à partir d'ici, comme on dit, les choses sont là. Et le W3C et l'IETF sont parrainés par les mêmes monopoles, donc la mentalité de «faisons une technologie techniquement correcte et solide pour que les gens puissent l'utiliser et tout va bien» n'est pas là et ne le sera jamais.Mais ça aurait dû l'être.

Comment sortir de cette situation? Apparemment, le simple fait d'attendre la «bonne» technologie axée sur les affaires, le résultat de la concurrence et toutes sortes d'autres choses merveilleuses, aboutira finalement à quelque chose de démocratique, adapté à un simple médecin rural afin qu'il puisse fournir des services de télémédecine avec son Internet normal. En effet, il est nécessaire de faire un amendement, non pas pour un simple médecin rural, mais pour ceux qui peuvent payer beaucoup d'argent, l'entreprise propose depuis longtemps des solutions de streaming en temps réel. Bon, fiable, nécessitant des réseaux dédiés et des équipements spéciaux. Dans de nombreux cas, et ne fonctionne pas sur le protocole IP. Ce qui - et c'est une autre raison d'une situation aussi triste - n'a pas été créé en temps réel et ne le garantit pas toujours. Pas toujours, mais pas dans des situations vitales, il convient tout à fait pour le moment.Essayons donc WebRTC. Jusqu'à présent, de tous les maux, il est le plus petit et le plus démocratique. Pour lequel, après tout, vous devez dire merci à Google.

4. Un peu sur les serveurs multimédias qui implémentent WebRTC

Wowza, Flashphoner, Kurento, Flussonic, Red5 Pro, Unreal Media Server - ce sont quelques-uns des serveurs multimédias qui prennent en charge WebRTC. Ils fournissent la publication de vidéos des navigateurs au serveur et diffusent des vidéos aux navigateurs via WebRTC à partir du serveur.

Les problèmes décrits dans cet article, de différentes manières et avec différents degrés de succès, sont résolus dans ces produits logiciels. Certains d'entre eux, par exemple, Kurento et Wowza, effectuent le transcodage audio-vidéo directement dans le serveur, d'autres, par exemple, Unreal Media Server, ne se transcodent pas eux-mêmes, mais fournissent d'autres programmes pour cela. Certains serveurs, tels que Wowza et Unreal Media Server, prennent en charge la diffusion en continu sur toutes les connexions via un port TCP et UDP central, car WebRTC lui-même alloue un port distinct pour chaque connexion, de sorte que le fournisseur doit ouvrir de nombreux ports dans le pare-feu, ce qui crée des problèmes de sécurité.

Il existe de nombreux points et subtilités implémentés dans tous ces serveurs de différentes manières. À quel point tout cela convient au consommateur, jugez-vous, chers utilisateurs.