
Desde os primeiros dias de trabalho num sistema de videovigilância na nuvem, deparamo-nos com um problema, sem solução do qual podíamos desistir da Ivideon - este era o nosso Everest, uma escalada que consumiu muita energia, mas agora temos finalmente enfiou um machado de gelo no topo do quebra-cabeça de plataforma cruzada.
O sistema de transmissão de áudio e vídeo pela Internet não deve depender de equipamentos, clientes Web e dos padrões que eles suportam, e também funcionar corretamente na presença de Network Address Translators e firewalls. Um usuário de videovigilância na nuvem deseja acessar o serviço, mesmo que utilize câmeras analógicas, e prefere assistir a transmissão de vídeo ao vivo no dispositivo mais moderno.
É muito significativo que o usuário queira assistir aos vídeos com o mínimo de atraso. Quase a única maneira de mostrar vídeo com baixa latência em um navegador é usar WebRTC (comunicações em tempo real na web). WebRTC é um conjunto de tecnologias para transmissão ponto a ponto de vídeo e áudio em navegadores, inicialmente projetado para transmissão e reprodução de fluxos de vídeo com baixa latência. Para tanto, entre outras coisas, é utilizado o protocolo UDP.
Antes de contarmos o que o novo mecanismo oferece ao usuário, lembraremos por que e por que oferecemos suporte às 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 é surpresa que tenha sido inicialmente suportada em dispositivos Apple. Hoje, o vídeo HLS também é compatível com praticamente todos os decodificadores e muitos dispositivos que executam o sistema operacional. Android.
O mecanismo HLS usa o conhecido codec de vídeo H264 em combinação com fluxos de áudio AAC ou MP3 para transmitir dados de vídeo. Todo o fluxo de dados de áudio e vídeo é empacotado em um contêiner de transporte MPEG-TS. Para transmissão via protocolo HTTP, as informações contidas no stream são divididas em fragmentos descritos nas playlists m3u8. E só então esses fragmentos, junto com as playlists, são transmitidos via HTTP. Chunking significa automaticamente um atraso em segundos. Este é um recurso do contêiner MPEG-TS.
O mecanismo HLS também suporta fluxos multibitrate, Live/VOD.
Principais vantagens do HLS:
- suporte integrado em todos os principais navegadores;
- facilidade de implementação (em comparação com WebRTC);
- É muito conveniente e eficiente organizar todos os tipos de transmissões para um grande público devido ao fato de que os segmentos podem ser carregados uma vez em um CDN.
Apesar da simplicidade do motor, nem tudo é tão tranquilo quanto parece. O principal problema é que os desenvolvedores de players terceirizados se afastaram das recomendações da Apple, por exemplo, em termos de 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, eles tiveram que criar diferentes formatos de lista de reprodução para diferentes players.
Mas um dos maiores problemas do mecanismo HLS é a alta latência na transferência de dados.
As origens dos “freios”
A principal razão para a alta latência do HLS reside no fato de que os programadores criaram o mecanismo para obter imagens da mais alta qualidade. Portanto, os parâmetros do intervalo de quadros usados e o tamanho do buffer de reprodução simplesmente não são adequados para transmissões de vídeo ao vivo. Por causa disso, há um atraso bastante alto na transmissão do vídeo, que pode ser de 5 a 7 segundos.
Por um lado, isso não é muito, por exemplo, para quem assiste a um filme de um servidor de hospedagem de vídeo. Mas para sistemas de vigilância por vídeo, o atraso na transmissão de imagens de vídeo pode ser muito importante.
Se você estiver observando um escritório onde os funcionários olham para os monitores uma vez por hora, um atraso de 5 segundos não importa. Mas as pessoas começaram a reclamar que, por exemplo, ao transmitir uma partida de futebol, já escreviam GOOOOL no chat, mas isso ainda não está no vídeo :). Já temos vários casos de usuários em que o Ivideon deveria praticamente substituir o Skype.
É possível vencer a latência no HLS? A resposta a esta pergunta soa como o discurso de um exterminador de ratos experiente numa palestra para especialistas novatos em controle de pragas: “Os ratos não podem ser exterminados, mas seu número pode ser reduzido a um mínimo razoável”. O mesmo acontece com o atraso no HLS, não será possível reduzi-lo a zero, mas existem soluções no mercado que podem reduzir significativamente o atraso.
Cortes finos
Outra desvantagem do mecanismo é a utilização de pequenos arquivos para transferência de dados. Parece que o que há de errado nisso?
Qualquer pessoa que tenha tentado copiar um grande número de arquivos pequenos de uma mídia para outra provavelmente notou que a velocidade de gravação de tal conjunto é muito menor do que a de um arquivo grande do mesmo tamanho. E a intensidade de acesso ao disco rígido aumenta significativamente, o que geralmente afeta negativamente o desempenho de todo o computador. Portanto, a transmissão de dados de vídeo em pequenos pedaços 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 PC desktop. O principal é que o navegador esteja atualizado e compatível com HTML5 e Media Source Extensions.
- Excelente qualidade de imagem. A função de transmissão adaptativa de dados utilizada permite alterar dinamicamente a qualidade do vídeo transmitido dependendo da largura de banda da conexão à Internet, enquanto o algoritmo se esforça para manter a qualidade máxima.
- Não há necessidade de configurações complexas do equipamento do usuário.
Desvantagens:
- Suporte limitado para trabalhar com o mecanismo em alguns dispositivos.
- Altos atrasos na transmissão da imagem.
- Aumento significativo na sobrecarga e complexidade de otimização devido ao uso de arquivos pequenos. Devido à natureza do contêiner, nunca conseguiremos obter uma latência inferior ao tamanho do segmento.
As desvantagens do HLS superaram as vantagens para nós e nos obrigaram a procurar opções alternativas.
O que é WebRTC

