Implementando o WebRTC em um servidor de mídia - prática e política

1. Streaming para navegadores em tempo real - sem solução. Ou existe?

Há cerca de 20 anos, a largura de banda da rede e os recursos de computação dos computadores permitem a compactação e transmissão de som e vídeo pelo protocolo IP no modo quase em tempo real. Durante esse período, centenas de padrões e protocolos foram desenvolvidos por organizações centrais de padronização, como W3C e IETF, além de muitas empresas grandes e pequenas, para compactar, empacotar, encaminhar, sincronizar e reproduzir com eficiência conteúdo de áudio e vídeo em computadores e dispositivos móveis. A captura de vídeo em tempo real, a compactação e a transmissão por IP receberam atenção especial, porque, em primeiro lugar, o IP é o mais barato e mais acessível em todos os níveis e, em segundo lugar, as tecnologias de videoconferência e vigilância por vídeo são vitais e têm grande demanda.

Parece que tantos anos se passaram e muito trabalho foi feito. Que maravilhosas realizações nesta área podemos observar após 20 anos? Vamos remover a tampa da caixa (é claro, essa não é a caixa de Pandora nem a "lata de vermes") e ver quais tecnologias e recursos maravilhosos se tornaram disponíveis após muitos anos de trabalho por dezenas de milhares de engenheiros de software talentosos. Um programador de 1998, que primeiro enviou o som pela rede, um médico que deseja uma solução de telemedicina simples, barata e confiável, um professor que precisa realizar uma lição remota - agora eles abrem esta capa, cheia de esperanças brilhantes, e o que vêem? Em uma panela fervente e ofensiva, cheia de marketing alucinante, capitalismo cínico e tentativas desesperadas de entusiastas de melhorar as coisas, todos os tipos de codecs, protocolos, formatos e aplicativos estão flutuando.É isso que a sopa de TI da "comunidade" oferece ao consumidor em tempo real. Pegue-se que cheira menos, tente, teste, compre. Não existe uma solução simples e eficaz. Diferentemente do streaming, que não requer tempo real: ainda há 5 anos, existe um padrão HLS que funciona em qualquer navegador e dispositivo em que o fornecedor da solução possa simplesmente instalar o segmentador HLS no servidor e dormir tranqüilamente.

Aqui está o RTSP - muitos consoles e equipamentos profissionais o reproduzem, mas os navegadores não são reproduzidos. Aqui está o RTMP - o Safari não deseja reproduzi-lo no iOS e nem todos os Androids o reproduzem. O Chrome o proíbe como não confiável. Aqui está o MPEG2-TS - os navegadores também não o reproduzem. Extensões de fonte de mídia HTML5 (MSE) - boas para segmentos de vídeo com duração de 5 a 10 segundos (ou seja, para HLS / Dash), mas para segmentos curtos com menos de um segundo - nem sempre estáveis ​​- funcionam de maneira diferente em navegadores diferentes e novamente não suportado no iOS.

Como, pergunta-se, o jardim de infância envia vídeos de câmeras instaladas em grupos a pais que desejam abrir o navegador a qualquer momento em qualquer dispositivo e sem instalar plug-ins para assistir seus filhos em tempo real? Por que todos os jardins de infância não oferecem esses serviços? Sim, porque fornecer esse serviço é muito caro. Precisamos desenvolver aplicativos para dispositivos móveis, onde o vídeo será reproduzido - porque os navegadores não são reproduzidos. Precisa de muito mais.

Vamos definir o conceito de "próximo ao tempo real". Isso é um atraso de menos de 5 segundos para vigilância por vídeo e menos de 1 segundo para videoconferência. O atraso médio do protocolo HLS é de 20 a 30 segundos. Talvez seja adequado para jardins de infância, mas para vigilância por vídeo de segurança, videoconferência e seminários on-line, é necessária outra tecnologia.

