hogar › Internet › Visualización de cámaras IP vía rtsp. Transmitimos una transmisión de video desde una cámara IP usando WebRTC. ¿Por qué es necesario el protocolo RTSP?

Visualización de cámaras IP vía rtsp. Transmitimos una transmisión de video desde una cámara IP usando WebRTC. ¿Por qué es necesario el protocolo RTSP?

Según algunos datos, hoy en día existen cientos de millones Cámaras IP para videovigilancia. Sin embargo, el retraso en la reproducción del vídeo no es crítico para todos ellos. La videovigilancia suele producirse de forma "estática": la transmisión se graba en el almacenamiento y se puede analizar su movimiento. Existen muchas soluciones de software y hardware desarrolladas para videovigilancia que hacen bien su trabajo.

En este artículo veremos una aplicación ligeramente diferente. camaras ip, es decir, aplicación en transmisiones en línea donde sea necesario Baja latencia de comunicación.

En primer lugar, aclaremos cualquier 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 ni interfaz de red. La cámara web requiere conexión a una computadora, teléfono inteligente u otro dispositivo que tenga una tarjeta de red y un procesador.

cámara IP es un dispositivo independiente que tiene su propia tarjeta de red y procesador para comprimir el vídeo capturado y enviarlo a la red. Por tanto, una cámara IP es una minicomputadora independiente que se conecta completamente a la red y no requiere conexión a otro dispositivo, y puede transmitir directamente a la red.

Baja latencia(baja latencia) es un requisito bastante raro para las cámaras IP y las transmisiones en línea. La necesidad de trabajar con baja latencia surge, por ejemplo, si la fuente de la transmisión de vídeo interactúa activamente con los espectadores de esta transmisión.

En la mayoría de los casos, se necesita una latencia baja en los casos de uso de juegos. Estos ejemplos incluyen: una subasta de video en tiempo real, un casino de video con un crupier en vivo, un programa de televisión interactivo en línea con un presentador, control remoto de un quadcopter, etc.

Distribuidor de casino en línea en vivo en el trabajo.

Una cámara IP RTSP normal suele transmitir vídeo H.264 códec y puede funcionar en dos modos de transporte de datos: intercalado Y no entrelazado.

Modo intercalado el más popular y conveniente, porque En este modo, los datos de vídeo se transmiten a través de TCP dentro de la conexión de red a la cámara. Para distribuir desde una cámara IP a entrelazado, sólo necesita abrir/reenviar un puerto RTSP de la cámara (por ejemplo 554) al exterior. El reproductor solo puede conectarse a la cámara a través de TCP y captar la transmisión dentro de esta conexión.

El segundo modo de funcionamiento de la cámara es no entrelazado. En este caso, la conexión se establece mediante el protocolo. RTSP/TCP, y el tráfico va por separado, según el protocolo RTP/UDP fuera del canal TCP creado.

Modo no entrelazado más favorable para transmitir vídeo con latencia mínima, ya que utiliza el RTP/UDP, pero al mismo tiempo es más problemático si el jugador está ubicado detrás NAT.

Al conectarse a una cámara IP de un reproductor que está detrás de NAT, el reproductor debe saber qué direcciones IP y puertos externos puede usar para recibir tráfico de audio y video. Estos puertos se especifican en el texto Configuración SDP, que se envía a la cámara cuando se establece una conexión RTSP. Si la NAT se abrió correctamente y se determinaron las direcciones IP y los puertos correctos, entonces todo funcionará.

Entonces, para captar video de la cámara con un retraso mínimo, debe usar no intercalado modo y recibir tráfico de vídeo a través de UDP.

Los navegadores no admiten directamente la pila de protocolos RTSP/UDP, pero sí admiten la pila de protocolos de tecnología nativa. 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, la cámara IP necesitaría soporte parcial para la pila WebRTC.

Para eliminar esta incompatibilidad, se requiere un servidor de retransmisión intermedio, que actuará como puente entre los protocolos de la cámara IP y los protocolos del navegador.

El servidor se hace cargo de la transmisión de la cámara IP a través de RTP/UDP y lo envía a los navegadores conectados a través de WebRTC.

La tecnología WebRTC funciona según el protocolo. UDP y por lo tanto proporciona un bajo retraso en la dirección Servidor > Navegador. La cámara IP también funciona mediante el protocolo RTP/UDP y proporciona un bajo retraso en la dirección Cámara > Servidor.

