Palabras clave: ciudad inteligente, vídeo de seguridad, reproducción de páginas web de vídeo de vigilancia RTSP, visualización 3D, gemelo digital

1.1 Puntos débiles de la industria

Con el desarrollo generalizado de aplicaciones inteligentes en todo el país ( ciudades inteligentes, comunidades inteligentes, seguridad pública inteligente, protección contra incendios inteligente, transporte inteligente, turismo inteligente y educación inteligente ), la visualización 3D y las plataformas gemelas digitales también han ganado popularidad como terminales de visualización centralizadas. para big data Uso en grandes áreas.

Dado que la visualización 3D y la plataforma gemela digital, como sistema de recopilación y visualización de diversos big data, necesitan acceder a diversos datos comerciales, incluidas varias fuentes de señales de video de seguridad en tiempo real, fuentes de video de comunicaciones de emergencia, cámaras industriales, real inalámbrico humano-máquina. -Video de retorno en tiempo, cámaras de maquinaria de ingeniería no tripuladas en minas inteligentes, varias señales de video en tiempo real en el sitio durante el comando remoto, varias imágenes visuales de robots en producción industrial, etc.

Debido a la necesidad de ser compatible con el entorno operativo multiterminal, la plataforma de visualización 3D generalmente funciona en modo B / S. En este momento, no se puede acceder directamente a la fuente de video de seguridad tradicional [transmisión de red RTSP] desde el lado del navegador. , pero la transmisión de la red RTSP debe convertirse a HTML5. Solo se puede reproducir normalmente después de utilizar el formato de protocolo de transmisión compatible con el navegador.

Ante esta situación, los fabricantes tradicionales convierten la transmisión de red RTSP en el protocolo HTTP Live Streaming (HLS) lanzado por Apple a través del servidor de transmisión de medios y luego implementan la reproducción del navegador multiterminal, pero debido a que el protocolo HLS es una segmentación progresiva. El protocolo de descarga de archivos no es un protocolo de transmisión de medios en el verdadero sentido, por lo que inherentemente tiene el problema de un largo retraso en la transmisión. El efecto de retraso más bajo que se puede lograr en la industria suele ser de aproximadamente 3 segundos, pero este índice de retraso no puede cumplir con aplicaciones específicas. escenarios en todos los requisitos de comunicación en tiempo real.

También hay algunos fabricantes que convierten transmisiones de red RTSP en transmisiones de red en formato HTTP-FLV para terminales de PC, a fin de lograr un retraso de red de 1 a 2 segundos, mejorando así aún más el rendimiento en tiempo real del terminal de PC. Sin embargo, esto todavía no puede satisfacer las necesidades de escenarios de aplicaciones como la comunicación de emergencia, el comando remoto y la interacción en tiempo real.

1.2 Introducción a la solución

Con base en los puntos débiles actuales de las aplicaciones de la industria, con base en las capacidades de investigación y desarrollo de tecnología de transmisión de medios acumuladas a lo largo de los años, nuestra empresa desarrolló con éxito un conjunto de soluciones de acceso de video unificado compatibles con HTML5 y latencia ultrabaja a principios de 2020. los últimos tres años Desde que la solución se lanzó al mercado a finales de 2020, ha mejorado enormemente la experiencia de comunicación en tiempo real y ha controlado el retraso de transmisión de un extremo a otro a unos 300 ms en un entorno de red privada, lo que ha sido ampliamente reconocido por los socios de la industria y los usuarios finales. Como importante innovación tecnológica en la industria, esta solución aporta valor real a los usuarios finales.

Debido a que esta tecnología es totalmente compatible con el estándar HTML5, puede ejecutarse normalmente en el lado de la PC (incluido el sistema Windwos, el sistema Linux, el sistema operativo localizado), el lado del dispositivo Android y el lado del dispositivo iOS, y no es necesario instalar un complemento del navegador. -ins de los principales fabricantes de monitorización, lo que mejora enormemente la experiencia del usuario y puede ser perfectamente compatible con varios sistemas empresariales (sistema de visualización 3D, gemelo digital, sistema GIS).

