Desde os primeiros días de traballo nun sistema de videovixilancia na nube, enfrontámonos a un problema, sen unha solución para o que puidésemos renunciar a Ivideon: este era o noso Everest, unha escalada que requiría moita enerxía, pero agora temos por fin. meteu un piolet na parte superior do puzzle multiplataforma.
O sistema de transmisión de audio e vídeo a través de Internet non debe depender dos equipos, dos clientes web e dos estándares que admiten, e tamén funciona correctamente en presenza de tradutores de enderezos de rede e cortalumes. Un usuario de videovixilancia na nube quere acceder ao servizo, aínda que utilice cámaras analóxicas, e prefire ver a transmisión de vídeo en directo no dispositivo máis moderno.
É moi significativo que o usuario queira ver vídeos cun atraso mínimo. Case a única forma de mostrar vídeo con baixa latencia nun navegador é usar WebRTC (comunicacións web en tempo real). WebRTC é un conxunto de tecnoloxías para a transmisión peer-to-peer de vídeo e audio en navegadores, deseñadas inicialmente para a transmisión e reprodución de fluxos de vídeo con baixa latencia. Para iso utilízase, entre outras cousas, o protocolo UDP.
Antes de contarche o que ofrece o novo motor ao usuario, recordarémosche por que e por que admitimos as tecnoloxías HLS e por que decidimos seguir adiante.
Motor HLS: pros e contras
()
A tecnoloxía HLS (HTTP Live Streaming) foi desenvolvida por Apple, polo que non é de estrañar que fose compatible por primeira vez cos dispositivos Apple. Hoxe en día, o vídeo HLS tamén é compatible con practicamente todos os descodificadores e moitos dispositivos que executan o sistema operativo. Android.
O motor HLS usa o coñecido códec de vídeo H264 en combinación con fluxos de audio AAC ou MP3 para transmitir datos de vídeo. Todo o fluxo de datos de audio e vídeo está empaquetado nun contedor de transporte MPEG-TS. Para a transmisión a través do protocolo HTTP, a información contida no fluxo divídese en fragmentos descritos nas listas de reprodución m3u8. E só entón estes fragmentos, xunto coas listas de reprodución, transmítense a través de HTTP. A fragmentación automaticamente significa un atraso en segundos. Esta é unha característica do contedor MPEG-TS.
O motor HLS tamén admite fluxos multibitrate, Live/VOD.
Principais vantaxes do HLS:
- soporte integrado en todos os navegadores principais;
- facilidade de implementación (en comparación con WebRTC);
- É moi cómodo e eficiente organizar todo tipo de emisións para unha gran audiencia debido ao feito de que se poden cargar segmentos nunha CDN unha vez.
A pesar da sinxeleza do motor, non todo é tan suave como parece. O principal problema é que os desenvolvedores de reprodutores de terceiros afastáronse das recomendacións de Apple, por exemplo en canto aos formatos de audio compatibles. En particular, moitos desenvolvedores comezaron a engadir a posibilidade de traballar con fluxos de audio populares: vídeo mpeg2, audio mpeg2, etc. Como resultado, tiveron que crear diferentes formatos de lista de reprodución para diferentes reprodutores.
Pero un dos maiores problemas do motor HLS é a alta latencia na transferencia de datos.
As orixes dos "freos"
A principal razón da alta latencia de HLS reside no feito de que os programadores crearon o motor para obter imaxes de maior calidade. Polo tanto, os parámetros do intervalo de fotogramas utilizados e o tamaño do búfer de reprodución simplemente non son axeitados para as emisións de vídeo en directo. Debido a isto, hai un atraso bastante alto na transmisión de imaxes de vídeo, que pode ser de 5 a 7 segundos.
Por unha banda, isto non é moito, por exemplo, para os que ven unha película desde un servidor de hospedaxe de vídeos. Pero para os sistemas de videovixilancia, o atraso na transmisión de imaxes de vídeo pode ser moi importante.
Se estás vendo unha oficina na que os empregados miran desde os seus monitores unha vez por hora, entón un atraso de 5 segundos non importa en absoluto. Pero a xente comezou a queixarse de que, por exemplo, ao transmitir un partido de fútbol, xa escribían GOOOOL no chat, pero isto aínda non está no vídeo :). Xa temos unha serie de casos de usuarios nos que Ivideon debería substituír practicamente Skype.
É posible superar a latencia en HLS? A resposta a esta pregunta soa como o discurso dun exterminador de ratas experimentado nunha conferencia para especialistas novatos en control de pragas: "Non se poden exterminar as ratas, pero o seu número pódese reducir a un mínimo razoable". O mesmo co atraso no HLS, non será posible reducilo a cero, pero hai solucións no mercado que poden reducir significativamente o atraso.
Cortes finos
Outra desvantaxe do motor é o uso de pequenos ficheiros para a transferencia de datos. Parece que que hai de malo con isto?
Calquera que intentou copiar un gran número de ficheiros pequenos dun medio a outro probablemente teña notado que a velocidade de escritura deste conxunto é moito menor que un ficheiro grande do mesmo tamaño. E a intensidade de acceso ao disco duro aumenta significativamente, o que xeralmente afecta negativamente ao rendemento de todo o ordenador. Polo tanto, a transmisión de datos de vídeo en pequenos anacos de 10 segundos tamén contribúe a aumentar a latencia do motor.
Imos resumir brevemente todos os pros e contras da tecnoloxía HLS.
Vantaxes do HLS:
- Capacidade de traballar con calquera dispositivo. Podes ver vídeos en calquera dispositivo moderno, xa sexa un teléfono intelixente, tableta, portátil ou PC de escritorio. O principal é que o navegador web está actualizado e compatible con HTML5 e extensións de fontes multimedia.
- Excelente calidade de imaxe. A función de transmisión de datos adaptativa usada permítelle cambiar de forma dinámica a calidade do vídeo transmitido dependendo do ancho de banda da conexión a Internet, mentres que o algoritmo se esforza por manter a máxima calidade.
- Non é necesaria unha configuración complexa do equipo do usuario.
Desvantaxes:
- Soporte limitado para traballar co motor nalgúns dispositivos.
- Altos atrasos na transmisión da imaxe.
- Aumento significativo da sobrecarga e da complexidade da optimización debido ao uso de ficheiros pequenos. Debido á natureza do contedor, nunca poderemos obter unha latencia inferior ao tamaño do segmento.
As desvantaxes do HLS superaban as súas vantaxes para nós e obrigáronnos a buscar opcións alternativas.
Que é WebRTC
()
A plataforma WebRTC foi desenvolvida por Google en 2011 para transmitir datos de audio e vídeo en tempo real entre navegadores e aplicacións móbiles cunha latencia mínima. Para iso, utilízase o protocolo estándar UDP e algoritmos especiais de control de fluxo. Hoxe é un proxecto de código aberto, é mantido activamente por Google e está a ser desenvolvido.
WebRTC é un conxunto de tecnoloxías para a transmisión de audio e vídeo peer-to-peer. É dicir, por exemplo, os navegadores de usuarios que utilizan WebRTC poden transferir datos entre si directamente, sen utilizar servidores remotos para almacenar e procesar datos. Toda a información tamén é procesada polos navegadores e aplicacións móbiles dos usuarios finais.
A comodidade e as amplas capacidades desta tecnoloxía foron apreciadas polos desenvolvedores de todos os navegadores máis populares. A compatibilidade con WebRTC está dispoñible actualmente en Mozilla Firefox, Opera, Google Chrome (e todos os navegadores baseados en Chromium), así como en aplicacións móbiles que executan Android e iOS.
Con todas as súas indubidables vantaxes, WebRTC ten varias desvantaxes importantes.
Dificultades de elección
A tecnoloxía WebRTC é moito máis complexa en termos de interaccións de rede debido ao feito de que se trata de P2P. É difícil depurar, probar e pode comportarse de forma imprevisible. Ao mesmo tempo, temos que superar NAT e firewall, temos que garantir o funcionamento en redes onde UDP está bloqueado.
A implementación WebRTC de Google é moi difícil de usar. Incluso hai unha empresa enteira que ofrece servizos de montaxe de SDK. Ademais, a implementación de Google foi moi difícil de integrar co noso sistema sen volver codificar o vídeo completo.
Non obstante, hai tempo que queriamos dar aos usuarios a oportunidade de traballar con vídeos "en directo" completos e minimizar o desfase entre a imaxe na pantalla e os propios eventos. Ademais, tiñamos o desexo de facer máis cómodo o uso das cámaras PTZ, onde os atrasos son críticos.
Tendo en conta que outras implementacións anti-lag aínda teñen unha funcionalidade limitada e funcionan notablemente peor, decidimos usar WebRTC.
Que fixemos
Implementar correctamente a plataforma WebRTC non é unha tarefa fácil. Calquera erro de cálculo ou imprecisión pode provocar que os atrasos na transmisión de vídeo non só non diminúan en comparación con outras plataformas, senón que incluso aumenten.
Para que WebRTC funcione correctamente, en primeiro lugar, é necesario realizar unha actualización tecnolóxica da pila para traballar con vídeo web. Iso foi o que fixemos.
En primeiro lugar, implementamos un servidor de protocolo de sinalización WebRTC a través de Websocket e tamén implantamos un servidor de pares WebRTC na nube baseado no SDK webrtc.org. A súa tarefa é distribuír fluxos de vídeo aos pares do cliente WebRTC en formato H.264 + Opus/G.711 sen transcodificación de vídeo.
Escollemos Websocket como protocolo de sinalización porque xa ten soporte de alta calidade en todos os navegadores web populares. Debido a isto, pode reducir significativamente non só a sobrecarga de desenvolvemento, senón tamén evitar perder tempo e recursos en repetidas conexións TCP e TLS en comparación con AJAX.
O feito é que, por defecto, WebRTC non proporciona o protocolo de sinalización necesario para configurar, manter e finalizar correctamente a comunicación de vídeo en tempo real entre as aplicacións fonte e cliente.
E para implementar de forma independente a tecnoloxía de sinalización, necesitabamos desenvolver o noso propio servidor de sinalización con soporte para varios protocolos web (Websocet, WebRTC). E coa capacidade de xestionar de forma segura sesións e notificacións en tempo real, xestión de vídeos e moito máis.
Superamos as limitacións de P2P reducindo a latencia non a través de P2P, senón a través de UDP e control de fluxo para reducir a latencia. Isto tamén está integrado en WebRTC, xa que o caso de uso principal son as conversas p2p a través dun navegador.
No cliente móbil, implementamos o reprodutor mediante o SDK webrtc.org, xa que só el implementa correctamente o control de fluxo, ten todos os esquemas coñecidos de corrección de erros directos (FEC) e implementa correctamente o mecanismo para reenviar paquetes para todos os navegadores. Tamén é importante que o SDK webrtc.org estea a ser desenvolvido activamente por Google.
Cal é o resultado da implementación de WebRTC?
Para ver vídeo en directo desde cámaras, engadimos un novo reprodutor optimizado baseado en WebRTC á túa conta persoal. Ofrece velocidades rápidas de carga de vídeo e elimina por completo o problema da acumulación de latencia a medida que aumenta o tempo de visualización.
Despois de introducir o soporte de WebRTC no servizo na nube Ivideon, podemos dicir con total confianza que os nosos clientes agora poden ver vídeos en directo completos. Agora o atraso á hora de transmitir secuencias de vídeo non supera un segundo! A modo de comparación, o motor HLS anterior proporcionou a entrega de vídeo cun atraso de 5 a 7 segundos. A diferenza na velocidade de demostración do vídeo é moi significativa e o usuario notarao inmediatamente despois de comezar a traballar co noso servizo de vídeo.
Como esperabamos, a implementación do novo reprodutor mellorou a capacidade de resposta da PTZ e a comunicación de voz coa cámara.
Só hai un punto sutil sobre o que queremos chamar a atención. O novo reprodutor WebRTC está a traballar actualmente en modo de proba. E é por iso que non o activamos para todos os nosos clientes por defecto. Pero pode activalo vostede mesmo activando o elemento correspondente na configuración da cámara (para facelo, vai a ).
Características da implementación de WebRTC no servizo Ivideon
WebRTC aínda é unha tecnoloxía experimental polo momento. O seu soporte aínda non está correctamente implementado en todos os navegadores e dispositivos de usuarios, e tampouco en todas as cámaras.
É precisamente por iso que aínda non fixemos o reprodutor WebRTC como predeterminado para todos os usuarios.
Polo momento, recomendamos usar WebRTC só nos navegadores Google Chrome. As últimas versións de Firefox e Safari tamén admiten esta tecnoloxía, pero, por desgraza, aínda é inestable.
Aínda non implementamos a compatibilidade con WebRTC para navegadores en dispositivos móbiles. Actualmente, se inicia sesión desde un dispositivo móbil e activa WebRTC, este modo non funcionará. Non obstante, WebRTC está dispoñible nas nosas aplicacións móbiles para и .
E rematando a historia sobre as características da implementación de WebRTC no noso servizo, imos notar dous puntos máis sutís.
En primeiro lugar, a tecnoloxía céntrase na transmisión de vídeo en directo en tempo real. Polo tanto, se a túa canle non ten ancho de banda suficiente para transmitir o vídeo, notarás caídas de fotogramas (con HLS notarás un desvanecemento do vídeo e un aumento da latencia, pero non haberá caídas de fotogramas), pero o vídeo seguirá emitindo en real tempo.
En segundo lugar, dado que a tecnoloxía está deseñada para funcionar especificamente con vídeo en directo en tempo real, non a usamos para traballar con datos de vídeo arquivados.
Outros cambios no servizo
Neste momento, Flash xa non está implicado no mecanismo de selección automática do motor. Aínda podes usar ese reprodutor, pero para facelo debes seleccionalo manualmente na configuración da conta ou da cámara. Non se trata dunha homenaxe á moda, é só que, segundo as estatísticas do noso servizo, practicamente non quedan usuarios traballando con Flash. E tentando determinar se o navegador do usuario o admite, perdemos uns 2 segundos de tempo precioso.
Aquí tes unha breve visión xeral dos cambios que che esperan no noso sistema de videovixilancia na nube e na conta persoal. Quédese connosco e segue as novidades!
Fonte: www.habr.com