La cámara puede generar una cantidad limitada de transmisiones debido a recursos y ancho de banda limitados. El uso de un servidor intermedio le permite escalar la transmisión desde una cámara IP a una gran cantidad de espectadores.

Por otro lado, al utilizar un servidor se habilitan dos patas de comunicación:
1) Entre espectadores y servidor
2) Entre el servidor y la cámara
Esta topología tiene una serie de "características" o "trampas". Los enumeramos a continuación.

Error n.º 1: códecs

Los códecs utilizados pueden ser un obstáculo para el rendimiento de baja latencia y pueden degradar el rendimiento general del sistema.

Por ejemplo, si la cámara emite una transmisión de video de 720p en H.264 y está conectado un navegador Chrome en un teléfono inteligente Android solo compatible con VP8.

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 sólo podrá dar servicio a entre 10 y 15 cámaras IP, a una velocidad aproximada de 1 cámara por núcleo físico.

Por lo tanto, si la capacidad del servidor no permite transcodificar el número planificado de cámaras, entonces se debe evitar la transcodificación. Por ejemplo, ofrezca solo navegadores que admitan H.264 y ofrezca a otros el uso de una aplicación móvil nativa para iOS o Android que admita el códec H.264.

Como opción para evitar la transcodificación en un navegador móvil, puede utilizar H.L.S.. Pero la transmisión HTTP no tiene ninguna latencia baja y actualmente no se puede utilizar para transmisiones interactivas.

Error n.º 2: pérdida y tasa de bits de la cámara

El protocolo UDP ayuda a afrontar la latencia, pero permite la pérdida de paquetes de vídeo. Por lo tanto, a pesar de la baja latencia, si hay grandes pérdidas en la red entre la cámara y el servidor, la imagen puede dañarse.

Para eliminar 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 dedicado entre la cámara y el servidor.

Error #3: Pérdidas y tasa de bits del espectador

Cada espectador de transmisión conectado al servidor también tiene un ancho de banda determinado en la descarga.

Si la cámara IP envía una transmisión que excede las capacidades del canal del espectador (por ejemplo, la cámara envía 1Mbps, y el espectador sólo puede aceptar 500 kbps), entonces habrá grandes pérdidas en este canal y, como resultado, el video se congelará o se producirán fuertes artefactos.

En este caso, hay tres opciones:

Transcodifique la transmisión de video individualmente para cada espectador a la tasa de bits requerida.
Transcodifica transmisiones no para cada persona conectada, sino para un grupo de espectadores.
Prepare transmisiones de cámara con anticipación en varias resoluciones y velocidades de bits.

Primera opción con transcodificación no es adecuado para cada espectador, ya que consumirá recursos de la CPU incluso con 10-15 espectadores conectados. Aunque cabe señalar que esta opción proporciona la máxima flexibilidad con la máxima carga de CPU. Aquellos. Esta es una opción ideal, por ejemplo, si está transmitiendo transmisiones a solo 10 personas distribuidas geográficamente, cada una de ellas recibe una tasa de bits dinámica y cada una necesita una latencia mínima.

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

Si el espectador no tiene suficiente ancho de banda, cambia al grupo en el que puede recibir cómodamente la transmisión de vídeo. Así, el número de sesiones de transcodificación no es igual al número de espectadores como en el primer caso, sino que es un número fijo, por ejemplo 2, si los grupos de transcodificación dos.

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 transmisiones con diferentes resoluciones y velocidades de bits, y los espectadores cambian entre estas transmisiones 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 transmisiones en lugar de solo una.

Como resultado, consideramos tres opciones para adaptarnos al ancho de banda de los espectadores. Si asumimos que una sesión de transcodificación ocupa 1 núcleo de servidor, obtenemos la siguiente tabla de carga de CPU:

La tabla muestra que podemos transferir 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.

Probando RTSP como WebRTC

Ha llegado el momento de realizar varias pruebas para identificar la imagen real de lo que está sucediendo. Tomemos una cámara IP real y realicemos pruebas para medir la latencia de transmisión.

Para probar, tomemos una cámara IP antigua. Enlace D DCS-2103 con el apoyo RTSP y códecs H.264 y G.711.