Portanto, até agora, mais precisamente até o verão de 2017, não havia um padrão ou protocolo único para transmitir áudio e vídeo para qualquer navegador em qualquer dispositivo em tempo real. As razões para esta situação, consideraremos neste artigo posteriormente. Eles não são de natureza técnica, por esses motivos. Enquanto isso, vamos ver o que aconteceu no verão de 2017, que, no mínimo, mas ainda forneceu uma tecnologia que nos permite resolver os problemas acima. Essa tecnologia é WebRTC, muito foi escrito sobre isso tanto neste recurso quanto na rede em geral. Ele não pode mais ser chamado de completamente novo e, no momento da redação deste artigo, o W3C considera o WebRTC 1.0 um projeto concluído. Não falaremos aqui sobre o que é o WebRTC; se o leitor não estiver familiarizado com essa tecnologia, sugerimos que você faça uma pesquisa no hub ou no google e se familiarize,para que é utilizado e como funciona em termos gerais. Aqui apenas dizemos que esta tecnologia foi desenvolvida para comunicação ponto a ponto em navegadores, com ela você pode implementar aplicativos de bate-papo por vídeo e voz sem nenhum servidor - o navegador se comunica diretamente com o navegador. O WebRTC é suportado por todos os navegadores em todos os dispositivos e, no verão de 2017, a Apple finalmente chegou até nós e o adicionou ao seu Safari no iOS. Foi esse evento que tornou o WebRTC a tecnologia mais universal e geralmente aceita para streaming em tempo real para navegadores, desde o pôr do sol do RTMP, que começou em 2015.O WebRTC é suportado por todos os navegadores em todos os dispositivos e, no verão de 2017, a Apple finalmente chegou até nós e o adicionou ao seu Safari no iOS. Foi esse evento que tornou o WebRTC a tecnologia mais universal e geralmente aceita para streaming em tempo real para navegadores, desde o pôr do sol do RTMP, que começou em 2015.O WebRTC é suportado por todos os navegadores em todos os dispositivos e, no verão de 2017, a Apple finalmente chegou até nós e o adicionou ao seu Safari no iOS. Foi esse evento que tornou o WebRTC a tecnologia mais versátil e geralmente aceita para streaming em tempo real para navegadores desde o pôr do sol do RTMP, que começou em 2015.

No entanto, o que o streaming para navegadores de câmeras tem a ver com isso? Mas o fato é que o WebRTC é muito flexível em sua funcionalidade e permite enviar áudio e vídeo para apenas um dos dois participantes (pares) e aceitar apenas o outro. Portanto, nasceu a idéia de adaptar o WebRTC em servidores de mídia. O servidor de mídia pode receber vídeo da câmera, estabelecer comunicação com o navegador e concordar que somente ele será enviado e o navegador receberá. Assim, o servidor de mídia pode enviar simultaneamente o vídeo da câmera para muitos navegadores / visualizadores. Por outro lado, um servidor de mídia pode receber um fluxo de um navegador e encaminhá-lo para, por exemplo, muitos outros navegadores, realizando a tão desejada função “um para muitos”.

Então, finalmente, tudo foi formado? O Akuna Matata e o jardim de infância poderão instalar esse servidor de mídia em algum lugar da hospedagem ou na AWS, enviar um fluxo de cada câmera para lá e a partir daí já será distribuído para os navegadores dos pais, todos com um atraso de não mais de um segundo. Em geral - sim, a vida está melhorando. Mas há problemas. E esses problemas estão relacionados ao fato de o WebRTC ser exagerado para tais tarefas; não foi projetado para eles e não é adequado para eles. Os problemas, além da compatibilidade com codec, existem principalmente com a escalabilidade de um servidor de mídia. Ou seja, ao mesmo tempo, 100 pais podem ser atendidos em um computador servidor e 500 já são difíceis. Embora a rede permita. E observe a carga do processador no servidor com 100 conexões - já está perto de 90%. Como assim? Afinal, basta enviar um vídeo de som.

Com o mesmo fluxo, se enviado via protocolo RTMP ao Flash player, você poderá facilmente suportar 2000 conexões simultâneas em um servidor. O WebRTC é apenas 100?
Por quê? Há duas razões: primeiro, o protocolo WebRTC é muito mais caro em termos de computação - por exemplo, todos os dados são criptografados e consomem muito tempo do processador. E o segundo motivo, que discutiremos em mais detalhes, é a implementação extremamente ineficiente do protocolo por seu criador - o Google, que fornece o código c ++ de origem para essa implementação para adaptação em servidores, gateways e outros aplicativos que desejam oferecer suporte ao WebRTC: webrtc.org/native-code

