WebRTC - diffusion / multidiffusion en direct évolutive


114

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.

3
"La seule façon de créer une application évolutive est d'utiliser une solution côté serveur." Cela semble assez clair ... Quant au WebRTC, il n'a jamais été destiné à des diffusions à grande échelle. Utilisez quelque chose qui prend en charge la multidiffusion pour cela, ou si vous devez passer par Internet, une connexion un à un basée sur un serveur, car les FAI n'acheminent pas la multidiffusion.
Dark Falcon

1
Pourquoi ne pas utiliser WebRTC du client au serveur? Le problème est dans la distribution, dans la mesure où la connexion du client ne peut pas le gérer, alors envoyez un flux au serveur et diffusez-le aux clients à partir de là. La bande passante va coûter cher, mais vous ne pouvez pas vous déplacer en envoyant un seul flux à chaque utilisateur ou en demandant à l'utilisateur d'envoyer un flux à d'autres utilisateurs.
Dark Falcon

1
À ma connaissance, il y a au moins deux entreprises qui essaient de fournir des vidéos p2p basées sur webrtc : affovi.com/rtcplayer.html - principalement pour la vidéo en direct; et peer5.com - principalement pour la VOD.
Svetlin Mladenov

1
@igorpavlov Vous voudrez peut-être vérifier: github.com/muaz-khan/WebRTC-Scalable-Broadcast Bien que cela ne fonctionne que dans Chrome, et pas encore de diffusion audio.
Muaz Khan

4
Il n'y a aucun moyen d'atteindre cette évolutivité sans une sorte de MCU. WebRTC est conçu pour être Peer-to-Peer. Vous ne pouvez pas diffuser à partir de celui-ci sans claquer absolument votre diffuseur (avec une connexion de pair unique pour chaque flux, dont les stagiaires, est un autre flux en cours d'encodage). En ce qui concerne le relais du média d'égal à égal, cela pourrait être possible, mais bien sûr, cela entraînerait une latence supplémentaire pour chaque pair ajouté au flux plus tard. Pour la qualité et l'évolutivité, disposer d'un serveur MCU webrtc est la seule solution réaliste.
Benjamin Trent

Réponses:


66

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é.


1
Est-il vrai de dire que cela ne fonctionne pas dans Safari actuellement (ou dans tout navigateur qui ne prend pas en charge WebRTC?). Est-ce que quelqu'un connaît une solution hybride où vous diffusez du navigateur au serveur en utilisant WebRTC puis transcodez la vidéo en HLS / HDS (ou même RTMP) pour s'intégrer dans un système de diffusion traditionnel?
Ben

1
@Ben oui, cela ne fonctionne pas avec les navigateurs qui ne prennent pas en charge WebRTC. À l'époque (quand j'écris ceci), Safari ne le soutenait clairement pas. Aujourd'hui, cependant, je n'ai pas vérifié. Mais je pense toujours qu'ils ne prennent pas en charge WebRTC (à confirmer, cependant). Quant à l'utiliser dans un système hybride, c'est tout à fait possible, en fait c'est ce que j'ai fait pour l'entreprise dans laquelle j'ai travaillé; comme vous l'avez dit, j'ai diffusé du navigateur au serveur et à partir de là, j'ai construit et branché un pipeline GStreamer pour transcoder le flux. Vous pouvez le faire aussi!
nschoe

une idée sur jitsi? est-ce que jitisi est aussi le même?
ishandutta2007

@nschoe Est-ce mieux que d'utiliser websocket pour faire de même?
Navigateur

Vous expliquez en fait le fonctionnement d'une SFU (Selective Forwarding Unit). Vous pouvez faire de même avec mediasoup
Dirk V

11

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!

entrez la description de l'image ici

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


1
Ce truc me semble un peu dépassé. Des mises à jour ou des réflexions sur cette idée?
igorpavlov

Aussi, résout-il de toute façon les problèmes de latence? Par exemple, Peer1 parle à Peer5 et Peer2 perd finalement la connexion. Ou cette architecture est-elle valable uniquement pour le LAN?
igorpavlov

De plus, Streamroot est-il similaire à Peer5?
igorpavlov

7

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 .


1
Les gens ne tuent pas la technologie. La technologie se tue en fournissant une UX très médiocre, en particulier lors de l'utilisation d'un micro / caméra. C'est là que getusermedia gagne.
igorpavlov