Como la cámara estuvo mucho tiempo en el armario junto con otros dispositivos y cables útiles, tuve que enviarla a Reiniciar presionando y 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ó la luz verde de la cámara y el enrutador vio otro dispositivo en la red local con la 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, vaya a la configuración de 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 disponibilidad de la cámara se puede verificar fácilmente usando reproductor VLC. Medios: transmisión de red abierta.

Nos aseguramos de que la cámara esté funcionando y transmitiendo video a través de RTSP.

Usaremos Web Call Server 5 como servidor para las pruebas. Este es un servidor de streaming con soporte. RTSP y WebRTC protocolos. Se conectará a la cámara IP a través de RTSP y retomar la transmisión de video. A continuación, distribuya la transmisión. WebRTC.

Después de la instalación, debe cambiar el servidor al modo RTSP no entrelazado que comentamos anteriormente. Esto se puede hacer agregando una configuración

Rtsp_interleaved_mode=falso
Esta configuración se agrega a la configuración de flashphoner.properties y requiere reiniciar el servidor:

Reinicio del servidor de llamadas web del servicio
Así, tenemos un servidor que opera según el esquema no entrelazado, recibe paquetes de la cámara IP vía UDP y luego los distribuye vía 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 tanto, lo primero que debemos hacer es reenviar el puerto 554 a la dirección 192.168.1.37 para entradas TCP/RTSP conexiones para que el servidor pueda establecer una conexión con 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 al puerto 554 y la dirección IP al 37.

Si tiene una NAT amigable y conoce la dirección IP externa, puede comenzar a probar con el servidor.

El 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 la transmisión es: rtsp://ip-cam/live1.sdp
Aquí cámara 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 configurar la cámara IP y probarla en VLC, configuré el servidor y probé RTSP fluye a través del servidor con distribución por WebRTC, finalmente podemos comparar las latencias.

Para ello utilizaremos un cronómetro 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 el navegador Firefox a través de un servidor remoto.

Hacer ping al servidor 100 ms.
Hacer ping localmente 1 ms.

La primera prueba con un temporizador se ve así:
Sobre un fondo negro está el temporizador original, que muestra un retraso cero. Izquierda VLC, a la derecha Firefox, recibiendo WebRTC transmitir desde un servidor remoto.

	Cero	VLC	Firefox, WCS
Tiempo	50.559	49.791	50.238
Latencia ms	0	768	321

En esta prueba vemos un retraso de VLC el doble del retraso Servidor de llamadas web Firefox +, a pesar de que el vídeo en VLC se reproduce en la red local y el vídeo que se muestra en Firefox pasa por un servidor en un centro de datos en Alemania y regresa. Esta discrepancia puede deberse al hecho de que VLC opera sobre TCP (modo entrelazado) e incluye algunos buffers adicionales para una reproducción de video fluida.

Tomamos varias fotografías para registrar los valores de latencia.

A menudo surge la pregunta: ¿Cómo conectar una cámara IP a un NVR si no está en la lista de compatibilidad?

Hay dos opciones ONVIF y RTSP

Comencemos con el protocolo ONVIF (Foro de interfaz de vídeo en red abierta)

ONVIF es un protocolo generalmente aceptado para el funcionamiento conjunto de cámaras IP, NVR y software, en caso de que todos los dispositivos sean de diferentes fabricantes. ONVIF se puede comparar con el idioma 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 puede estar deshabilitada, lo que significa que el nombre de usuario/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 operación a través del protocolo ONVIF.

En algunos casos, la contraseña ONVIF puede diferir de la contraseña de acceso WEB.

¿Qué está disponible cuando se conecta a través de ONVIF?

Hola

Transmisión de vídeo

Recepción y transmisión de datos de audio.

Control de cámara PTZ

Análisis de vídeo (por ejemplo, detección de movimiento)

Estos parámetros dependen de la compatibilidad de las versiones del protocolo ONVIF. En algunos casos, algunos parámetros no están disponibles o no funcionan correctamente.

k y usando ONVIF

En grabadores SNR y Dahua, el protocolo ONVIF se encuentra 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 sigue siendo el predeterminado

Uso de cámaras ONVIF puerto 8080
(desde 2017, en los nuevos modelos ONVIF el puerto se cambió a 80 para las series Alpha y Mira)
cámaras omnidireccionales Base usar ONVIF puerto 80, en el registrador se indica como 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 del canal.

