WebRTC - diffusion évolutive de flux en direct / multidiffusion

Question

PROBLÈME :

WebRTC nous permet d'établir des connexions vidéo/audio de pair à pair. C'est parfait pour les appels p2p, les hangouts. Mais qu'en est-il de la diffusion (one-to-many, par exemple, 1-to-10000) ?

Disons que nous avons un diffuseur "B" et deux participants "A1", "A2". Bien sûr, le problème semble pouvoir être résolu : il suffit de connecter B à A1, puis B à A2. B envoie donc un flux vidéo/audio directement à A1 et un autre flux à A2. B envoie les flux deux fois.

Imaginons maintenant qu'il y ait 10000 participants : A1, A2, ..., A10000. Cela signifie que B doit envoyer 10000 flux. Chaque flux est de ~40KB/s, ce qui signifie que B a besoin d'un débit Internet sortant de 400MB/s pour maintenir cette diffusion. Inacceptable.

QUESTION INITIALE (OBSOLÈTE)

Est-il possible de résoudre ce problème en faisant en sorte que B n'envoie qu'un seul flux sur un serveur et que les participants n'extraient que 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 la ruine de l'idée de WebRTC ?

NOTES

Flash ne répond pas à mes besoins, car l'interface utilisateur est médiocre pour les clients finaux.

SOLUTION (PAS VRAIMENT)

26.05.2015 - Pour l'instant, il n'existe pas de solution de diffusion évolutive pour WebRTC, dans laquelle vous n'utilisez pas du tout de serveurs de médias. Il existe des solutions côté serveur ainsi que des solutions hybrides (p2p + côté serveur en fonction de différentes conditions) sur le marché.

Il y a quand même quelques technologies prometteuses comme https://github.com/muaz-khan/WebRTC-Scalable-Broadcast mais ils doivent répondre à ces problèmes éventuels : latence, stabilité globale de la connexion au réseau, formule d'extensibilité (ils ne sont probablement pas extensibles à l'infini).

SUGGESTIONS

1. Réduisez l'unité centrale et la bande passante en réglant les codecs audio et vidéo ;
2. Obtenez un serveur de médias.

Answer 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 les Websockets est que vous n'avez pas accès à RAW UDP par conception et qu'il 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 cryptage clé. Donc à moins que quelqu'un "invente" ou qu'une API permette un moyen de action une seule clé de session entre tous les clients, le multicast est inutile.

Answer 2

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

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

Answer 3

Il existe 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 y peercdn.com ont pris.

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

1. Le diffuseur envoie la vidéo en direct à un serveur.
2. Le serveur enregistre la vidéo (généralement, il la transcende également dans tous les formats pertinents).
3. Une métadonnée sur ce flux en direct est en cours de création, compatible avec HLS, HDS ou MPEG_DASH.
4. Les consommateurs naviguent jusqu'au flux en direct correspondant, où le lecteur reçoit les métadonnées et sait quelles parties de la vidéo il faut lire ensuite.
5. En même temps, le consommateur est connecté à d'autres consommateurs (via WebRTC).
6. Ensuite, le joueur télécharge le morceau correspondant, soit directement depuis le serveur, soit depuis des pairs.

L'application d'un tel modèle permet d'é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

Answer 4

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

Cette architecture pourrait fonctionner s'il n'y a pas de latences et de délais de connexion. En théorie, elle est donc correcte, mais pas en pratique.

Pour l'instant, j'utilise une solution côté serveur.

Answer 5

C'est un problème vraiment difficile à résoudre. Je pense que les meilleurs résultats peuvent être obtenus avec une approche hybride, où vous avez des nœuds de type serveur et des clients.

Les nœuds de type serveur-a fonctionneront en tant que pairs "puissants" et pour les cas où le p2p n'est pas une option (traversée NAT du pare-feu).

En outre, vous pouvez utiliser certains des destinataires pour transmettre les données à d'autres pairs dans l'arbre de distribution.

Nous ( http://www.addlive.com ) prévoient de travailler à l'ajout d'une telle fonctionnalité à notre plateforme.