WebRTC - diffusion / multidiffusion en direct évolutive

PROBLÈME:

WebRTC nous offre des connexions vidéo / audio peer-to-peer. Il est parfait pour les appels p2p, les hangouts. Mais qu'en est-il de la diffusion (un à plusieurs, par exemple, 1 à 10 000)?

Disons que nous avons un diffuseur "B" et deux participants "A1", "A2". Bien sûr, cela semble être résoluble: 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 deux flux.

Imaginons maintenant qu'il y ait 10000 participants: A1, A2, ..., A10000. Cela signifie que B doit envoyer 10000 flux. Chaque flux est d'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 (OBSOLÈTE)

Est-il possible de résoudre cela d'une manière ou d'une autre, alors B n'envoie qu'un seul flux sur un serveur et les participants tirent 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 que cela signifie ruiner l'idée WebRTC?

REMARQUES

Flash ne fonctionne pas pour mes besoins en raison de la mauvaise UX des clients finaux.

SOLUTION (PAS VRAIMENT)

26.05.2015 - Il n'existe pas de solution de ce type pour la diffusion évolutive pour WebRTC pour le moment, où vous n'utilisez pas du tout de serveurs de médias. Il existe sur le marché des solutions côté serveur ainsi que des solutions hybrides (p2p + côté serveur selon les différentes conditions).

Il existe cependant des technologies prometteuses comme https://github.com/muaz-khan/WebRTC-Scalable-Broadcast mais elles doivent répondre à ces problèmes possibles: latence, stabilité globale de la connexion réseau, formule d'évolutivité (elles ne sont probablement pas évolutives à l'infini ).

SUGGESTIONS

1. Diminuez le processeur / la bande passante en ajustant les codecs audio et vidéo;
2. Obtenez un serveur multimédia.

Comme cela a été à peu près couvert ici, ce que vous essayez de faire ici n'est pas possible avec le WebRTC simple et à l'ancienne (strictement pair à pair). Car comme il a été dit précédemment, les connexions WebRTC renégocient les clés de cryptage pour crypter les données, pour chaque session. Votre diffuseur (B) devra donc en effet télécharger son flux autant de fois qu'il y a 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. Il est complètement open source ( github repo ici ).

Cela fonctionne comme suit: votre diffuseur contacte la passerelle (Janus) qui parle WebRTC . Il y a donc une négociation de clé: B transmet en toute sécurité (flux cryptés) à Janus.

Désormais, lorsque les participants se connectent, ils se connectent à nouveau à Janus: négociation WebRTC, clés sécurisées, etc. À partir de maintenant, Janus renvoie les flux à chaque participant.

Cela fonctionne bien car le diffuseur (B) ne télécharge son flux qu'une seule fois, sur Janus. Désormais, Janus décode les données en utilisant sa propre clé et a accès aux données brutes (qu'il s'agit de paquets RTP) et peut renvoyer ces paquets à chaque participant (Janus s'occupe du cryptage pour vous). Et puisque vous mettez Janus sur un serveur, il a une grande bande passante de téléchargement, vous pourrez donc diffuser vers de nombreux pairs.

Alors oui, il n'implique un serveur, mais ce serveur parle WebRTC, et vous « propre »: vous mettre en œuvre la partie Janus de sorte que vous n'avez pas à vous soucier de la corruption de données ou de l' homme au milieu. Eh bien, à moins que votre serveur ne soit compromis, bien sûr. Mais vous pouvez faire beaucoup.

Pour vous montrer à quel point il est facile à utiliser, dans Janus, vous avez une fonction appelée incoming_rtp()(et incoming_rtcp()) que vous pouvez appeler, qui vous donne un pointeur vers les paquets rt (c) p. Vous pouvez ensuite l'envoyer à chaque participant (ils sont stockés dans sessionsce Janus rend très facile à utiliser). Regardez ici pour une implémentation de la incoming_rtp()fonction , quelques lignes ci-dessous vous pouvez voir comment transmettre les paquets à tous les participants et ici vous pouvez voir la fonction réelle pour relayer un paquet rtp.

Tout fonctionne plutôt bien, la documentation est assez facile à lire et à comprendre. Je vous suggère de commencer par l'exemple "echotest", c'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 aussi bien commencer à partir d'un fichier complet.

S'amuser! J'espère que j'ai aidé.

Comme @MuazKhan l'a noté ci-dessus:

https://github.com/muaz-khan/WebRTC-Scalable-Broadcast

fonctionne en chrome, et pas encore de diffusion audio, mais cela semble être une 1ère solution.

Une démonstration de diffusion peer-to-peer WebRTC évolutive.

Ce module initialise simplement socket.io et le configure de manière à ce qu'une diffusion unique puisse être relayée sur un nombre illimité d'utilisateurs sans aucun problème d'utilisation de la bande passante / du processeur. Tout se passe de pair à pair!

