Desde os primeiros dias de trabalho no sistema de vigilância em nuvem, enfrentamos um desafio que, sem solução, poderia colocar um ponto final no Ivideon – foi nossa Everest, cuja escalada demandou um enorme esforço, mas agora, finalmente, cravamos o piolet no topo desse enigma multiplataforma.
O sistema de transmissão de som e vídeo pela Internet não deve depender de equipamentos, clientes web e dos padrões suportados por eles, além de funcionar corretamente na presença de Tradutores de Endereços de Rede e firewalls. O usuário de vigilância em nuvem deseja ter acesso ao serviço, mesmo que utilize câmeras analógicas, e prefira assistir à transmissão de vídeo ao vivo em um dispositivo moderno.
É bastante relevante que o usuário queira assistir ao vídeo com o mínimo de atraso possível. Quase a única maneira de exibir vídeo com baixo atraso no navegador é usar o WebRTC (comunicações em tempo real pela web). O WebRTC é um conjunto de tecnologias para transmissão de vídeo e som peer-to-peer nos navegadores, originalmente projetado para transmissão e reprodução de fluxo de vídeo com baixa latência. Para isso, entre outras coisas, é utilizado o protocolo UDP.
Antes de contar a vocês o que o novo motor oferece ao usuário, vamos relembrar por que e para que suportamos as tecnologias HLS e por que decidimos seguir em frente.
Motor HLS: prós e contras
()
A tecnologia HLS (HTTP Live Streaming) foi desenvolvida pela Apple, portanto, não é surpreendente que o suporte tenha aparecido primeiro em dispositivos dessa marca. Atualmente, a transmissão de vídeo no formato HLS também é suportada por praticamente todos os decodificadores de TV e muitos dispositivos que operam no sistema Android.
O motor HLS utiliza o bem conhecido codec de vídeo H264 combinado com fluxos de áudio AAC ou MP3. Todo o fluxo de dados de áudio e vídeo é embalado em um contêiner de transporte MPEG-TS. Para transmissão pelo protocolo HTTP, as informações contidas no fluxo são divididas em fragmentos, descritos nas listas de reprodução m3u8. Somente então esses fragmentos, juntamente com as listas de reprodução, são transmitidos via HTTP. A divisão em fragmentos implica automaticamente um atraso em segundos, característica desse contêiner MPEG-TS.
O motor HLS também suporta fluxos de múltiplas taxas de bits, Live/VOD.
As principais vantagens do HLS:
- suporte integrado em todos os principais navegadores;
- facilidade de implementação (comparado com WebRTC);
- é muito conveniente e eficiente organizar diversas transmissões para um grande público, pois é possível carregar segmentos uma única vez no CDN.
Apesar da simplicidade do motor, as coisas não são tão suaves quanto parecem. O principal problema é que os desenvolvedores de players de terceiros se afastaram das recomendações da Apple, especialmente em relação aos formatos de áudio suportados. Em particular, muitos desenvolvedores começaram a adicionar a capacidade de trabalhar com fluxos de áudio populares: vídeo mpeg2, áudio mpeg2, etc. Como resultado, foi necessário criar diferentes formatos de playlist para players diferentes.
No entanto, um dos maiores problemas do motor HLS é a alta latência na transmissão de dados.
As raízes dos "atrasos"
A principal razão para a alta latência do HLS reside no fato de que os programadores criaram o motor para obter a melhor qualidade de imagem possível. Portanto, os parâmetros do intervalo de quadros utilizados e o tamanho do buffer de reprodução não são adequados para transmissões ao vivo. Isso resulta em uma latência considerável na transmissão do vídeo, que pode chegar a 5-7 segundos.
Por um lado, isso é um intervalo pequeno, por exemplo, para aqueles que assistem a um filme em um servidor de hospedagem de vídeo. Mas para sistemas de monitoramento, a latência na transmissão do vídeo pode ser muito significativa.
Se você está monitorando um escritório onde os funcionários se afastam dos monitores a cada hora, então uma latência de 5 segundos não faz nenhuma diferença. Mas as pessoas começaram a reclamar que, por exemplo, durante a transmissão de um jogo de futebol, no chat já haviam escrito GOOOOOL, mas no vídeo isso ainda não apareceu :). Já temos vários casos de usuários em que o Ivideon deve praticamente substituir o Skype.
É possível vencer a latência no HLS? A resposta a essa pergunta soa como um discurso de um exterminador de ratos experiente em uma palestra para iniciantes: "É impossível exterminar os ratos, mas é possível reduzir a população a um mínimo razoável". Assim acontece com a latência no HLS; não conseguiremos eliminá-la totalmente, mas existem soluções no mercado que permitem reduzir significativamente a latência.
Segmentação fina
Outro ponto negativo do motor é o uso de arquivos pequenos para a transmissão de dados. À primeira vista, o que há de errado nisso?
Qualquer pessoa que já tentou copiar uma grande quantidade de pequenos arquivos de um dispositivo para outro certamente notou que a velocidade de gravação desse conjunto é muito menor do que a de um único grande arquivo do mesmo tamanho. E a intensidade de acesso ao disco rígido aumenta significativamente, o que, em geral, afeta negativamente o desempenho de todo o computador. Portanto, a transmissão de dados de vídeo em pequenos fragmentos de 10 segundos também contribui para aumentar a latência do mecanismo.
Vamos resumir brevemente todos os prós e contras da tecnologia HLS.
Vantagens do HLS:
- Capacidade de trabalhar com qualquer dispositivo. Você pode assistir a vídeos em qualquer dispositivo moderno, seja um smartphone, tablet, laptop ou desktop. O principal é que o navegador da web seja de versão moderna e compatível com HTML5 e Media Source Extensions.
- Excelente qualidade de imagem. A função de transmissão adaptativa utilizada permite alterar dinamicamente a qualidade do vídeo transmitido de acordo com a largura de banda da conexão com a Internet, enquanto o algoritmo busca manter a qualidade máxima.
- Não há necessidade de configurações complexas no equipamento do usuário.
Desvantagens:
- Suporte limitado ao funcionamento do mecanismo em alguns dispositivos.
- Altas latências na transmissão de imagem.
- Aumento significativo de overhead e dificuldade de otimização devido ao uso de arquivos de pequeno tamanho. Devido às características do contêiner, nunca conseguiremos obter uma latência menor do que o tamanho do segmento.
As desvantagens do HLS superaram suas vantagens para nós e nos fizeram buscar alternativas.
O que é WebRTC
()
A plataforma WebRTC foi desenvolvida pelo Google em 2011 para a transmissão de dados de vídeo e áudio em tempo real entre navegadores e aplicativos móveis com latência mínima. Para isso, usa-se o protocolo padrão UDP e algoritmos especiais de controle de fluxo. Hoje, é um projeto de código aberto, que é ativamente apoiado e desenvolvido pelo Google.
WebRTC é um conjunto de tecnologias para transmissão de vídeo e áudio ponto a ponto. Ou seja, por exemplo, os navegadores dos usuários podem transmitir dados diretamente entre si, sem o uso de servidores remotos para armazenar e processar dados. Todas as informações também são processadas pelos navegadores e aplicativos móveis dos usuários finais.
A conveniência e as grandes possibilidades dessa tecnologia foram muito bem avaliadas pelos desenvolvedores de todos os navegadores populares. Hoje, o suporte ao WebRTC é implementado no Mozilla Firefox, Opera, Google Chrome (e em todos os navegadores baseados em Chromium), bem como em aplicativos móveis para Android e iOS.
Apesar de suas inegáveis qualidades, o WebRTC tem algumas desvantagens significativas.
Dificuldades na escolha
A tecnologia WebRTC é muito mais complexa em termos de interações de rede devido ao fato de ser baseada em P2P. É difícil depurar, testar e pode se comportar de maneira imprevisível. Além disso, precisamos superar NAT e firewalls, garantindo o funcionamento em redes onde o UDP está bloqueado.
A implementação do WebRTC do Google é bastante complicada de usar. Há até uma empresa inteira que oferece serviços de montagem de SDK. Além disso, integrar a implementação do Google ao nosso sistema foi bastante desafiador, já que precisávamos evitar a recodificação de todo o vídeo.
No entanto, há muito desejávamos oferecer aos usuários a capacidade de trabalhar com um real 'fluxo' de vídeo e minimizar o atraso da imagem na tela em relação aos eventos reais. Além disso, queríamos tornar o uso de câmeras PTZ mais confortável, onde os atrasos são críticos.
Considerando que outras implementações para combate a atrasos ainda têm funcionalidade limitada e funcionam de maneira visivelmente inferior, decidimos usar o WebRTC.
O que fizemos
Implementar corretamente a plataforma WebRTC é uma tarefa desafiadora. Qualquer erro ou imprecisão pode resultar em atrasos na transmissão do vídeo não apenas não diminuindo em comparação com outras plataformas, mas até aumentando.
Para o funcionamento adequado do WebRTC, primeiro é necessário realizar uma modernização tecnológica da pilha para trabalhar com vídeo na web. E foi isso que fizemos.
Primeiro, implementamos um servidor de sinalização do protocolo WebRTC sobre Websocket, além de implantar um servidor peer WebRTC na nuvem com base no SDK webrtc.org. Sua função é distribuir fluxos de vídeo para os peers WebRTC dos clientes no formato H.264 + Opus/G.711 sem reencodificação do vídeo.
Escolhemos o Websocket como protocolo de sinalização porque ele já é bem suportado em todos os navegadores web populares. Com isso, é possível reduzir significativamente não apenas os custos de desenvolvimento, mas também evitar gastar tempo e recursos com handshakes TCP e TLS repetidos em comparação com AJAX.
A questão é que, por padrão, o WebRTC não fornece um protocolo de sinalização necessário para a configuração, manutenção e finalização corretas da comunicação de vídeo em tempo real entre os aplicativos de origem e os clientes.
E para implementar a tecnologia de sinalização por conta própria, precisávamos desenvolver nosso próprio servidor de sinalização com suporte a vários protocolos web (Websocket, WebRTC). Além disso, com a capacidade de gerenciar sessões e notificações em tempo real de forma segura, controle de vídeo e muitos outros parâmetros.
Superamos as limitações do P2P reduzindo a latência não por meio do P2P, mas sim com UDP e gerenciando o fluxo para diminuir a latência. Isso também está embutido no WebRTC, uma vez que o principal caso de uso são as conversas P2P através do navegador.
No cliente móvel, implementamos um player utilizando o SDK webrtc.org, pois apenas ele gerencia o fluxo corretamente, possui todos os conhecidos esquemas de Correção de Erros de Reencaminhamento (FEC) e implementa corretamente o mecanismo de retransmissão de pacotes para todos os navegadores. É importante ressaltar que o SDK webrtc.org é desenvolvido ativamente pelo Google.
Qual é o resultado da implementação do WebRTC?
Para visualizar vídeo ao vivo das câmeras, adicionamos ao painel do cliente um novo player otimizado com base no WebRTC. Ele garante alta velocidade de carregamento do vídeo e elimina completamente o problema de acumulação de latência à medida que o tempo de visualização aumenta.
Após a implementação do suporte ao WebRTC no serviço em nuvem Ivideon, podemos afirmar com total confiança que agora nossos clientes têm acesso à reprodução de vídeo ao vivo de alta qualidade. Atualmente, a latência na transmissão do vídeo não ultrapassa um segundo! Para comparação, o antigo mecanismo HLS fornecia a entrega do vídeo com uma latência de 5 a 7 segundos. A diferença na velocidade de exibição do vídeo é muito significativa e o usuário perceberá isso imediatamente ao começar a usar nosso serviço de vídeo.
Como já prevíamos, a implementação do novo player permitiu aumentar a responsividade do PTZ e da comunicação de voz com a câmera.
Há apenas um detalhe sutil que queremos chamar a atenção. O novo player WebRTC ainda está em modo de teste. Por isso, não o ativamos para todos os nossos clientes por padrão. Mas você pode ativá-lo manualmente, habilitando a opção correspondente nas configurações da câmera (para isso, você precisa acessar o ).
Características da implementação do WebRTC no serviço Ivideon
Atualmente, o WebRTC ainda é uma tecnologia experimental. Seu suporte ainda não está corretamente implementado em todos os navegadores e dispositivos do usuário, nem em todas as câmeras.
Essa é a razão pela qual ainda não tornamos o player WebRTC o principal por padrão para todos os usuários.
Por enquanto, recomendamos usar o WebRTC apenas nos navegadores Google Chrome. As versões mais recentes do Firefox e Safari também suportam essa tecnologia, mas, infelizmente, ainda de forma instável.
Ainda não implementamos o suporte ao WebRTC para navegadores em dispositivos móveis. No momento, se você acessar um dispositivo móvel e ativar o WebRTC, esse modo não funcionará. No entanto, o WebRTC está disponível em nossos aplicativos móveis para e .
E para concluir nossa narrativa sobre as características da implementação do WebRTC em nosso serviço, queremos ressaltar mais dois detalhes sutis.
Primeiro, a tecnologia é voltada especificamente para a transmissão de vídeo ao vivo em tempo real. Portanto, se a largura de banda do seu canal for insuficiente para transmitir o vídeo, você notará perda de quadros (com o HLS, você perceberá pausas no vídeo e aumento da latência, mas os quadros não serão perdidos), embora o vídeo continue a ser transmitido em tempo real.
Em segundo lugar, como a tecnologia é destinada a funcionar com vídeo ao vivo em tempo real, nós não a utilizamos para trabalhar com dados de vídeo arquivados.
Outras alterações no serviço
Atualmente, o Flash não participa mais do mecanismo de seleção automática do motor. Você ainda pode usar esse player, mas precisa escolhê-lo manualmente nas configurações da conta ou da câmera. Não é uma questão de moda, é que, de acordo com as estatísticas do nosso serviço, restam praticamente nenhum usuário trabalhando com Flash. E ao tentar determinar se o navegador do usuário é compatível, nós perdemos cerca de 2 segundos de tempo valioso.
Aqui está um resumo das mudanças que você pode esperar em nosso sistema de videovigilância em nuvem e na sua conta pessoal. Fique conosco e acompanhe as novidades!
Fonte: habr.com