2 API WebRTC nativa do Google e compatibilidade com servidor de mídia

Lembre-se de que o WebRTC foi criado para transferir áudio e vídeo do navegador para o navegador e não havia tarefas para oferecer suporte a muitas conexões simultâneas. Portanto, e não apenas, a implementação do WebRTC no navegador não deu a mínima para o princípio básico de design e arquitetura de sistemas técnicos - elegância (nada mais), eficiência, alto desempenho. A ênfase foi colocada na confiabilidade e capacidade de gerenciamento com erros e situações extremas na rede - perda de pacotes, conexões, etc. O que, é claro, é bom. No entanto, após uma análise mais detalhada, verifica-se que essa é a única coisa boa na implementação do WebRTC pelo Google.

Vejamos os pontos principais, pelos quais o uso da implementação do WebRTC pelo Google para servidores de mídia é extremamente problemático.

2.a O código é 10 vezes mais do que deveria e é extremamente ineficiente.Este

é um número comprovado. Para começar, você baixa cerca de 5 gigabytes de código, dos quais apenas 500 megabytes são relevantes para o WebRTC. Então você tenta se livrar do código desnecessário. Afinal, para as necessidades de um servidor de mídia, você não precisa de codificação / decodificação; o servidor deve receber apenas conteúdo e encaminhá-lo a todos. Quando você removeu todo o desnecessário que você poderia (e você pode remover muito menos do que gostaria), ainda tem 100 megabytes de código. Esta é uma figura monstruosa. É ela quem é 10 vezes maior do que deveria ser.

A propósito, neste momento, muitos dirão - como a codificação / decodificação não é necessária? E a transcodificação do AAC para o Opus e vice-versa? E a transcodificação de VP9-> H264? Se você fizer essa transcodificação no servidor, também não poderá obter 5 conexões simultâneas. Se for realmente necessário, a transcodificação deve ser feita não por um servidor de mídia, mas por outro programa.

Mas vamos voltar ao problema do código inchado e ilustrá-lo. O que você acha que é a profundidade da pilha de chamadas de função ao enviar um quadro de vídeo já compactado? Uma chamada para winsock (no Windows) da função send ou sendto (WSASend / WSASendTo)? Não, é claro, é preciso fazer mais trabalho. No caso do WebRTC, você precisa compactar o quadro no protocolo RTP e criptografá-lo, o que no total nos fornece o protocolo SRTP. É necessário salvar o quadro em caso de perda de pacotes para enviá-lo novamente mais tarde. Quantos objetos e threads c ++ devem estar envolvidos nisso?

Veja como o WebRTC 61



faz isso : Como você pode ver nesta captura de tela, desde o momento em que alimentamos o quadro compactado no WebRTC, até o momento em que o colocamos na fila de objetos Paced_Sender, a profundidade da pilha de chamadas é de 8 (!) E 7 objetos estão envolvidos!

Em seguida, um PacedSender de thread separado puxa nosso quadro da fila e o envia para processamento adicional:



e finalmente, chegamos à etapa 4, onde o quadro criptografado e já embalado pelo RTP depende da fila para ser enviada à rede, que está envolvida em outro thread. Nesse momento, a profundidade da pilha de chamadas (no encadeamento PacedSender) é 7 e mais 3 novos objetos estão envolvidos. O envio de thread ocupado chamará o WSASend / WSASendTo final também após 3-4 chamadas de função aninhadas e envolverá mais 3-4 novos objetos.

Então, vimos três threads, cada um dos quais faz um ótimo trabalho. Todo mundo que programou esses sistemas tem uma idéia de como essas coisas são feitas e o que realmente precisa ser feito. De acordo com nossas estimativas, pelo menos 90% dos objetos e códigos aqui são supérfluos e violam os princípios da programação orientada a objetos.

