Muchas veces surge la pregunta: ¿Cómo conectar una cámara ip al NVR si no está en la lista de compatibilidad?
Hay dos opciones ONVIF y RTSP
Comencemos con el protocolo ONVIF (Open Network Video Interface Forum)
ONVIF es un protocolo común para la interoperabilidad de cámaras IP, NVR, software, en caso de que todos los dispositivos sean de diferentes fabricantes. ONVIF se puede comparar con idioma en Inglés para la comunicación internacional de personas.
Asegúrese de que los dispositivos conectados admitan ONVIF; en algunos dispositivos, ONVIF puede estar desactivado de forma predeterminada.
O la autorización ONVIF se puede deshabilitar, lo que significa que el inicio de sesión/contraseña siempre será el predeterminado
independientemente del nombre de usuario/contraseña para WEB 
También vale la pena señalar que algunos dispositivos usanpuerto separado para trabajar bajo el protocolo ONVIF
En algunos casos, la contraseña de ONVIF puede diferir de la contraseña de acceso a la WEB.
¿Qué está disponible cuando se conecta a través de ONVIF?
Hola
Transferencia de datos de vídeo
Recepción y transmisión de datos de audio
Control cámaras PTZ(PTZ)
Análisis de video (por ejemplo, detección de movimiento)
Estas opciones dependen de la compatibilidad de las versiones del protocolo ONVIF. En algunos casos, algunos de los parámetros no están disponibles o funcionan incorrectamente.
K y utilizando ONVIF
En registradores SNR y Dahua Protocolo ONVIF ubicado en la pestaña Dispositivo remoto, línea Fabricante
Seleccione el canal al que se conectará el dispositivo
En la pestaña Fabricante, seleccione ONVIF
Especificar dirección IP dispositivos
RTSP el puerto permanece predeterminado
Uso de cámaras ONVIF puerto 8080
(desde 2017, en los nuevos modelos ONVIF, el puerto se ha cambiado a 80 para las series Alpha, Mira)
Cámaras OMNY Base usar ONVIF puerto 80, en el registrador se especifica como un puerto HTTP
Nombre
Contraseña según los parámetros del dispositivo
canal remoto el valor predeterminado es 1. Si el dispositivo es multicanal, se indica el número de canal.
Búfer del decodificador- almacenamiento en búfer de transmisión de video con valor de tiempo
Tipo de servidorhay una opción de programa TCP, UDP
TCP- establece una conexión entre el remitente y el destinatario, se asegura de que todos los datos lleguen al destinatario sin cambios y en la secuencia deseada, también regula la velocidad de transmisión.
A diferencia de TCP, UDP no establece una conexión preliminar, sino que simplemente comienza a transmitir datos. UDP no realiza un seguimiento de los datos que se reciben y no los duplica en caso de pérdida o error.
UDP es menos confiable que TCP. Pero, por otro lado, proporciona una transmisión más rápida debido a la ausencia de retransmisión de paquetes perdidos.
Cronograma— detección automática de tipo.
Así se ven los dispositivos conectados en Dahua
El estado verde significa que el DVR y la cámara están conectados correctamente
El estado rojo significa que hay problemas de conexión. Por ejemplo, el puerto de conexión es incorrecto.
La segunda forma de conectarse es RTSP(Protocolo de transmisión en tiempo real) 
RTSPun protocolo de transmisión en tiempo real que describe comandos para controlar una transmisión de video.
Con la ayuda de estos comandos, la transmisión de video se transmite desde la fuente al destinatario.
por ejemplo de una cámara IP a un DVR o un servidor.
¿Qué está disponible cuando se conecta a través de RTSP?
Transferencia de datos de vídeo
Recepción y transmisión de datos de audio
ventajade este protocolo de transferencia en el sentido de que no requiere compatibilidad de versiones.
Hoy, RTSP es compatible con casi todas las cámaras IP y NVR.
Defectos protocolo es que nada más está disponible excepto la transmisión de datos de video y audio.
Veamos un ejemplo de conexión de una cámara. para y utilizando RTSP
.jpg)
RTSP ubicado en la pestaña Dispositivo remoto, línea Fabricante, en el registrador SNR y Dahua, se presenta comoGeneral
Seleccione el canal al que se conectará el dispositivo
Dirección URL- aquí ingresamos la cadena de consulta por la cual la cámara regresa básico Transmisión RTSP desde alto resolución.
URL adicional - Aquí ingrese la cadena de consulta por la cual la cámara regresa adicional Transmisión RTSP desde baja resolucion.
Ejemplo de solicitud:
rtsp://172.16.31.61/1 corriente principal
rtsp://172.16.31.61/2 hilo adicional
¿Por qué necesita una transmisión adicional?
En un monitor local conectado a una grabadora de imágenes múltiples, la grabadora utiliza un hilo adicional para ahorrar recursos. Por ejemplo, en imágenes pequeñas de 16 ventanas no es necesario decodificar resolución Full HD, D1 es suficiente. Bueno, si ha abierto 1/4/8 ventanas en este caso, la transmisión principal se decodifica con alta resolución.
Nombresegún los parámetros del dispositivo
Contraseña según los parámetros del dispositivo
Búfer del decodificadoralmacenamiento en búfer de transmisión de video con valor de tiempo
Tipo de servidor- TCP, UDP, Horario (similar al protocolo ONVIF)
Este artículo responde a las preguntas más comunes, tales como:
¿La cámara IP es compatible con el NVR?
Y si es compatible como se conecta!?
Protocolo RTSP
RTSP (Protocolo de transmisión en tiempo real o, en ruso, protocolo de transmisión en tiempo real) es un protocolo de aplicación que describe comandos para controlar una transmisión de video. Con estos comandos podemos “ordenar” a la cámara o al servidor, por ejemplo, que comience a emitir un flujo de vídeo. Un ejemplo de una solicitud para iniciar la reproducción se ve así: PLAY rtsp://192.168.0.200/h264 RTSP/1.0
Es decir, RTSP es solo un conjunto de comandos para controlar la transmisión de video. Hagamos un experimento. Para ello, necesitamos una cámara IP que admita el protocolo RTSP y su dirección RTSP. Esta dirección se parece a esto rtsp://
Protocolo TCP
Digamos que hemos elegido el método RSTP sobre TCP y queremos comenzar a transmitir un flujo de video. ¿Qué ocurrirá a nivel de los mecanismos de transporte? Previamente, con la ayuda de varios comandos, se establecerá una conexión entre el remitente y el destinatario. Después de eso, comenzará la transferencia de datos de video. Al mismo tiempo, los mecanismos TCP
se asegurará de que todos los datos lleguen al destinatario sin cambios y en la secuencia correcta. TCP también regulará la tasa de transmisión para que el transmisor no envíe datos más intensamente de lo que el receptor puede procesarlos, por ejemplo,
UDP es una alternativa al transporte Protocolo TCP. A diferencia de TCP, UDP no establece una conexión previa, sino que simplemente comienza a transmitir datos. UDP no se asegura de que se reciban los datos y no los duplica si faltan partes o se reciben con errores. UDP menos
fiable que TCP. Pero, por otro lado, proporciona una transmisión más rápida debido a la ausencia de un mecanismo para retransmitir paquetes perdidos. La diferencia entre los protocolos TCP y UTP se puede ilustrar con el siguiente ejemplo. Dos amigos se encuentran. Opción TCP:
Iván: ¡Hola! ¿Chateamos?" (se establece la conexión)
Simón: "¡Hola! ¡Vamos!" (se establece la conexión)
Iván: “Ayer estuve en la tienda. ¿Lo entiendes?" (transferencia de datos)
Simón: "¡Sí!" (confirmación)
Iván: “Estaban descargando equipo nuevo. ¿Lo entiendes?" (transferencia de datos)
Semyon: "No" (confirmación)
Iván: “Estaban descargando equipo nuevo. ¿Lo entiendes?" (retransmisión)
Simón: "¡Sí!" (confirmación)
Iván: “Mañana estaré allí de nuevo. ¿Lo entiendes?" (transferencia de datos)
Simón: "¡Sí!" (confirmación)
variante UDP
Iván: ¡Hola! Fui a la tienda ayer” (transmisión de datos)
Iván: “Estaban descargando equipos nuevos” (transmisión de datos)
Iván: “Mañana estaré allí de nuevo” (transmisión de datos)
Iván: "Te puedo conseguir precios" (transmisión de datos)
Iván: "Prometieron descuentos por buenos volúmenes" (transmisión de datos)
Iván: "Si quieres, llama, vamos juntos" (transmisión de datos)
Semyon: "Sí, llamaré" (transmisión de datos)
También puede ver la diferencia en los protocolos haciendo el siguiente experimento: intente configurar la cámara en modo RTSP sobre TCP y mueva la mano frente a la lente; verá un retraso en la pantalla del monitor. Ahora ejecute la misma prueba en RTSP sobre el modo UDP. El retraso será menor. Varios factores afectan el tiempo de demora: el formato de compresión, la potencia de la computadora, el protocolo de transmisión y las características del software involucrado en la decodificación de video.
RTP (Protocolo de transporte en tiempo real), o protocolo de transporte en tiempo real en ruso. Este protocolo está diseñado específicamente para transmitir tráfico en tiempo real. Le permite monitorear la sincronización de los datos transmitidos, ajustar la secuencia de entrega de paquetes y, por lo tanto, es más adecuado para transmitir datos de video y audio. En general, es preferible usar RTP o UDP para transmitir un flujo de video. Trabajar a través de TCP se justifica solo si tenemos que trabajar con redes problemáticas, ya que el protocolo TCP podrá corregir errores y fallas que se produzcan durante la transferencia de datos.
RTSP (Protocolo de transmisión en tiempo real) es un protocolo de transmisión en tiempo real que contiene un conjunto simple de comandos básicos para controlar la transmisión de video.
Conexión de fuentes RTSP y cámaras IP en una videoconferencia
El protocolo RTSP permite que cualquier usuario de TrueConf se conecte a cámaras de video IP y otras fuentes de contenido multimedia que transmiten utilizando este protocolo para monitorear objetos remotos. Además, el usuario puede conectarse a dichas cámaras para transmitir imágenes durante una videoconferencia.
Gracias al soporte del protocolo RTSP, los usuarios de TrueConf Server no solo pueden conectarse a cámaras IP, sino también transmitir videoconferencias a reproductores RTSP y servidores de medios. Lea más sobre las transmisiones RTSP.
Beneficios de usar cámaras IP con soluciones de software TrueConf
- Al instalar una cámara IP en una oficina o taller industrial y conectarse a ella en cualquier momento conveniente, puede monitorear el proceso de producción de su empresa.
- Puede realizar un monitoreo las 24 horas de objetos remotos. Por ejemplo, si se va de vacaciones y no quiere dejar su apartamento desatendido, simplemente instale una o más cámaras IP allí. Al hacer una llamada a una de estas cámaras desde su PC con la aplicación de cliente TrueConf instalada, puede conectarse a su apartamento en cualquier momento y ver lo que sucede allí en tiempo real.
- Las aplicaciones de cliente TrueConf para Windows, Linux y macOS brindan a todos los usuarios la capacidad de grabar videoconferencias, gracias a las cuales puede grabar cualquier evento durante la videovigilancia y recibir evidencia documental de los mismos.
Según algunos datos, hasta la fecha, el mundo ha instalado cientos de millones Cámaras IP para videovigilancia. Sin embargo, lejos de todos ellos, el retraso en la reproducción de vídeo es fundamental. La videovigilancia, por regla general, ocurre "estáticamente": la transmisión se registra en el almacenamiento y se puede analizar en busca de movimiento. Para la videovigilancia se han desarrollado muchas soluciones de software y hardware que hacen bien su trabajo.
En este artículo, veremos una aplicación ligeramente diferente. cámaras IP, a saber, el uso en transmisiones en línea, cuando sea necesario bajo retardo de comunicación.
Antes que nada, aclaremos un posible malentendido en la terminología sobre webcams y cámaras IP.
Cámara web es un dispositivo de captura de video que no tiene su propio procesador e interfaz de red. La cámara web debe estar conectada a una computadora, teléfono inteligente u otro dispositivo que tenga tarjeta de red y procesador.
cámara IP es un dispositivo independiente que tiene su propia tarjeta de red y procesador para comprimir el video capturado y enviarlo a la red. Por lo tanto, la cámara IP es una mini computadora independiente que se conecta completamente a la red y no necesita estar conectada a otro dispositivo, y puede transmitir directamente a la red.
Baja latencia(baja latencia) es un requisito bastante raro para cámaras IP y transmisiones en línea. La necesidad de trabajar con baja latencia aparece, por ejemplo, si la fuente de la transmisión de video interactúa activamente con los espectadores de esta transmisión.
La mayoría de las veces, se necesita una latencia baja en los casos de uso de juegos. Los ejemplos incluyen: subasta de video en vivo, video casino con crupier en vivo, programa de televisión interactivo en vivo con el presentador, control remoto cuadricóptero, etc
Un crupier de casino en línea en vivo en el trabajo.
Una cámara IP RTSP ordinaria, por regla general, presiona el video en H.264 códec y puede operar en dos modos de transporte de datos: intercalado Y no intercalado.
Modo intercalado el más popular y conveniente, porque en este modo, los datos de video se transmiten a través del protocolo TCP dentro conexión de red a la cámara Para distribuir desde una cámara IP a intercalado, solo necesita abrir / reenviar un puerto RTSP de la cámara (por ejemplo, 554) al exterior. El jugador solo necesita conectarse a la cámara a través de TCP y recoger la transmisión que ya está dentro de esta conexión.
El segundo modo de funcionamiento de la cámara es no intercalado. En este caso, la conexión se establece mediante el protocolo RTSP/TCP, y el tráfico va ya por separado, según el protocolo RTP/UDP fuera del canal TCP creado.
Modo no intercalado más favorable para la transmisión de video con un retraso mínimo, ya que utiliza el protocolo RTP/UDP, pero al mismo tiempo es más problemático si el jugador se encuentra detrás NAT.
Al conectarse a la cámara IP de un jugador ubicada detrás de NAT, el jugador debe saber qué puertos y direcciones IP externas puede usar para recibir tráfico de audio y video. Estos puertos se especifican en la configuración SDP de texto que se envía a la cámara cuando se establece una conexión RTSP. Si el NAT se abrió correctamente y se definieron las direcciones IP y los puertos correctos, entonces todo funcionará.
Entonces, para tomar videos de la cámara con un retraso mínimo, debe usar no intercalado y recibir tráfico de video a través de UDP.
Los navegadores no admiten directamente la pila de protocolos RTSP/UDP, pero admiten la pila de protocolos de tecnología integrada WebRTC.
Las tecnologías de navegador y cámara son muy similares, en particular SRTP esta encriptado RTP. Pero para una distribución correcta a los navegadores, una cámara IP necesitaría soporte parcial para la pila WebRTC.
Para eliminar esta incompatibilidad, se requiere un servidor de retransmisión intermedio, que será un puente entre los protocolos de la cámara IP y los protocolos del navegador.
El servidor toma la transmisión de la cámara IP para sí mismo RTP/UDP y se lo da a los navegadores conectados a través de WebRTC.
La tecnología WebRTC funciona según el protocolo UDP y por lo tanto asegura baja latencia en la dirección Servidor > Navegador. La cámara IP también funciona en el protocolo. RTP/UDP y proporciona baja latencia en la dirección Cámara > Servidor.
La cámara puede dar un número limitado de secuencias, debido a los recursos y ancho de banda limitados. El uso de un servidor intermedio le permite escalar la transmisión desde una cámara IP a Número grande público.
Por otro lado, cuando se utiliza el servidor, se habilitan dos tramos de comunicación:
1) Entre los espectadores y el servidor
2) Entre el servidor y la cámara
Tal topología tiene una serie de "características" o "trampas". Los enumeramos a continuación.
Trampa #1 - Códecs
Los códecs utilizados pueden ser un obstáculo para la baja latencia y causar una degradación en el rendimiento general del sistema.Por ejemplo, si una cámara envía una transmisión de video de 720p en H.264 y un navegador Chrome está conectado a teléfono inteligente Android con soporte para VP8 solamente.
Cuando la transcodificación está habilitada, se debe crear una sesión de transcodificación para cada una de las cámaras IP conectadas, que decodifica H.264 y codifica en VP8. En este caso, un servidor de doble procesador de 16 núcleos podrá atender solo 10-15 cámaras IP, con un cálculo aproximado de 1 cámara por núcleo físico.
Por lo tanto, si las capacidades del servidor no permiten transcodificar el número planificado de cámaras, se debe evitar la transcodificación. Por ejemplo, sirva solo navegadores con soporte H.264 y ofrezca el resto para usar nativo aplicación movil para iOS o Android, donde hay soporte para el códec H.264.
Como opción para omitir la transcodificación en un navegador móvil, puede utilizar HLS. Pero la transmisión HTTP no tiene una latencia baja y actualmente no se puede usar para transmisión interactiva.
Trampa n.° 2: tasa de bits y pérdida de la cámara
El protocolo UDP ayuda a hacer frente a la demora, pero permite la pérdida de paquetes de video. Por lo tanto, a pesar de la baja latencia, con grandes pérdidas de red entre la cámara y el servidor, la imagen puede corromperse.
Para eliminar las pérdidas, debe asegurarse de que la transmisión de video generada por la cámara tenga una tasa de bits que se ajuste al ancho de banda asignado entre la cámara y el servidor.
Trampa n.º 3: tasa de bits y pérdida del espectador
Cada espectador de transmisión que se conecta al servidor también tiene una cierta rendimiento en Descargar.Si la cámara IP envía un flujo que excede las capacidades del canal del espectador (por ejemplo, la cámara envía 1Mbps, y el espectador solo puede aceptar 500 kbps), entonces habrá grandes pérdidas en este canal y, como resultado, frisos de video o artefactos fuertes.
En este caso, hay tres opciones:
- Transcodifique la transmisión de video individualmente para cada espectador a la tasa de bits requerida.
- Transcodifique transmisiones no para cada conectado, sino para un grupo de un grupo de espectadores.
- Prepare transmisiones desde la cámara con anticipación en varias resoluciones y tasas de bits.
Segunda opción es reducir la carga en la CPU del servidor utilizando grupos de transcodificación. El servidor crea varios grupos por bitrate, por ejemplo dos:
- 200 kbps
- 1Mbps
Tercera opción implica un rechazo total de la transcodificación en el lado del servidor y el uso de transmisiones de video ya preparadas en varias resoluciones y velocidades de bits. En este caso, la cámara está configurada para generar dos o tres secuencias con diferentes resoluciones y tasas de bits, y los espectadores cambian entre estas secuencias según su ancho de banda.
En este caso, la carga de transcodificación en el servidor desaparece y se traslada a la propia cámara, porque la cámara ahora se ve obligada a codificar dos o más secuencias en lugar de una.
Como resultado, consideramos tres opciones para ajustarnos al ancho de banda de los espectadores. Si asumimos que una sesión de transcodificación requiere 1 núcleo de servidor, obtenemos la siguiente tabla de carga de CPU:
La tabla muestra que podemos cambiar la carga de transcodificación a la cámara o transferir la transcodificación al servidor. Las opciones 2 y 3 parecen ser las más óptimas.
Probar RTSP como WebRTC
Es hora de realizar algunas pruebas para revelar la imagen real de lo que está sucediendo. Tomemos una cámara IP real y probémosla para medir la latencia de transmisión.Tomemos una cámara IP antigua para probar D-link DCS-2103 con el apoyo RTSP y códecs H.264 y G.711.
Dado que la cámara permaneció durante mucho tiempo en un armario con otros dispositivos y cables útiles, tuve que enviarla a reiniciar manteniendo presionado el botón en la parte posterior de la cámara durante 10 segundos.
Después de conectarse a la red, se encendió una luz verde en la cámara y el enrutador vio otro dispositivo en red local con dirección IP 192.168.1.37.
Vamos a la interfaz web de la cámara y configuramos los códecs y la resolución para probar:
A continuación, vamos a configuración de la red y averigüe la dirección RTSP de la cámara. En este caso, la dirección RTSP vivir1.sdp, es decir. La cámara está disponible en rtsp://192.168.1.37/live1.sdp
La accesibilidad de la cámara se puede comprobar fácilmente con reproductor VLC. Medios: abra la secuencia de red.
Nos aseguramos de que la cámara funcione y proporcione video a través de RTSP.
Usaremos Web Call Server 5 como servidor para las pruebas. Este es un servidor de transmisión con soporte RTSP y WebRTC protocolos Se conectará a la cámara IP por RTSP y toma la transmisión de video. Distribuir aún más la corriente por WebRTC.
Después de la instalación, debe cambiar el servidor al modo RTSP no intercalado que discutimos arriba. Esto se puede hacer agregando la configuración
rtsp_interleaved_mode=falso
Esta configuración se agrega a la configuración de flashphoner.properties y requiere un reinicio del servidor:
Servicio webcallserver reiniciar
Así, tenemos un servidor que funciona según el esquema no intercalado, recibe paquetes de la cámara IP a través de UDP y luego los distribuye a través de WebRTC (UDP).
El servidor de prueba está ubicado en un servidor VPS ubicado en el centro de datos de Frankfurt, tiene 2 núcleos y 2 gigabytes de RAM.
La cámara está ubicada en la red local en 192.168.1.37.
Por lo tanto, lo primero que debemos hacer es reenviar el puerto 554 a 192.168.1.37 para recibir TCP/RTSP conexiones para que el servidor pueda conectarse a nuestra cámara IP. Para hacer esto, agregue solo una regla en la configuración del enrutador:
La regla le dice al enrutador que redirija todo el tráfico entrante en el puerto 554 al 37, la dirección IP.
Si tiene un NAT amigable y conoce la dirección IP externa, puede comenzar a probar con el servidor.
Reproductor de demostración estándar en el navegador Google Chrome tiene este aspecto:
Para comenzar a reproducir una transmisión RTSP, solo necesita ingresar su dirección en el campo Arroyo.
En este caso, la dirección de flujo: rtsp://ip-cam/live1.sdp
Aquí camara ip esta es la dirección IP externa de su cámara. El servidor intentará establecer una conexión con esta dirección.
Prueba de latencia VLC vs WebRTC
Después de que configuramos la cámara IP y probamos en VLC, configuré el servidor y probé RTSP fluir a través del servidor con distribución por WebRTC, finalmente podemos comparar los retrasos.Para ello, utilizaremos un temporizador que mostrará fracciones de segundo en la pantalla del monitor. Encienda el temporizador y reproduzca la transmisión de video simultáneamente en VLC localmente y en navegador firefox a través de un servidor remoto.
hacer ping al servidor 100ms.
Hacer ping localmente 1ms.
La primera prueba del temporizador se ve así:
Sobre un fondo negro está el temporizador original, que muestra cero retraso. Izquierda VLC, a la derecha Firefox recepción WebRTC transmitir desde un servidor remoto.
| Cero | VLC | Firefox, WCS | |
| Tiempo | 50.559 | 49.791 | 50.238 |
| latencia ms | 0 | 768 | 321 |
Tomamos algunas fotos para capturar los valores de retraso.