WebRTC - diffusion/multidiffusion évolutive en direct
PROBLEME:
WebRTC nous fournit des connexions audio/vidéo d'égal à égal. Il est parfait pour les appels P2P, les hangouts. Mais qu'en est-il de la radiodiffusion (un-à-plusieurs, par exemple, 1 à 10000)?
Disons que nous avons un diffuseur "B" et deux participants "A1", "A2". Bien sûr, cela semble pouvoir être résolu: nous connectons simplement B avec A1 puis B avec A2. Donc, B envoie un flux vidéo/audio directement à A1 et un autre flux à A2. B envoie des flux deux fois.
Imaginons maintenant qu'il y a 10000 participants: A1, A2, ..., A10000. Cela signifie que B doit envoyer 10000 flux. Chaque flux correspond à environ 40 Ko/s, ce qui signifie que B a besoin d’une vitesse Internet sortante de 400 Mo/s pour maintenir cette diffusion. Inacceptable.
QUESTION ORIGINALE (OBSOLETE)
Est-il possible d'une manière ou d'une autre de résoudre ce problème, de sorte que B n'envoie qu'un seul flux sur un serveur et que les participants extraient simplement ce flux de ce serveur? Oui, cela signifie que la vitesse de sortie sur ce serveur doit être élevée, mais je peux la maintenir.
Ou peut-être cela signifie-t-il ruiner l'idée de WebRTC?
REMARQUES
Flash ne répond pas à mes besoins, contrairement à la mauvaise UX pour les clients finaux.
SOLUTION (PAS VRAIMENT)
26.05.2015 - Il n'existe actuellement aucune solution de ce type pour la diffusion évolutive pour WebRTC, dans laquelle vous n'utilisez pas du tout de serveurs multimédias. Il existe des solutions côté serveur et hybride (p2p + côté serveur selon différentes conditions) sur le marché.
Il existe des technologies prometteuses comme https://github.com/muaz-khan/WebRTC-Scalable-Broadcast mais elles doivent répondre aux problèmes possibles: latence, stabilité globale de la connexion réseau, formule d’évolutivité (ils ne sont pas compatibles). infinie-évolutive probablement).
SUGGESTIONS
- Réduisez les ressources CPU/bande passante en peaufinant les codecs audio et vidéo;
- Obtenez un serveur de médias.
Comme cela a été couvert en détail ici, ce que vous essayez de faire ici n’est pas possible avec WebRTC (strictement peer-to-peer) traditionnel. Comme il a été dit précédemment, les connexions WebRTC renégocient les clés de chiffrement pour chiffrer les données, pour chaque session. Ainsi, votre radiodiffuseur (B) devra en effet télécharger son flux autant de fois qu'il y aura de participants.
Cependant, il existe une solution assez simple, qui fonctionne très bien: je l’ai testée, elle s’appelle une passerelle WebRTC. Janus est un bon exemple. C'est complètement open source ( github repo here ).
Cela fonctionne comme suit: votre radiodiffuseur contacte la passerelle (Janus) qui parle WebRTC. Il y a donc une négociation de clé: B transmet de manière sécurisée (flux cryptés) à Janus.
Désormais, lorsque les participants se connectent, ils se connectent à Janus, à nouveau: négociation WebRTC, clés sécurisées, etc. À partir de maintenant, Janus émettra les flux en retour à chaque participant.
Cela fonctionne bien car le diffuseur (B) ne télécharge son flux qu’une seule fois, vers Janus. Maintenant, Janus décode les données en utilisant sa propre clé et a accès aux données brutes (qu’il contient, les paquets RTP) et peut émettre ces paquets en retour à chaque participant (Janus s’occupe du cryptage pour vous). Et puisque vous mettez Janus sur un serveur, il dispose d’une bande passante de téléchargement excellente, ce qui vous permet de diffuser en continu vers de nombreux pairs.
Donc, oui, implique un serveur, mais ce serveur parle WebRTC, et vous le «possédez»: vous implémentez la partie Janus afin que vous n'ayez pas à vous soucier de la corruption des données ou de l'homme au milieu. Bien sauf si votre serveur est compromis, bien sûr. Mais vous pouvez faire tellement de choses.
Pour vous montrer à quel point il est facile d’utiliser Janus, vous disposez d’une fonction appelée incoming_rtp() (et incoming_rtcp()) que vous pouvez appeler, qui vous donne un pointeur sur les paquets rt (c) p. Vous pouvez ensuite l'envoyer à chaque participant (ils sont stockés dans sessions que Janus rend très facile à utiliser). Regardez ici pour une implémentation de la fonction incoming_rtp() , quelques lignes ci-dessous vous pouvez voir comment transmettre les paquets à tous les participants et ici vous pouvez voir la fonction réelle permettant de relayer un fichier RP paquet.
Tout fonctionne assez bien, la documentation est assez facile à lire et à comprendre. Je vous suggère de commencer par l'exemple "echotest", il est le plus simple et vous pouvez comprendre le fonctionnement interne de Janus. Je vous suggère de modifier le fichier de test d'écho pour créer le vôtre, car il y a beaucoup de code redondant à écrire. Vous pouvez donc commencer par un fichier complet.
S'amuser! J'espère que j'ai aidé.
Comme @MuazKhan a noté ci-dessus:
https://github.com/muaz-khan/WebRTC-Scalable-Broadcast
fonctionne en chrome, et pas encore audio-broadcast, mais il semble être une 1ère solution.
Démo de diffusion WebRTC peer-to-peer évolutive.
Ce module initialise simplement socket.io et le configure d’une manière cette diffusion unique peut être relayée sur un nombre illimité d’utilisateurs sans aucun problèmes de bande passante/utilisation du processeur. Tout se passe peer-to-peer!
Cela devrait certainement être possible de compléter.
D'autres sont également capables d'y parvenir: http://www.streamroot.io/
D'après nos informations, la seule implémentation actuelle pertinente est Adobe Flash Player, qui prend en charge la multidiffusion p2p pour la diffusion vidéo poste à poste depuis la version 10.1.
La diffusion "évolutive" n'est pas possible sur Internet, car la multidiffusion IP UDP n'y est pas autorisée. Mais en théorie, c'est possible sur un réseau local.
Le problème avec Websockets est que vous n’avez pas accès à RAW UDP de par sa conception et que cela ne sera pas autorisé .
Le problème avec WebRTC est que ses canaux de données utilisent une forme de SRTP, dans laquelle chaque session possède sa propre clé encryption. Donc, à moins que quelqu'un "n'invente" ou qu'une API ne permette un moyen de partager une clé de session entre tous les clients, la multidiffusion est inutile.
Mes maîtres sont axés sur le développement d’un protocole de diffusion en direct hybride cdn/p2p utilisant WebRTC. J'ai publié mes premiers résultats sur http://bem.tv
Tout est open source et je recherche des contributeurs! :-)
Il y a la solution de la livraison assistée par les pairs, ce qui signifie que l'approche est hybride. Le serveur et les pairs aident à distribuer la ressource. C'est l'approche peer5.com et peercdn.com ont adopté.
Si nous parlons spécifiquement de la diffusion en direct, cela ressemblera à ceci:
- Le radiodiffuseur envoie la vidéo en direct à un serveur.
- Le serveur enregistre la vidéo (généralement, la convertit également dans tous les formats appropriés).
- Une métadonnée sur ce flux en direct est en cours de création, compatible avec HLS, HDS ou MPEG_DASH.
- Les utilisateurs consultent le flux en direct correspondant. Le lecteur obtient les métadonnées et sait quelles parties de la vidéo sont à suivre.
- Dans le même temps, le consommateur est connecté à d'autres consommateurs (via WebRTC)
- Ensuite, le joueur télécharge le bloc concerné directement du serveur ou de ses pairs.
Suivre un tel modèle peut économiser jusqu’à ~ 90% de la bande passante du serveur en fonction du débit du flux en direct et de la liaison montante collaborative des téléspectateurs.
disclaimer: l'auteur travaille chez Peer5
La réponse d’Angel Genchev semble correcte, mais il existe une architecture théorique permettant la diffusion à faible temps de latence via WebRTC. Imagine B (diffuseur) passe en A1 (participant 1). Ensuite, A2 (participant 2) se connecte. Au lieu de diffuser en continu de B à A2, A1 commence à diffuser en continu la vidéo reçue de B à A2. Si A1 se déconnecte, A2 commence à recevoir de B.
Cette architecture pourrait fonctionner s'il n'y a pas de latences ni de délais de connexion. Donc, théoriquement, c'est correct, mais pas dans la pratique.
En ce moment, j'utilise une solution côté serveur.
Certaines solutions disponibles sur le marché pour la solution évolutive WebRTC. Ils fournissent une diffusion Web en continu évolutive à faible temps de latence. Voici quelques exemples . Janus , Jitsi , Wowza , Red5pro , Ant Media Server
Je suis développeur pour Ant Media Server , nous fournissons également les éditions communautaire et d'entreprise, notamment les SDK Android et iOS. Faites-nous savoir si nous pouvons vous aider d'une manière ou d'une autre.
Il existe plusieurs solutions à ce problème. Il fournit à la fois une faible latence et une ultra faible latence.
Vérifiez ceci post moyen
Pour avoir une latence ultra faible évolutive, vous pouvez essayer ant media server
Je développe le système de diffusion WebRTC à l’aide du Kurento Media Server . Kurento Prend en charge plusieurs types de protocoles de streaming tels que RTSP, WebRTC, HLS. Cela fonctionne également en termes de temps réel et de mise à l'échelle.
Par conséquent, Kurento ne prend pas en charge le format RTMP utilisé dans Youtube ou Twitch. L'un des problèmes avec moi est le nombre d'utilisateurs simultanés.
J'espère que ça vous aidera.
En tant que peer1, seul l'homologue appelle getUserMedia (), c'est-à-dire que peer1 crée une pièce.
- Ainsi, peer1 capture les médias et commence la salle.
- peer2 rejoint la pièce et obtient le flux (données) de peer1 et ouvre également une connexion parallèle nommée "peer2-connection"
- Lorsque peer3 rejoint la pièce et obtient le flux (données) de peer2 et ouvre également une connexion parallèle nommée 'peer3-connection ", etc.
Ce processus est continu puisque de nombreux pairs sont connectés les uns aux autres.
Ainsi, une seule diffusion peut être transférée sur un nombre illimité d'utilisateurs sans aucun problème d'utilisation de la bande passante/du processeur.
Enfin, tout ce qui est mentionné ci-dessus est une référence de Link .
Vous décrivez l'utilisation de WebRTC avec une exigence d'un à plusieurs. WebRTC est conçu pour la diffusion en continu d'égal à égal. Cependant, certaines configurations vous permettent de tirer profit de la faible latence de WebRTC tout en diffusant des vidéos à de nombreux spectateurs.
L'astuce consiste à ne pas taxer le client de streaming avec chaque lecteur et, comme vous l'avez mentionné, à disposer d'un serveur multimédia "relais". Vous pouvez le construire vous-même, mais honnêtement, la meilleure solution consiste souvent à utiliser quelque chose comme le produit WebRTC Streaming de Wowza .
Pour diffuser efficacement à partir d'un téléphone, vous pouvez utiliser le SDK GoCoder de Wowza, mais d'après mon expérience, un SDK plus avancé tel que StreamGears fonctionne le mieux.