WebRTC - transmissão / multicast escalável ao vivo

PROBLEMA:

WebRTC nos dá conexões de vídeo / áudio ponto a ponto. É perfeito para chamadas p2p, hangouts. Mas e quanto à transmissão (um para muitos, por exemplo, 1 para 10000)?

Digamos que temos uma emissora "B" e dois participantes "A1", "A2". Claro que parece resolvível: apenas conectamos B com A1 e B com A2. Portanto, B envia fluxo de vídeo / áudio diretamente para A1 e outro fluxo para A2. B envia streams duas vezes.

Agora vamos imaginar que haja 10.000 participantes: A1, A2, ..., A10000. Isso significa que B deve enviar 10.000 fluxos. Cada transmissão é de aproximadamente 40 KB / s, o que significa que B precisa de 400 MB / s de velocidade de saída da Internet para manter essa transmissão. Inaceitável.

PERGUNTA ORIGINAL (OBSOLETA)

É possível resolver isso de alguma forma, de modo que B envie apenas um fluxo em algum servidor e os participantes apenas puxem esse fluxo deste servidor? Sim, isso significa que a velocidade de saída neste servidor deve ser alta, mas posso mantê-la.

Ou talvez isso signifique arruinar a ideia do WebRTC?

NOTAS

Flash não está funcionando para minhas necessidades de acordo com UX ruim para clientes finais.

SOLUÇÃO (NÃO REALMENTE)

26.05.2015 - Não existe uma solução para transmissão escalonável para WebRTC no momento, onde você não usa servidores de mídia. Existem soluções do lado do servidor e também híbridas (p2p + lado do servidor dependendo das diferentes condições) no mercado.

Existem alguns técnicos promissores, como https://github.com/muaz-khan/WebRTC-Scalable-Broadcast, mas eles precisam responder a esses possíveis problemas: latência, estabilidade geral da conexão de rede, fórmula de escalabilidade (provavelmente não são infinitos escaláveis )

SUGESTÕES

1. Diminua a CPU / largura de banda ajustando os codecs de áudio e vídeo;
2. Obtenha um servidor de mídia.

Como já foi abordado aqui, o que você está tentando fazer aqui não é possível com o WebRTC simples e antigo (estritamente ponto a ponto). Porque, como foi dito antes, as conexões WebRTC renegociam chaves de criptografia para criptografar dados, para cada sessão. Portanto, sua emissora (B) realmente precisará enviar seu stream tantas vezes quanto houver participantes.

Porém, existe uma solução bastante simples, que funciona muito bem: eu testei, chama-se gateway WebRTC. Janus é um bom exemplo. É totalmente open source ( github repo aqui ).

Isso funciona da seguinte maneira: sua emissora contata o gateway (Janus) que fala WebRTC . Portanto, há uma negociação de chave: B transmite com segurança (fluxos criptografados) para Janus.

Agora, quando os participantes se conectam, eles se conectam ao Janus, novamente: negociação WebRTC, chaves seguras, etc. De agora em diante, o Janus irá emitir de volta os streams para cada participante.

Isso funciona bem porque a emissora (B) só carrega seu stream uma vez, para Janus. Agora Janus decodifica os dados usando sua própria chave e tem acesso aos dados brutos (isto é, pacotes RTP) e pode emitir de volta esses pacotes para cada participante (Janus cuida da criptografia para você). E já que você colocou o Janus em um servidor, ele tem uma grande largura de banda de upload, então você será capaz de transmitir para muitos pares.

Então, sim, ele faz envolver um servidor, mas esse servidor fala WebRTC, e você "próprio": você implementar a parte Janus, assim você não precisa se preocupar com a corrupção de dados ou homem no meio. Bem, a menos que seu servidor esteja comprometido, é claro. Mas há muito que você pode fazer.

Para mostrar como é fácil de usar, no Janus, você tem uma função chamada incoming_rtp()(e incoming_rtcp()) que você pode chamar, que fornece um ponteiro para os pacotes rt (c) p. Você pode então enviá-los a cada participante (eles são armazenados em uma sessionspasta que o Janus torna muito fácil de usar). Procure aqui uma implementação da incoming_rtp()função , algumas linhas abaixo você pode ver como transmitir os pacotes para todos os participantes e aqui você pode ver a função real para retransmitir um pacote rtp.

Tudo funciona muito bem, a documentação é bastante fácil de ler e entender. Eu sugiro que você comece com o exemplo "mais quente", é o mais simples e você pode entender o funcionamento interno de Janus. Eu sugiro que você edite o arquivo de teste de eco para fazer o seu próprio, porque há muito código redundante para escrever, então você pode começar a partir de um arquivo completo.

Diverta-se! Espero ter ajudado.

Como @MuazKhan notado acima:

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

funciona em cromo, e ainda sem transmissão de áudio, mas parece ser uma 1ª Solução.

Uma demonstração de transmissão ponto a ponto WebRTC escalonável.

Este módulo simplesmente inicializa socket.io e o configura de forma que uma única transmissão possa ser retransmitida por usuários ilimitados sem quaisquer problemas de largura de banda / uso de CPU. Tudo acontece ponto a ponto!