1.3 Implementación técnica

1.3.1 Arquitectura técnica

El diagrama de arquitectura de implementación técnica del sistema es el siguiente:

1.3.2 Composición del módulo funcional

La plataforma se compone principalmente de una estación de trabajo de transcodificación de video de baja latencia y un servidor de publicación de transmisiones en vivo de baja latencia .

Estación de trabajo de transcodificación de video de baja latencia : se utiliza para lograr acceso unificado a las cámaras de seguridad de varios fabricantes de front-end, realizar una conversión de formato de codificación y protocolo unificado y enviarlo al servidor de publicación de transmisiones en vivo de baja latencia en modo de baja latencia.

Servidor de publicación de transmisiones en vivo de baja latencia: se utiliza para realizar el reenvío de baja latencia de varios flujos de red, publicar en HTML5 para varios dispositivos terminales (PC, dispositivos iOS, dispositivos Android) y admitir aplicaciones de alta concurrencia de una a varias.

1.3.3 Tipos de terminales admitidos

Las soluciones existentes pueden admitir los siguientes terminales de dispositivos:

terminal de computadora

Terminal Android

Terminal iOS

Tipo de sistema operativo:

Windows/Linux/MacOS

Tipo de navegador:

Cromo/Firefox/Safari/Edge

Tipo de navegador:

Cromo/Firefox

WeChat, subprogramas de WeChat

Tipo de navegador:

Safari

WeChat, subprogramas de WeChat

1.3.4 Indicadores de desempeño de concurrencia

Después de las pruebas reales, los indicadores de rendimiento de concurrencia de nuestro sistema de software de servidor en vivo de baja latencia son los siguientes:

Entorno de configuración del hardware del servidor:

Procesador:Intel E5-2650

Memoria: 16GB

Disco duro: SSD de 120 GB

Tarjeta de red: Intel Gigabit LAN x 4 puertos

SO del servidor:

CentOS x64 7.6

Transmisión en vivo: 2 Mb/s

Resolución de imagen: 1280x720

Formato de codificación de vídeo: H.264

Índice de rendimiento concurrente: 2000 recepciones simultáneas de transmisiones en vivo

Uso máximo de CPU: 42%

Uso promedio de CPU: 35%

Uso promedio de memoria: 56%

1.3.5 Especificaciones de baja latencia

El retraso de un extremo a otro del sistema ocurre principalmente en los siguientes enlaces:

1. Retraso en la adquisición y codificación de vídeo;

Esta parte del retraso aparece en el lado de la cámara y el retraso está en el rango de 20 a 50 ms;

2. Retraso en el acceso al vídeo y en la transcodificación;

Esta parte del retraso ocurre en la estación de trabajo de transcodificación de video de baja latencia. Cuando se realiza la conversión de protocolo y la conversión de formato de codificación de video, el retraso está en el rango de 10 a 30 ms;

3. Retraso en el servicio de liberación en vivo;

Esta parte del retraso ocurre en el lado del servidor del servidor de publicación de transmisión en vivo de baja latencia. Cuando el servidor recibe la transmisión de red enviada por la estación de trabajo de transcodificación de video de baja latencia, necesita almacenar en caché de 2 a 3 cuadros de datos localmente para resistir. Jitter del ancho de banda de la red Para evitar el impacto de la congelación de la imagen.

Según los diferentes formatos de transmisión de red, esta parte del retraso está en el rango de 40 a 100 ms;

4. Retraso en la reproducción de decodificación del cliente:

Cuando el reproductor HTML5 del lado del cliente está reproduciendo la transmisión de red, debe esperar a que se reciba un cuadro completo de datos antes de poder decodificarlo y generarlo, y también necesita almacenar en caché de 1 a 2 cuadros de datos según el impacto de combatir la fluctuación de la red, por lo que esta parte del retraso está en el rango de 20 a 80 ms;

En resumen, el tiempo de retardo de todo el sistema de un extremo a otro suele estar en el rango de 300 a 500 ms, lo que es básicamente consistente con el modo de complemento del navegador del fabricante de monitoreo.