\u00e9 muito conveniente e eficiente organizar diversas transmiss\u00f5es para um grande p\u00fablico, pois \u00e9 poss\u00edvel carregar segmentos uma \u00fanica vez no CDN.<\/li>\n<\/ul>\n\nApesar da simplicidade do motor, as coisas n\u00e3o s\u00e3o t\u00e3o suaves quanto parecem. O principal problema \u00e9 que os desenvolvedores de players de terceiros se afastaram das recomenda\u00e7\u00f5es da Apple, especialmente em rela\u00e7\u00e3o aos formatos de \u00e1udio suportados. Em particular, muitos desenvolvedores come\u00e7aram a adicionar a capacidade de trabalhar com fluxos de \u00e1udio populares: v\u00eddeo mpeg2, \u00e1udio mpeg2, etc. Como resultado, foi necess\u00e1rio criar diferentes formatos de playlist para players diferentes.<\/p>\n
No entanto, um dos maiores problemas do motor HLS \u00e9 a alta lat\u00eancia na transmiss\u00e3o de dados.<\/p>\n
As ra\u00edzes dos \"atrasos\"<\/h2>\n \nA principal raz\u00e3o para a alta lat\u00eancia do HLS reside no fato de que os programadores criaram o motor para obter a melhor qualidade de imagem poss\u00edvel. Portanto, os par\u00e2metros do intervalo de quadros utilizados e o tamanho do buffer de reprodu\u00e7\u00e3o n\u00e3o s\u00e3o adequados para transmiss\u00f5es ao vivo. Isso resulta em uma lat\u00eancia consider\u00e1vel na transmiss\u00e3o do v\u00eddeo, que pode chegar a 5-7 segundos.<\/p>\n
Por um lado, isso \u00e9 um intervalo pequeno, por exemplo, para aqueles que assistem a um filme em um servidor de hospedagem de v\u00eddeo. Mas para sistemas de monitoramento, a lat\u00eancia na transmiss\u00e3o do v\u00eddeo pode ser muito significativa.<\/p>\n
Se voc\u00ea est\u00e1 monitorando um escrit\u00f3rio onde os funcion\u00e1rios se afastam dos monitores a cada hora, ent\u00e3o uma lat\u00eancia de 5 segundos n\u00e3o faz nenhuma diferen\u00e7a. Mas as pessoas come\u00e7aram a reclamar que, por exemplo, durante a transmiss\u00e3o de um jogo de futebol, no chat j\u00e1 haviam escrito GOOOOOL, mas no v\u00eddeo isso ainda n\u00e3o apareceu :). J\u00e1 temos v\u00e1rios casos de usu\u00e1rios em que o Ivideon deve praticamente substituir o Skype.<\/p>\n
\u00c9 poss\u00edvel vencer a lat\u00eancia no HLS? A resposta a essa pergunta soa como um discurso de um exterminador de ratos experiente em uma palestra para iniciantes: \"\u00c9 imposs\u00edvel exterminar os ratos, mas \u00e9 poss\u00edvel reduzir a popula\u00e7\u00e3o a um m\u00ednimo razo\u00e1vel\". Assim acontece com a lat\u00eancia no HLS; n\u00e3o conseguiremos elimin\u00e1-la totalmente, mas existem solu\u00e7\u00f5es no mercado que permitem reduzir significativamente a lat\u00eancia.<\/p>\n
Segmenta\u00e7\u00e3o fina<\/h2>\n \nOutro ponto negativo do motor \u00e9 o uso de arquivos pequenos para a transmiss\u00e3o de dados. \u00c0 primeira vista, o que h\u00e1 de errado nisso?<\/p>\n
Qualquer pessoa que j\u00e1 tentou copiar uma grande quantidade de pequenos arquivos de um dispositivo para outro certamente notou que a velocidade de grava\u00e7\u00e3o desse conjunto \u00e9 muito menor do que a de um \u00fanico grande arquivo do mesmo tamanho. E a intensidade de acesso ao disco r\u00edgido aumenta significativamente, o que, em geral, afeta negativamente o desempenho de todo o computador. Portanto, a transmiss\u00e3o de dados de v\u00eddeo em pequenos fragmentos de 10 segundos tamb\u00e9m contribui para aumentar a lat\u00eancia do mecanismo.<\/p>\n
Vamos resumir brevemente todos os pr\u00f3s e contras da tecnologia HLS.<\/p>\n
Vantagens do HLS:<\/b><\/p>\n\nCapacidade de trabalhar com qualquer dispositivo. Voc\u00ea pode assistir a v\u00eddeos em qualquer dispositivo moderno, seja um smartphone, tablet, laptop ou desktop. O principal \u00e9 que o navegador da web seja de vers\u00e3o moderna e compat\u00edvel com HTML5 e Media Source Extensions.<\/li>\n Excelente qualidade de imagem. A fun\u00e7\u00e3o de transmiss\u00e3o adaptativa utilizada permite alterar dinamicamente a qualidade do v\u00eddeo transmitido de acordo com a largura de banda da conex\u00e3o com a Internet, enquanto o algoritmo busca manter a qualidade m\u00e1xima.<\/li>\n N\u00e3o h\u00e1 necessidade de configura\u00e7\u00f5es complexas no equipamento do usu\u00e1rio.<\/li>\n<\/ol>\n\nDesvantagens:<\/b><\/p>\n\nSuporte limitado ao funcionamento do mecanismo em alguns dispositivos.<\/li>\n Altas lat\u00eancias na transmiss\u00e3o de imagem.<\/li>\n Aumento significativo de overhead e dificuldade de otimiza\u00e7\u00e3o devido ao uso de arquivos de pequeno tamanho. Devido \u00e0s caracter\u00edsticas do cont\u00eainer, nunca conseguiremos obter uma lat\u00eancia menor do que o tamanho do segmento.<\/li>\n<\/ol>\n\nAs desvantagens do HLS superaram suas vantagens para n\u00f3s e nos fizeram buscar alternativas.<\/p>\n
O que \u00e9 WebRTC<\/h2>\n \nc<\/noindex>)<\/p>\nA plataforma WebRTC foi desenvolvida pelo Google em 2011 para a transmiss\u00e3o de dados de v\u00eddeo e \u00e1udio em tempo real entre navegadores e aplicativos m\u00f3veis com lat\u00eancia m\u00ednima. Para isso, usa-se o protocolo padr\u00e3o UDP e algoritmos especiais de controle de fluxo. Hoje, \u00e9 um projeto de c\u00f3digo aberto, que \u00e9 ativamente apoiado e desenvolvido pelo Google.<\/p>\n
WebRTC \u00e9 um conjunto de tecnologias para transmiss\u00e3o de v\u00eddeo e \u00e1udio ponto a ponto. Ou seja, por exemplo, os navegadores dos usu\u00e1rios podem transmitir dados diretamente entre si, sem o uso de servidores remotos para armazenar e processar dados. Todas as informa\u00e7\u00f5es tamb\u00e9m s\u00e3o processadas pelos navegadores e aplicativos m\u00f3veis dos usu\u00e1rios finais.<\/p>\n
A conveni\u00eancia e as grandes possibilidades dessa tecnologia foram muito bem avaliadas pelos desenvolvedores de todos os navegadores populares. Hoje, o suporte ao WebRTC \u00e9 implementado no Mozilla Firefox, Opera, Google Chrome (e em todos os navegadores baseados em Chromium), bem como em aplicativos m\u00f3veis para Android e iOS.<\/p>\n
Apesar de suas ineg\u00e1veis qualidades, o WebRTC tem algumas desvantagens significativas. <\/p>\n
Dificuldades na escolha<\/h2>\n \nA tecnologia WebRTC \u00e9 muito mais complexa em termos de intera\u00e7\u00f5es de rede devido ao fato de ser baseada em P2P. \u00c9 dif\u00edcil depurar, testar e pode se comportar de maneira imprevis\u00edvel. Al\u00e9m disso, precisamos superar NAT e firewalls, garantindo o funcionamento em redes onde o UDP est\u00e1 bloqueado.<\/p>\n
A implementa\u00e7\u00e3o do WebRTC do Google \u00e9 bastante complicada de usar. H\u00e1 at\u00e9 uma empresa inteira que oferece servi\u00e7os de montagem de SDK. Al\u00e9m disso, integrar a implementa\u00e7\u00e3o do Google ao nosso sistema foi bastante desafiador, j\u00e1 que precis\u00e1vamos evitar a recodifica\u00e7\u00e3o de todo o v\u00eddeo.<\/p>\n
No entanto, h\u00e1 muito desej\u00e1vamos oferecer aos usu\u00e1rios a capacidade de trabalhar com um real 'fluxo' de v\u00eddeo e minimizar o atraso da imagem na tela em rela\u00e7\u00e3o aos eventos reais. Al\u00e9m disso, quer\u00edamos tornar o uso de c\u00e2meras PTZ mais confort\u00e1vel, onde os atrasos s\u00e3o cr\u00edticos.<\/p>\n
Considerando que outras implementa\u00e7\u00f5es para combate a atrasos ainda t\u00eam funcionalidade limitada e funcionam de maneira visivelmente inferior, decidimos usar o WebRTC. <\/p>\n
O que fizemos<\/h2>\n \n
Para o funcionamento adequado do WebRTC, primeiro \u00e9 necess\u00e1rio realizar uma moderniza\u00e7\u00e3o tecnol\u00f3gica da pilha para trabalhar com v\u00eddeo na web. E foi isso que fizemos.<\/p>\n
Primeiro, implementamos um servidor de sinaliza\u00e7\u00e3o do protocolo WebRTC sobre Websocket, al\u00e9m de implantar um servidor peer WebRTC na nuvem com base no SDK webrtc.org. Sua fun\u00e7\u00e3o \u00e9 distribuir fluxos de v\u00eddeo para os peers WebRTC dos clientes no formato H.264 + Opus\/G.711 sem reencodifica\u00e7\u00e3o do v\u00eddeo.<\/p>\n
Escolhemos o Websocket como protocolo de sinaliza\u00e7\u00e3o porque ele j\u00e1 \u00e9 bem suportado em todos os navegadores web populares. Com isso, \u00e9 poss\u00edvel reduzir significativamente n\u00e3o apenas os custos de desenvolvimento, mas tamb\u00e9m evitar gastar tempo e recursos com handshakes TCP e TLS repetidos em compara\u00e7\u00e3o com AJAX.<\/p>\n
A quest\u00e3o \u00e9 que, por padr\u00e3o, o WebRTC n\u00e3o fornece um protocolo de sinaliza\u00e7\u00e3o necess\u00e1rio para a configura\u00e7\u00e3o, manuten\u00e7\u00e3o e finaliza\u00e7\u00e3o corretas da comunica\u00e7\u00e3o de v\u00eddeo em tempo real entre os aplicativos de origem e os clientes.<\/p>\n
E para implementar a tecnologia de sinaliza\u00e7\u00e3o por conta pr\u00f3pria, precis\u00e1vamos desenvolver nosso pr\u00f3prio servidor de sinaliza\u00e7\u00e3o com suporte a v\u00e1rios protocolos web (Websocket, WebRTC). Al\u00e9m disso, com a capacidade de gerenciar sess\u00f5es e notifica\u00e7\u00f5es em tempo real de forma segura, controle de v\u00eddeo e muitos outros par\u00e2metros.<\/p>\n
Superamos as limita\u00e7\u00f5es do P2P reduzindo a lat\u00eancia n\u00e3o por meio do P2P, mas sim com UDP e gerenciando o fluxo para diminuir a lat\u00eancia. Isso tamb\u00e9m est\u00e1 embutido no WebRTC, uma vez que o principal caso de uso s\u00e3o as conversas P2P atrav\u00e9s do navegador.<\/p>\n
No cliente m\u00f3vel, implementamos um player utilizando o SDK webrtc.org, pois apenas ele gerencia o fluxo corretamente, possui todos os conhecidos esquemas de Corre\u00e7\u00e3o de Erros de Reencaminhamento (FEC) e implementa corretamente o mecanismo de retransmiss\u00e3o de pacotes para todos os navegadores. \u00c9 importante ressaltar que o SDK webrtc.org \u00e9 desenvolvido ativamente pelo Google.<\/p>\n
Qual \u00e9 o resultado da implementa\u00e7\u00e3o do WebRTC?<\/h2>\n \n
![\"WebRTC](\"\/wp-content\/uploads\/2019\/04\/d185b546f5fc4c15021481c0cc2fedbd.jpeg\")