Definitivamente, isso deve ser possível concluir.
Outros também podem fazer isso: http://www.streamroot.io/

AFAIK, a única implementação atual que é relevante e madura é o Adobe Flash Player, que oferece suporte a multicast p2p para transmissão de vídeo ponto a ponto desde a versão 10.1.

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

A difusão "escalonável" não é possível na Internet, porque o multicast IP UDP não é permitido lá. Mas, em teoria, é possível em uma LAN.
O problema com Websockets é que você não tem acesso ao RAW UDP por design e isso não será permitido.
O problema com o WebRTC é que seus canais de dados usam uma forma de SRTP, onde cada sessão tem sua própria chave de criptografia . Portanto, a menos que alguém "invente" ou uma API permita uma maneira de compartilhar uma chave de sessão entre todos os clientes, o multicast é inútil.

Existe a solução de entrega assistida por pares, ou seja, a abordagem é híbrida. O servidor e os pares ajudam a distribuir o recurso. Essa é a abordagem que peer5.com e peercdn.com adotaram .

Se estivermos falando especificamente sobre transmissão ao vivo, será algo parecido com isto:

1. O Broadcaster envia o vídeo ao vivo para um servidor.
2. O servidor salva o vídeo (geralmente também o transcodifica para todos os formatos relevantes).
3. Um metadado sobre esta transmissão ao vivo está sendo criado, compatível com HLS ou HDS ou MPEG_DASH
4. Os consumidores navegam até a transmissão ao vivo relevante, onde o jogador obtém os metadados e sabe quais partes do vídeo obter a seguir.
5. Ao mesmo tempo, o consumidor está sendo conectado a outros consumidores (via WebRTC)
6. Em seguida, o jogador baixa o bloco relevante diretamente do servidor ou de pares.

Seguir esse modelo pode economizar até ~ 90% da largura de banda do servidor, dependendo da taxa de bits da transmissão ao vivo e do uplink colaborativo dos telespectadores.

isenção de responsabilidade: o autor está trabalhando na Peer5

Meu mestrado está focado no desenvolvimento de um protocolo híbrido de transmissão ao vivo cdn / p2p usando WebRTC. Publiquei meus primeiros resultados em http://bem.tv

Tudo é open source e estou procurando colaboradores! :-)

A resposta de Angel Genchev parece correta, porém, existe uma arquitetura teórica, que permite a transmissão em baixa latência via WebRTC. Imagine B (emissora) transmite para A1 (participante 1). Então A2 (participante 2) se conecta. Em vez de transmitir de B para A2, A1 começa a transmitir o vídeo recebido de B para A2. Se A1 se desconectar, A2 começará a receber de B.

Essa arquitetura pode funcionar se não houver latências e tempos limite de conexão. Então, teoricamente, está certo, mas não na prática.

No momento, estou usando uma solução do lado do servidor.

Existem algumas soluções disponíveis no mercado para solução escalável WebRTC. Eles fornecem streaming webrtc escalonável de baixa latência. Aqui estão alguns exemplos. Janus , Jitsi , Wowza , Red5pro , Ant Media Server

Eu sou desenvolvedor para Ant Media Server , nós fornecemos tanto a edição comunitária quanto a enterprise incluindo Android e iOS SDK também. Deixe-nos saber se podemos ajudá-lo de alguma forma.

Você está descrevendo o uso de WebRTC com um requisito de um para muitos. O WebRTC foi projetado para streaming ponto a ponto; no entanto, existem configurações que permitem que você se beneficie da baixa latência do WebRTC ao entregar vídeo para muitos visualizadores.

O truque é não sobrecarregar o cliente de streaming com cada visualizador e, como você mencionou, ter um servidor de mídia "relay". Você pode construir isso sozinho, mas, honestamente, a melhor solução geralmente é usar algo como o produto WebRTC Streaming da Wowza .

Para transmitir com eficiência de um telefone, você pode usar o GoCoder SDK de Wowza, mas, em minha experiência, um SDK mais avançado como o StreamGears funciona melhor.

Estou desenvolvendo um sistema de transmissão WebRTC usando o Kurento Media Server . Kurento Suporta vários tipos de protocolo de streaming, como RTSP, WebRTC, HLS. Ele funciona bem em termos de tempo real e escala.

Conseqüentemente, o Kurento não suporta RTMP, que é usado no Youtube ou Twitch agora. Um dos problemas comigo é o número de usuários simultâneos a isso.

Espero que ajude.

Como peer1 é apenas o peer que invoca getUserMedia (), ou seja, peer1 cria uma sala.

1. Portanto, o par1 captura a mídia e inicia a sala.
2. peer2 entra na sala e obtém stream (dados) de peer1 e também abre a conexão paralela chamada "peer2-connection"
3. Quando o peer3 entra na sala e obtém o fluxo (dados) do peer2 e também abre a conexão paralela denominada 'peer3-connection "e assim por diante.

Este processo é contínuo à medida que muitos pares se conectam uns aos outros.

Conseqüentemente, com isso, uma única transmissão pode ser transferida para usuários ilimitados sem quaisquer problemas de largura de banda / uso de CPU.

Finalmente, todo o conteúdo acima é referência do Link .