Búfer decodificador— almacenamiento en búfer de la transmisión de vídeo que indica el valor del tiempo

Tipo de servidorAquí hay una opción de programación TCP o UDP.

tcp- establece una conexión entre el remitente y el destinatario, garantiza que todos los datos lleguen al destinatario sin cambios y en la secuencia requerida, y 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 controla la recepción de datos 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 de flujos 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 la grabadora y la cámara están conectadas correctamente

El estado rojo significa que hay problemas de conexión. Por ejemplo, el puerto de conexión es incorrecto.

El segundo método de conexión 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.

Usando estos comandos, la transmisión de video se transmite desde la fuente al destinatario.

por ejemplo desde una cámara IP a un DVR o servidor.

¿Qué está disponible al conectarse vía RTSP?

Transmisión de vídeo

Recepción y transmisión de datos de audio.

VentajaEste protocolo de transferencia es que no requiere compatibilidad de versiones.

Hoy en día, RTSP es compatible con casi todas las cámaras IP y NVR.

Defectos El protocolo es que, aparte de la transmisión de datos de vídeo y audio, no hay nada más disponible.

Veamos un ejemplo de conexión de una cámara. para y usando RTSP

RTSP ubicado en la pestaña Dispositivo remoto, línea Fabricante, en la grabadora SNR y Dahua se presenta comoGeneral

Seleccione el canal al que se conectará el dispositivo

Dirección URL- aquí ingresamos la cadena de consulta para la cual envía la cámara básico Transmisión RTSP con alto resolución.

URL adicional - Aquí ingrese la cadena de consulta para la cual la cámara envía adicional Transmisión RTSP con baja resolucion.

Solicitud de ejemplo:

rtsp://172.16.31.61/1 corriente principal

rtsp://172.16.31.61/2 transmisión adicional

¿Por qué necesitas un hilo adicional?

En un monitor local conectado a la grabadora de imágenes múltiples, la grabadora utiliza un hilo adicional para ahorrar recursos. Por ejemplo, en imágenes pequeñas con 16 ventanas, no es necesario decodificar en resolución Full HD, D1 es suficiente. Bueno, si ha abierto ventanas 1/4/8, 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 decodificadoralmacenamiento en búfer de la transmisión de video que indica el valor del tiempo

Tipo de servidor- TCP, UDP, Programación (similar al protocolo ONVIF)

Este artículo responde a las preguntas más comunes, como por ejemplo:

¿La cámara IP es compatible con el NVR?

Y si es compatible, ¿cómo se conecta?

RTSP (Protocolo de transmisión en tiempo real)– un protocolo de transmisión en tiempo real que contiene un conjunto simple de comandos básicos para controlar una transmisión de video.

Conexión de fuentes RTSP y cámaras IP en videoconferencias

El protocolo RTSP permite a cualquier usuario de TrueConf conectarse a cámaras de video IP y otras fuentes de contenido multimedia que transmiten utilizando este protocolo para monitorear objetos remotos. El usuario también puede conectarse a dichas cámaras para transmitir imágenes durante una videoconferencia.

Gracias a la compatibilidad con el 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 multimedia. Lea más sobre las transmisiones RTSP.

Beneficios de utilizar cámaras IP con soluciones de software TrueConf

Instalando una cámara IP en una oficina o taller industrial y conectándola en cualquier momento conveniente, podrá controlar el proceso de producción de su empresa.
Puede monitorear objetos remotos las 24 horas del día. Por ejemplo, si te vas de vacaciones y no quieres dejar tu apartamento desatendido, simplemente instala allí una o más cámaras IP. Al realizar una llamada a una de estas cámaras desde su PC con la aplicación cliente TrueConf instalada, podrá conectarse a su apartamento en cualquier momento y ver en tiempo real lo que está sucediendo allí.
En las aplicaciones cliente TrueConf para Windows, Linux y macOS, todos los usuarios tienen acceso a la posibilidad de grabar videoconferencias, gracias a lo cual durante la videovigilancia se pueden grabar cualquier evento y recibir evidencia documental de los mismos.

Visualización cómoda de transmisiones de video o configuración mediante software de reproductores multimedia en su computadora personal. Hoy veremos cómo configurar una transmisión RTSP para equipos de red de Dahua Technology en uno de los reproductores más populares, VLC Media Player.