()
A plataforma WebRTC foi desenvolvida pelo Google em 2011 para transmitir streaming de dados de vídeo e áudio entre navegadores e aplicativos móveis com latência mínima. Para isso, são utilizados o protocolo UDP padrão e algoritmos especiais de controle de fluxo. Hoje é um projeto de código aberto, é mantido ativamente pelo Google e está em desenvolvimento.
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 que usam WebRTC podem transferir dados entre si diretamente, sem usar 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 praticidade e os amplos recursos dessa tecnologia têm sido muito apreciados pelos desenvolvedores de todos os navegadores populares. O suporte ao WebRTC está atualmente disponível no Mozilla Firefox, Opera, Google Chrome (e em todos os navegadores baseados no Chromium), bem como em aplicativos móveis. Android e iOS.
Apesar de todas as suas vantagens indiscutíveis, o WebRTC tem várias desvantagens significativas.
Dificuldades na escolha
A tecnologia WebRTC é muito mais complexa em termos de interações de rede por se tratar de P2P. É difícil depurar, testar e pode se comportar de maneira imprevisível. Ao mesmo tempo, precisamos superar o NAT e o firewall, precisamos garantir o funcionamento em redes onde o UDP está bloqueado.
A implementação WebRTC do Google é muito difícil de usar. Existe até uma empresa inteira que fornece serviços de montagem de SDK. Além disso, a implementação do Google foi muito difícil de integrar ao nosso sistema sem recodificar o vídeo inteiro.
No entanto, há muito que queríamos dar aos usuários a oportunidade de trabalhar com vídeo “ao vivo” completo e minimizar o atraso entre a imagem na tela e os próprios eventos. Além disso, queríamos tornar o uso de câmeras PTZ, onde os atrasos são críticos, mais confortável.
Considerando que outras implementações anti-lag ainda têm funcionalidade limitada e funcionam visivelmente pior, decidimos usar WebRTC.
O que nos fizemos