2.b 4-5 threads são alocados por conexão

Sem dúvida, com o número de threads neste exemplo, tudo está em ordem. É necessário fornecer processamento assíncrono, não bloquear ninguém, e todos os três threads são necessários. Em geral, um PeerConnection WebRTC aloca 4-5 threads. Bem, seria possível manter dentro de 3. Mas não menos. O problema é que isso é para todas as conexões! No servidor, por exemplo, você pode salvar 3 threads, mas eles servirão todas as conexões juntas e não alocará 3 threads para cada conexão. O conjunto de encadeamentos é uma solução de servidor inquestionável para essas tarefas.

2.c Soquetes assíncronos trabalhando nas mensagens do Windows

O código do Google WebRTC no Windows usa soquetes assíncronos através do WSAAsyncSelect. Os programadores de servidor sabem que o uso da função de seleção no servidor é suicídio e o WSAAsyncSelect, embora melhore a situação, mas não por uma ordem de magnitude. Se você deseja oferecer suporte a centenas e milhares de conexões, há uma solução melhor no Windows do que soquetes assíncronos. Soquetes sobrepostos e portas de conclusão de E / S devem estar ativadas, enviando notificações ao pool de threads que está executando o trabalho.

2.d Conclusão

Assim, podemos concluir: é possível aplicar o código WebRTC do Google, sem grandes alterações, a um servidor de mídia, mas o servidor não poderá obter centenas de conexões simultâneas. Pode haver duas soluções:

Fazer grandes alterações no código do Google é, sem exagero, quase impossível - afinal, todos esses objetos são muito bem ajustados um ao outro, não encapsulam funcionalidade, não são blocos independentes que executam certo trabalho, como deveria ser. Envolvê-los inalterados em outros cenários é impossível.

Não use o código do Google, mas implemente tudo usando bibliotecas abertas, como libsrtp e similares. Talvez este seja o caminho certo, mas, além do fato de que também é um trabalho enorme, você pode encontrar o fato de que sua implementação não será totalmente compatível com o Google e, portanto, não funcionará ou não funcionará em todos os casos, para por exemplo, com cromo, que não pode ser tolerado. Você pode discutir com os caras do Google por um longo tempo, provar que cumpriu o padrão, mas eles não cumpriram, e você estará certo mil vezes. Mas eles, na melhor das hipóteses, dirão: "nós vamos consertar, talvez de alguma forma mais tarde". Você precisa ajustar o Chrome agora. E o ponto.

3. Por que tudo é tão triste

Essa situação com a transmissão para navegadores em tempo real é uma ilustração muito característica do que a "tecnologia orientada aos negócios" às vezes leva. A tecnologia motivada pelos negócios está se desenvolvendo na direção em que é necessária para os negócios e na medida em que seja agradável a eles. É graças à abordagem comercial que agora temos computadores pessoais e telefones celulares - nenhum governo ou ministério central de planejamento poderia estar tão interessado em desenvolver e introduzir todas essas tecnologias de consumo para as massas. Os negócios privados, motivados pelo ganho pessoal de seus proprietários, fizeram isso assim que surgiu uma oportunidade técnica.

Há muito se sabe, entende e aceita que bens e serviços não essenciais, aqueles sem os quais você pode viver em paz, são melhor desenvolvidos por empresas privadas, então as coisas que são vitalmente necessárias para uma pessoa - energia, estradas, polícia e educação escolar - devem ser desenvolvidas centralmente. instituições controladas pelo estado.

Nós, os filhos da União Soviética e a mentalidade "tornemos a tecnologia tecnicamente correta e forte para que as pessoas possam usá-la e tudo esteja bem", poderíamos, é claro, dizer que em um sistema soviético planejado (se o governo decidir de repente), a tecnologia de streaming O IP em tempo real poderia ser desenvolvido e implementado em um ano e seria uma ordem de magnitude melhor do que o que a empresa já ganhou em 20 anos. Mas também entendemos que isso não se tornaria obsoleto e, no final, a longo prazo, ainda perderia alguma tecnologia comercial ocidental.