RTSP (Protocolo de transmisión en tiempo real) es un protocolo que permite al usuario reproducir de forma remota una secuencia de datos multimedia (audio y video) utilizando un hipervínculo y un reproductor multimedia (en nuestro caso, VLC Media Player).

Si necesita configurar una transmisión de video, siga los siguientes pasos:

En primer lugar, debe descargar e instalar VLC Media Player, que está disponible gratuitamente en el sitio web oficial.
Haga clic en el elemento del menú Medios – Abrir flujo de red (Abrir URL).
Ingrese la dirección de red RTSP en la línea de solicitud.
Presione el botón de reproducción cuando aparezca la imagen del video en la pantalla.

Explicación del enlace. RTSP

Ejemplo:

rtsp:// :@:/cam/realmonitor?canal= &subtipo=

Dónde :

: Nombre de usuario (iniciar sesión).

: contraseña.

: dirección IP de la cámara de vídeo en red.

: El puerto predeterminado es 554. Este valor se puede ignorar.

: numero de canal. La numeración comienza desde 1.

: tipo de flujo. Significado El hilo principal es 0, el hilo adicional 1 es 1, el hilo adicional 2 es 2. Por ejemplo, el enlace para el hilo adicional número 1 sería el siguiente:

rtsp://administrador: [correo electrónico protegido]:554/cámara/monitor real?canal=1&subtipo=1

Las videocámaras IP de Dahua Technology admiten los protocolos de transferencia de datos TCP y UDP. Si se ha cambiado el puerto 554, cámbielo en el campo correspondiente de la configuración de la cámara de video (interfaz web).

Si tiene algún problema para configurar una transmisión RTSP, consulte la sección correspondiente.

Cómo comprobar la capacidad de transmitir una transmisión RTSP desde una cámara IP en varios navegadores web

Comprobemos la visualización de una transmisión de video RTSP en los navegadores Chrome, Firefox, Safari en computadoras de escritorio con Windows, Mac OS X, Linux y dispositivos móviles con Android e iOS.

Comprobando la transmisión RTSP en VLC

Para asegurarse rápidamente de que la transmisión RTSP esté disponible y transmita video, ábrala en el reproductor VLC. Si la transmisión se reproduce correctamente, pasamos a probar la interfaz web. Puede obtener la URL RTSP en el panel de control de la cámara IP o utilizar alguna transmisión de video RTSP disponible públicamente, por ejemplo esta: rtsp://b1.dnsdojo.com:1935/live/sys3.stream

Prueba de transmisión RTSP-WebRTC en los navegadores Google Chrome y Mozilla Firefox

Nos aseguramos de que la misma transmisión RTSP se reproduzca en una página HTML normal en los navegadores Chrome y Firefox.

1. Cargue la interfaz de demostración en el menú 'Demo / Streaming Min'. Esta es una interfaz web HTML5 mínima que utiliza tecnología WebRTC para mostrar una transmisión de video RTSP en los navegadores Chrome y Firefox.

2. Establezca una conexión con el servidor de llamadas web.

3. Ingrese la dirección RTSP de la cámara y comience a reproducir la transmisión:

Como resultado, probamos con éxito la reproducción de la transmisión RTSP en el navegador Google Chrome. Se puede realizar una prueba similar con los navegadores Firefox y Opera en aquellas plataformas móviles y de escritorio que admitan la tecnología WebRTC en los navegadores.

Prueba de una transmisión RTSP-Websocket en el navegador Safari en iOS y Mac OS X

Los navegadores de dispositivos iOS no son compatibles con la tecnología WebRTC. Por este motivo se utiliza un reproductor independiente, 'WS Player Min', que toma la transmisión a través del protocolo Websocket y la reproduce en el elemento HTML5-Canvas del navegador.

1. Al igual que en el caso de Chrome, debe abrir la página de la interfaz de demostración, pero seleccionar un elemento de menú diferente:

2. Después de esto, establezca una conexión con el servidor de llamadas web.

3. Ingrese la dirección de transmisión RTSP previamente conocida y reproduzca la transmisión de video:

Por lo tanto, lo anterior demuestra la capacidad de ver el tráfico RTSP convertido mediante Web Call Server en los navegadores web más comunes, incluidas las plataformas móviles más populares.

El siguiente paso es agregar un reproductor HTML5 RTSP a su propio sitio web. El proceso de adición se describe en detalle en la sección de Implementación adyacente.