Je ne pourrais pas être plus d'accord.
Tom

Hormis le mauvais ux, serait-ce la solution? Serveur moins?
rubo77

6

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.


1
mais les chats fonctionnent déjà avec WebRTC, donc tout le monde voit chaque message, donc un à plusieurs devrait également fonctionner pour la vidéo
rubo77

@ rubo77 Les données envoyées par SMS ne sont rien du tout comparées au débit et à la quantité de données envoyées avec les flux vidéo. Ainsi, les chats peuvent facilement contenir plus d'utilisateurs à la fois
Dirk V

5

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


Je vous remercie. Je connais peer5 et je trouve que c'est une solution assez intéressante. Cependant, le but de cette question était de trouver une solution absolument sans serveur (seul STUN / TURN autorisé).
igorpavlov

5

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! :-)


Utilisez-vous un type de logiciel côté serveur, un peu MCU?
igorpavlov

J'utilise actuellement des composants côté serveur de rtcio people: github.com/rtc-io
flavioribeiro

1
Il semble que vous utilisiez leurs composants pour la signalisation. Qu'en est-il du streaming vidéo côté serveur? Ou votre solution est-elle absolument P2P?
igorpavlov

désolé pour le long délai pour vous répondre @igorpavlov, j'utilise EvoStream pour segmenter les vidéos et je boucle une source vidéo et pointe vers EvoStream à l'aide de l'encodeur élémentaire.
flavioribeiro

C'est un fournisseur de serveurs multimédias. Plus efficace? Probablement. Est-ce ce que je recherche? No.
igorpavlov

2

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.


Qu'en est-il de la vitesse du flux dans la solution côté serveur? Partagez s'il vous plait.
user2003356

Solution côté serveur signifie? Qu'avez-vous utilisé? Ce serait utile pour mes recherches. Partagez s'il vous plait. Merci.
user2003356

La solution côté serveur signifie Opentok by Tokbox. Je ne les annonce pas, il existe des tonnes de solutions de ce type sur le marché, mais je m'en tiens à celle-ci. Il fonctionne comme un serveur multimédia. PS Qu'entendez-vous par communication multipartite? Je ne comprends pas.
igorpavlov

@igorpavlov pourriez-vous donner la liste des entreprises qui fournissent webrtc côté serveur? Je ne connais que Flashphoner et Opentok. Merci
Ramil Amerzyanov

Je serais curieux de voir si cela pourrait réellement augmenter. Il y aura sûrement des problèmes de mise à l'échelle avec la latence sur les groupes ÉNORMES (1000+) mais s'il n'y en a que 5 à 10, j'imagine que cela fonctionnerait très bien, mais un travail de fantaisie serait nécessaire si quelqu'un au milieu de la chaîne des pairs " "part et reconnecter tous les pairs suivants si ce n'est qu'une seule chaîne serait un ÉNORME sur la tête. Il peut être préférable d'utiliser une structure arborescente binaire / ternaire.
Benjamin Trent

2

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.


1

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.


1

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.


0

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 .


1
Cette approche a déjà été mentionnée, mais elle peut ne pas fonctionner dans le monde réel. En tant que Peer3, pourquoi devrais-je me soucier des performances de bande passante du Peer2? Bien sûr, Peer3 peut se replier sur Peer1 si Peer2 quitte la chaîne, mais cela provoquera des tonnes d'interruptions de flux, de reconnexions, etc. Plus je suis dans la chaîne, plus je souffrirai. Donc, oui, peut fonctionner sur LAN, mais c'est probablement tout.
igorpavlov

La diffusion parallèle ne prend pas en charge la bande passante et si une fois la connexion établie de peer3 à peer1 via peer2 et telle que peer2 fallback alors, peer3 reste connecté à peer1.
susan097

Je ne suis pas sûr de comprendre. Je ne faisais pas vraiment référence au lien, permettez-moi maintenant de vous référer. Ce lien github.com/muaz-khan/WebRTC-Scalable-Broadcast a une image dans la section "Comment ça marche?" section. Cette image vous indique clairement qu'une fois, disons Peer5 se déconnecte, Peer8,9 et 10 sont déconnectés de la diffusion. Ils devront se connecter à Peer2 ou Peer6, mais cela entraînera des retards. Aussi, ce projet n'a ni contributeurs, ni activité.
igorpavlov
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.