Portanto, uma vez que é possível se dar bem sem a interferência do streaming, ele é deixado à mercê dos negócios privados. Que a desenvolve em seus próprios interesses, e não nos interesses do consumidor. Como não é do interesse do consumidor? Mas e a oferta e a demanda? Do que o consumidor precisa, a empresa oferecerá? Mas isso não oferece. Todos os consumidores estão gritando: o Google suporta áudio AAC no WebRTC, mas o Google nunca o faz, embora apenas cuspa para fazê-lo. A Apple absolutamente não se importa e não implementa nada das tão necessárias tecnologias de streaming em seus gadgets. Por quê? Sim, porque nem sempre a empresa faz o que o consumidor precisa. Ele não faz isso quando é monopolista e não tem medo de perder o consumidor. Então o negócio está ocupado fortalecendo sua posição. Então, o Google comprou nos últimos anos um monte de fabricantes de codecs de som.E agora empurra o áudio do Opus e força o mundo inteiro a transcodificar o AAC-> Opus para corresponder ao WebRTC, já que toda a tecnologia mudou há muito tempo para o áudio AAC. O Google justifica isso com o fato de que o AAC é uma tecnologia paga e o Opus é gratuito. Mas, de fato, isso é feito para estabelecer sua tecnologia como padrão. Como a Apple fez uma vez com o seu miserável HLS, que fomos feitos para amar, ou como a Adobe fez com o seu irresponsável protocolo RTMP ainda mais cedo. Aparelhos e navegadores ainda são coisas tecnicamente difíceis de desenvolver, a partir daqui surgem os monopolistas, a partir daqui, como dizem, as coisas estão lá. E o W3C e a IETF são patrocinados pelos mesmos monopolistas, de modo que a mentalidade de "vamos fazer uma tecnologia tecnicamente correta e forte para que as pessoas possam usá-la e tudo esteja bem" não está lá e nunca estará.Mas deveria ter sido.

Qual é o caminho para sair dessa situação? Aparentemente, apenas aguardando a tecnologia "certa" orientada aos negócios, o resultado da competição e todo tipo de coisa maravilhosa, finalmente, surgirá algo democrático, adequado para um médico rural simples, para que ele possa fornecer serviços de telemedicina com sua Internet normal. De fato, é necessário fazer uma emenda, não para um simples médico rural, mas para aqueles que podem pagar muito dinheiro, a empresa há muito tempo oferece soluções de streaming em tempo real. Bom, confiável, exigindo redes dedicadas e equipamentos especiais. Em muitos casos, e não trabalhando no protocolo IP. O qual - e esse é outro motivo para uma situação tão triste - não foi criado em tempo real e nem sempre garante isso. Nem sempre, mas não em situações vitais, é bastante adequado no momento.Então, vamos tentar o WebRTC. Até agora, dentre todos os males, ele é o menor e mais democrático. Pelo qual, afinal, você precisa agradecer ao Google.

4. Um pouco sobre servidores de mídia que implementam o WebRTC

Wowza, Flashphoner, Kurento, Flussonic, Red5 Pro e Unreal Media Server - esses são alguns dos servidores de mídia compatíveis com o WebRTC. Eles fornecem a publicação de vídeo de navegadores para o servidor e transmitem vídeo para navegadores via WebRTC a partir do servidor.

Os problemas descritos neste artigo, de maneiras diferentes e com graus variados de sucesso, são resolvidos nesses produtos de software. Alguns deles, por exemplo, Kurento e Wowza, fazem transcodificação de áudio e vídeo diretamente no servidor, outros, por exemplo, Unreal Media Server, não se transcodificam, mas fornecem outros programas para isso. Alguns servidores, como o Wowza e o Unreal Media Server, suportam o streaming em todas as conexões através de uma porta TCP e UDP central, porque o próprio WebRTC aloca uma porta separada para cada conexão, para que o provedor precise abrir muitas portas no firewall, o que cria problemas de segurança.

Existem muitos pontos e sutilezas implementados em todos esses servidores de maneiras diferentes. Quanto isso tudo combina com o consumidor, julgue você, queridos usuários.