Cela devrait certainement être possible à compléter.
D'autres sont également en mesure d'y parvenir: http://www.streamroot.io/

AFAIK la seule implémentation actuelle de ce qui est pertinente et mature est Adobe Flash Player, qui prend en charge la multidiffusion p2p pour la diffusion vidéo peer to peer depuis la version 10.1.

http://tomkrcha.com/?p=1526 .

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 LAN.
Le problème avec Websockets est que vous n'avez pas accès à RAW UDP par 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, où chaque session a sa propre clé de chiffrement . Donc, à moins que quelqu'un "invente" ou qu'une API ne permette de partager une clé de session entre tous les clients, la multidiffusion est inutile.

Il existe la solution de la prestation 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 adoptée par peer5.com et peercdn.com .

Si nous parlons spécifiquement de diffusion en direct, cela ressemblera à ceci:

1. Le diffuseur envoie la vidéo en direct à un serveur.
2. Le serveur enregistre la vidéo (généralement aussi la transcode dans tous les formats appropriés).
3. Une métadonnée sur ce flux en direct est en cours de création, compatible avec HLS ou HDS ou MPEG_DASH
4. Les consommateurs naviguent vers le flux en direct pertinent, le lecteur obtient les métadonnées et sait quels morceaux de la vidéo obtenir ensuite.
5. En même temps, le consommateur est connecté à d'autres consommateurs (via WebRTC)
6. Ensuite, le lecteur télécharge le morceau pertinent soit directement à partir du serveur, soit à partir de pairs.

Suivre un tel modèle peut économiser jusqu'à ~ 90% de la bande passante du serveur en fonction du débit binaire du flux en direct et de la liaison montante collaborative des téléspectateurs.

avertissement: l'auteur travaille chez Peer5

Mes maîtres se concentrent sur le développement d'un protocole hybride de diffusion en direct cdn / p2p utilisant WebRTC. J'ai publié mes premiers résultats sur http://bem.tv

Tout est open source et je recherche des contributeurs! :-)

La réponse d'Angel Genchev semble être correcte, cependant, il existe une architecture théorique, qui permet une diffusion à faible latence via WebRTC. Imaginez que B (diffuseur) diffuse vers A1 (participant 1). Puis A2 (participant 2) se connecte. Au lieu de diffuser de B à A2, A1 commence la diffusion de la vidéo reçue de B à A2. Si A1 se déconnecte, A2 commence à recevoir de B.

Cette architecture peut fonctionner s'il n'y a pas de latences et de délais de connexion. Donc, théoriquement, c'est vrai, mais pas pratiquement.

En ce moment, j'utilise une solution côté serveur.

Il existe des solutions disponibles sur le marché pour la solution évolutive WebRTC. Ils fournissent un streaming webrtc évolutif à faible latence. Voici quelques exemples. Janus , Jitsi , Wowza , Red5pro , Ant Media Server

Je suis développeur pour Ant Media Server , nous fournissons à la fois l'édition communautaire et entreprise, y compris le SDK Android et iOS. Faites-nous savoir si nous pouvons vous aider d'une manière ou d'une autre.

Vous décrivez l'utilisation de WebRTC avec une exigence un-à-plusieurs. WebRTC est conçu pour le streaming peer-to-peer, mais il existe des configurations qui vous permettront de bénéficier de la faible latence de WebRTC tout en diffusant de la vidéo à de nombreux téléspectateurs.

L'astuce est de ne pas taxer le client de streaming avec chaque spectateur et, comme vous l'avez mentionné, d'avoir un serveur multimédia "relais". Vous pouvez le créer vous-même, mais honnêtement, la meilleure solution est souvent d'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é comme StreamGears fonctionne mieux.

Je développe un système de diffusion WebRTC en utilisant le Kurento Media Server . Kurento Prend en charge plusieurs types de protocoles de streaming tels que RTSP, WebRTC, HLS. Cela fonctionne aussi bien en termes de temps réel et de mise à l'échelle.

Par conséquent, Kurento ne prend pas en charge RTMP qui est maintenant utilisé dans Youtube ou Twitch. L'un des problèmes avec moi est le nombre d'utilisateurs simultanés.

J'espère que cela aidera.

Comme peer1 n'est que le pair qui invoque getUserMedia (), c'est-à-dire que peer1 crée une salle.

1. Ainsi, peer1 capture les médias et démarre la pièce.
2. peer2 rejoint la salle et récupère le flux (données) de peer1 et ouvre également une connexion parallèle nommée "peer2-connection"
3. Lorsque peer3 rejoint la salle et récupère le flux (données) de peer2 et ouvre également une connexion parallèle nommée «peer3-connection» et ainsi de suite.

Ce processus se poursuit car de nombreux pairs se connectent les uns aux autres.

Par conséquent, une seule diffusion peut être transférée sur des utilisateurs illimités sans aucun problème d'utilisation de bande passante / CPU.

Enfin, tout ce qui précède est une référence de Link .