Implementar adequadamente a plataforma WebRTC não é uma tarefa fácil. Qualquer erro de cálculo ou imprecisão pode levar a atrasos na transmissão de vídeo, não apenas diminuindo em comparação com outras plataformas, mas até aumentando.
Para que o WebRTC funcione corretamente, antes de mais nada, é necessário realizar uma atualização tecnológica da pilha para trabalhar com vídeo web. Foi isso que fizemos.
Primeiro, implementamos um servidor de protocolo de sinalização WebRTC sobre Websocket e também implantamos um servidor peer WebRTC na nuvem baseado no SDK webrtc.org. Sua tarefa é distribuir fluxos de vídeo para pares WebRTC clientes no formato H.264 + Opus/G.711 sem transcodificação de vídeo.
Escolhemos o Websocket como protocolo de sinalização porque ele já possui suporte de alta qualidade em todos os navegadores populares. Devido a isso, você pode reduzir significativamente não apenas a sobrecarga de desenvolvimento, mas também evitar o desperdício de tempo e recursos em repetidos handshakes TCP e TLS em comparação com AJAX.
O fato é que, por padrão, o WebRTC não fornece o protocolo de sinalização necessário para configurar, manter e encerrar adequadamente a comunicação de vídeo em tempo real entre os aplicativos de origem e cliente.
E para implementar de forma independente a tecnologia de sinalização, precisávamos desenvolver nosso próprio servidor de sinalização com suporte para diversos protocolos web (Websocet, WebRTC). E com a capacidade de gerenciar com segurança sessões e notificações em tempo real, gerenciamento de vídeos e muito mais.
Superamos as limitações do P2P reduzindo a latência não por meio do P2P, mas por meio de UDP e controle de fluxo para reduzir a latência. Isso também está integrado ao WebRTC, já que o principal caso de uso são conversas ponto a ponto por meio de um navegador.
No cliente móvel, implementamos o player usando o SDK webrtc.org, pois somente ele implementa corretamente o controle de fluxo, possui todos os esquemas conhecidos de correção de erros de encaminhamento (FEC) e implementa corretamente o mecanismo de reenvio de pacotes para todos os navegadores. Também é importante que o SDK webrtc.org esteja sendo desenvolvido ativamente pelo Google.
Qual é o resultado da implementação do WebRTC?
Para visualizar vídeo ao vivo de câmeras, adicionamos um novo player otimizado baseado em WebRTC à sua conta pessoal. Ele fornece velocidades rápidas de carregamento de vídeo e elimina completamente o problema de acúmulo de latência à medida que o tempo de visualização aumenta.
Depois de introduzir o suporte WebRTC no serviço em nuvem da Ivideon, podemos dizer com total confiança que nossos clientes agora podem assistir a vídeos ao vivo completos. Agora o atraso na transmissão de sequências de vídeo não ultrapassa um segundo! Para efeito de comparação, o mecanismo HLS anterior fornecia entrega de vídeo com um atraso de 5 a 7 segundos. A diferença na velocidade da demonstração do vídeo é muito significativa e o usuário notará isso imediatamente após começar a trabalhar com nosso serviço de vídeo.
Como esperávamos, a implementação do novo player melhorou a capacidade de resposta do PTZ e da comunicação de voz com a câmera.

Há apenas um ponto sutil para o qual queremos chamar a atenção. O novo player WebRTC está atualmente funcionando em modo de teste. E é por isso que não o habilitamos para todos os nossos clientes por padrão. Mas você mesmo pode ativá-lo habilitando o item correspondente nas configurações da câmera (para fazer isso, vá para ).
Funcionalidades de implementação de WebRTC no serviço Ivideon

WebRTC ainda é uma tecnologia experimental no momento. Seu suporte ainda não está implementado corretamente em todos os navegadores e dispositivos do usuário, e também não em todas as câmeras.
É exatamente por isso que ainda não tornamos o player WebRTC padrão para todos os usuários.
Por enquanto, recomendamos usar WebRTC apenas em navegadores Google Chrome. As versões mais recentes do Firefox e Safari também suportam esta tecnologia, mas, infelizmente, ainda é instável.
Ainda não implementamos suporte WebRTC para navegadores em dispositivos móveis. Atualmente, se você fizer login em um dispositivo móvel e ativar o WebRTC, este modo não funcionará. No entanto, o WebRTC está disponível em nossos aplicativos móveis para и .
E concluindo a história sobre os recursos de implementação do WebRTC em nosso serviço, vamos observar mais dois pontos sutis.
Em primeiro lugar, a tecnologia está focada na transmissão de vídeo ao vivo em tempo real. Portanto, se o seu canal não tiver largura de banda suficiente para transmitir o vídeo, você notará quedas de quadros (com HLS você notará desbotamento do vídeo e aumento da latência, mas não haverá quedas de quadros), mas o vídeo ainda será transmitido em real tempo.
Em segundo lugar, como a tecnologia foi projetada para funcionar especificamente com vídeo ao vivo em tempo real, não a utilizamos para trabalhar com dados de vídeo arquivados.
Outras mudanças no serviço
Neste momento, o Flash não está mais envolvido no mecanismo de seleção automática de mecanismo. Você ainda pode usar esse player, mas para fazer isso você precisa selecioná-lo manualmente nas configurações da conta ou da câmera. Isto não é uma homenagem à moda, apenas que segundo as estatísticas do nosso serviço praticamente não restam utilizadores a trabalhar com Flash. E tentando determinar se o navegador do usuário oferece suporte, perdemos cerca de 2 segundos de um tempo precioso.
Aqui está uma breve visão geral das mudanças que esperam por você em nosso sistema de vigilância por vídeo em nuvem e em nossa conta pessoal. Fique conosco e acompanhe as novidades!
Fonte: habr.com
