Configuración del reproductor de transmisión Splayer UDP para el protocolo de transmisión del receptor COFDM Vcan1776-RX

Configuración del reproductor UDP Stream en el transmisor y receptor de video inalámbrico COFDM HDMI

El reproductor de transmisión UDP es la mejor solución para el codificador de video analógico CVBS de menor latencia. El firmware predeterminado del receptor de vídeo inalámbrico Vcan1776-RX COFDM admite reproductor RTSP. Algunos clientes necesitan utilizar el protocolo UDP..

La dirección IP y el número de puerto se pueden configurar en la página web, http://192.168.0.215 (defecto)

1. Después de actualizar el firmware, El extremo receptor restaurará los parámetros predeterminados de fábrica. (frecuencia central: 320megahercio, ancho de banda inalámbrico: 6megahercio, dirección IP del puerto de red: 192.168.0.215), Los clientes necesitan modificar la frecuencia central y el ancho de banda a través del Herramienta de placa de configuración de parámetros, y el transmisor guarda constantemente.

2. El cliente accede al servidor web del receptor a través de la página web (HTTP://192.168.0.215), y modifica su propia dirección IP y la configuración de la dirección IP del PC con Windows conectado al receptor:

Nota: Entre ellos, la IP local es la propia ip del receptor, y la IP remota es la IP final de la PC con Windows de acoplamiento. El cliente puede configurarlo según su situación real.. Tenga en cuenta que la modificación sólo tendrá efecto después de reiniciar el receptor..

Descarga el reproductor UDP jugador

3. Descarga el reproductor UDP jugador.
   • Splayer_v4.2_2020.6.6
   • https://drive.google.com/file/d/1ihzUhfnx2Wo3zLO8UAs1aUQeLswonJD-/view?usp=sharing
   • Splayer_v4.3_2022.10.22
   • https://drive.google.com/file/d/1PQc-LZ55qGnjeMsjkHYSloHfY3NEUsGH/view?usp=drive_link
   • Jugador_v4.3.1_2024.4.16
   • https://drive.google.com/file/d/1uv7GqP8P4r6qGOWJ5gYn0b8bZ4ptL8H6/view?usp=drive_link
   • Reproductor_QT_V1.0 para Win10 o Win11
   • https://drive.google.com/file/d/1VAegQjd-PmIL2XbJf7K8dnujMxhoIuhd/view?usp=drive_link
   • Reproductor_QT_V1.1.1 para Win10 o Win11
   • https://drive.google.com/file/d/1YMr2xxurGnbIBjFihc7f77afrdbOcc6l/view?usp=drive_link
   • Splayer_qt_v2.0
   • https://drive.google.com/file/d/1sASbARCL1lXAIsVKqkmEObRGPREbaSES/view?usp=drive_link
4. Abra el reproductor Splayer en la PC con Windows, haga clic en el botón de configuración en la esquina inferior derecha, y aparecerá la página de configuración:

Nota:

1. Se puede ver que el número de puerto del puerto está configurado en 1234, que está codificado por el programa de transmisión UDP del receptor y no se puede modificar;
2. En la columna Decodificar, configurar de acuerdo con las propiedades actuales de la transmisión de video, como la configuración de transmisión de video de baja latencia H264 como se muestra arriba;

4. Después de configurar y hacer clic en el “Confirmar” Botón para guardar los parámetros., haga clic en el botón de reproducción en la esquina inferior izquierda. Después de que la PC con Windows reciba la transmisión push UDP, se decodificará y reproducirá inmediatamente.

La configuración del reproductor de flujo UDP anterior es adecuada para el modelo siguiente.

¿Cómo es compatible con el reproductor VLC de Linux?? Reproducción de flujo de bajo retraso en Linux?

Pregunta: Ahora la transmisión UDP no se reproduce con el reproductor VLC. Necesito reproducir esta transmisión UDP en Linux y trato de comprender los detalles de esta transmisión.. Cualquier secuencia de comandos o claves u otras cosas.?

Quiero crear mi propio reproductor en Linux y quiero comprender los detalles de esta transmisión de video UDP desde el demodulador..

Si se trata de una transmisión de vídeo UDP normal, Entonces pregúntate por qué no funciona con VLC u OBS Studio..

Responder: Para el modelo Vcan1726-RX, Disponemos de dos firmware opcionales, El primer firmware para el reproductor RTSP es compatible con el reproductor VLC, pero algunos clientes mencionaron que tiene una latencia larga, Entonces hicimos el segundo firmware., Transmisión UDP en el Splayer, que admite una latencia más baja.

Esta transmisión de audio y video UDP es nuestro formato personalizado, entonces VLC no puede explicarlo. Si su cliente quiere abrir su propio reproductor (bajo linux), actualmente hay dos opciones:

1. Actualización al acceso predeterminado a la transmisión RTSP (primer firmware para reproductor RTSP)
2. Proporcionamos la biblioteca y rutinas DEMUX correspondientes. (Necesitamos comprender el entorno Linux del cliente para poder compilar un archivo de biblioteca adecuado.)
3. Este es el “Biblioteca y rutinas DEMUX” escrito por nuestros ingenieros bajo Ubuntu 14.04 64sistema de bits

El segundo tipo es demasiado difícil para los clientes comunes., y no conocemos las capacidades de desarrollo del propio reproductor de su cliente.

Porque algunos clientes enfrentan el problema de baja latencia en el reproductor VLC del sistema operativo Windows, no importa cómo probamos aquí, no encontramos este problema. En ese tiempo, Usaste Windows para probar. Tal vez si se cambiara a Linux, no habría ningún problema de transmisión RTSP. Intente probar la muestra Vcan1726 con la primera versión de firmware en Linux. Quizás esto no sea un problema en el sistema operativo Linux..

Pregunta: ¿Puedes crear una imagen acoplable para esta aplicación?? ¿Cuál puerto se utiliza para la transmisión entrante?, y otro puerto para el flujo saliente con algún códec ampliamente utilizado (h264)?

¿Qué son Splayer y UDP Stream Player??

SPlayer es un reproductor multimedia que admite varios formatos de vídeo., incluyendo transmisión UDP.

La transmisión UDP es un método para enviar datos de video a través de Internet utilizando el protocolo de datagramas de usuario. (UDP), que es un protocolo rápido y sencillo que no garantiza la entrega ni el orden de los paquetes.

La transmisión UDP se puede utilizar para transmisión de video en vivo o transmisión de video de baja latencia., pero también puede sufrir pérdida o corrupción de paquetes.

Según los resultados de búsqueda web., SPlayer puede reproducir transmisiones UDP siguiendo los siguientes pasos:

• Abra SPlayer y haga clic en el “Abrir URL” botón en la esquina superior derecha.
• Ingrese la URL de la transmisión UDP en el formato udp://@ip: Puerto, donde ip es la dirección IP del servidor y puerto es el número de puerto de la transmisión. Por ejemplo, udp://@224.0.0.1:1234.
• Clickea en el “DE ACUERDO” botón y espere a que se cargue la transmisión.

¿Cómo funciona bien Splayer para Win10??

Pregunta: No podemos iniciar Splayer 4.2 y 4.3 bajo Windows 10. ¿Podría proporcionarnos la versión correcta de Splayer para Windows? 10 y 11?

4.2 Comienza y cierra en este momento.. 4.3 comienza con el mensaje de error.

Nombre de la aplicación errónea: splayer.exe, versión: 1.0.0.1, marca de tiempo: 0x646d83e2
Nombre del módulo defectuoso: dvb_demux.dll, versión: 1.0.0.1, marca de tiempo: 0x5fe5bdbf
Código de excepción: 0xc0000005
Compensación de fallas: 0x0001484a
ID del proceso defectuoso: 0x3888
Hora de inicio de la aplicación errónea: 0x01da1164b89c78eb
Ruta de aplicación errónea: do:\UsuariosadminDescargasSplayer_v4.3_2022.10.22Splayer.exe
Ruta del módulo con errores: do:\UsuariosadminDescargasSplayer_v4.3_2022.10.22dvb_demux.dll
Identificación del informe: 4af19407-045e-48e5-a0f7-86fc90c6b3d3
Nombre completo del paquete defectuoso:
ID de aplicación relativo al paquete con errores:

Responder: Intente utilizar nuestro Splayer_qt_v1.0.zip (103.5megabyte).

Realimentación: La nueva versión de SPlayer funciona bien en el sitio problemático con Win 10! ¡Gracias!

Pregunta: Descubrimos que el retraso de tiempo aumentaba mientras se reproducía el vídeo del programa Reciver by Splayer. (flujo UDP).

Si habla en detalle – El receptor se conecta con un cable ethernet directamente al PC. La PC y el receptor están en la misma red local.. Cuando iniciamos el Splayer el retardo de tiempo es normal y el conteo preciso nos muestra 330 mseg, que es un poco más que uno de la salida HDMI donde observamos aproximadamente 270 mseg. es bueno. Pero si esperamos unos minutos sin ningún cambio en el lugar de trabajo observamos un aumento continuo en el retraso que alcanza 1-1,5 seg que no es aceptable en la aplicación del cliente.
Ayer lo probé yo mismo en Win. 10, y Win11 en diferentes PC con apagado complejo Win Brandmauer con Splayer qt (última versión tuya), y jugador 4.3 (versión antigua). Repito este problema cada vez en cualquier configuración..
Por favor ayúdenme a solucionar este problema.. Necesitamos un retraso constante en el tiempo de juego de Splayer, que no podría ser más de 350 mseg.

Responder: Un problema así no debería ocurrir, porque el reproductor no tiene caché en modo de baja latencia, y el retraso depende completamente de la capacidad de decodificación de la PC. Los ingenieros configurarán el entorno y lo probarán el próximo lunes..

Otro punto es pedir a los clientes que verifiquen la configuración de la frecuencia de actualización del monitor de su computadora portátil.. Por ejemplo, si la cámara ingresa 1080p60, entonces la frecuencia de actualización del monitor de la computadora portátil del cliente también debe ser de 60 Hz. De otra manera, la pantalla será demasiado lenta, lo que también provocará congestión de datos e introducirá retrasos.

El jugador Slayer tiene un gran retraso, O la decodificación es lenta o la pantalla es lenta., todo es causado por la pc.

Codificación de cámara HDMI Decodificación de receptor HDMI, salida a la pantalla, y prueba de retardo de reproducción por computadora del reproductor Splayer

No encontramos el problema que mencionas..

Se puede ver que la pantalla actual del reproductor Splayer y la salida HDMI del receptor son consistentes, y el retraso entre ellos es muy bajo.

¿Podrías preguntarle al cliente?, ¿Cuál es la resolución y la velocidad de fotogramas de la entrada de la cámara?? Suponiendo que la cámara del cliente es 1080p60, También puede seguir los dos pasos siguientes para solucionar aún más el problema.:

1. Permita que el cliente cambie la cámara a una velocidad de fotogramas más baja para realizar pruebas., como 1080p50/30;
2. Puede configurar los parámetros del segmento de codificación para permitir la codificación de cuadro inferior.. Por ejemplo, enviar el comando ATSO0,30_ a través del puerto de parámetros, y la codificación genera 1080p30 para realizar pruebas..

Nota:

1. Splayer está desarrollado específicamente para nuestro protocolo de transmisión patentado/personalizado y actualmente no admite el análisis ni la reproducción de protocolos MPEG-TS estándar..
2. Splayer actualmente está disponible solo en Windows. Las versiones de Linux y Android aún no se han desarrollado y no son compatibles en este momento..
3. en adición, no es el protocolo mpeg-ts el que hace que el retraso aumente. Incluso si se cambia a nuestro protocolo personalizado, el retraso no se reducirá (Nuestro protocolo personalizado realiza principalmente comprobaciones CRC en todos los paquetes de datos., mientras que el protocolo mpeg-ts no, ¿Cuál es la mayor diferencia entre los protocolos?). El mayor impacto en la latencia es el procesamiento de la decodificación y visualización del video en el reproductor.. Nuestro propio reproductor Splayer estará optimizado para escenarios de aplicaciones de transmisión de imágenes..
4. Incluso si el cliente obtiene nuestra biblioteca demux y extrae las transmisiones de audio y video, todavía tiene que hacer la decodificación y visualización del video por sí solo. Este cliente común y corriente no tiene esta capacidad.. La mayoría de los clientes sólo utilizarán reproductores de código abierto. (como por ejemplo basado en gstreamer), y el retraso de video de estos reproductores de código abierto no será bueno. Si quieres un buen retardo de video., Básicamente tienes que desarrollar tu propio jugador..
5. Si el cliente insiste en la biblioteca demux y dice que tiene la capacidad de encargarse de la posterior decodificación y reproducción de vídeo, También puedo cooperar contigo (pero solo proporcionamos la biblioteca y las rutinas demux en Linux/android, y no proporciona soporte posterior relacionado con la decodificación y la visualización)
6. Nuestro protocolo personalizado mejora principalmente la verificación CRC para manejar mejor los errores de transmisión., lo que ayuda a prevenir problemas inesperados de decodificación de video o incluso fallas del reproductor causadas por paquetes de datos corruptos. El protocolo de demultiplexación en sí no introduce una latencia significativa, ya sea nuestro protocolo personalizado o el protocolo estándar MPEG-TS. Los principales factores que afectan la latencia son en realidad las etapas de decodificación y renderizado posteriores.. En general:
   • Dado que la transmisión UDP y la decodificación/renderización del reproductor son procesos asincrónicos, la mayoría de los reproductores introducen una cierta cantidad de almacenamiento en búfer antes de iniciar la reproducción. Cuanto mayor sea el búfer, cuanto mayor sea la latencia.
     Por ejemplo, El reproductor multimedia VLC suele utilizar un almacenamiento en búfer relativamente grande, y su tamaño de búfer puede incluso aumentar dinámicamente durante la reproducción. En contraste, Splayer mantiene el buffer de reproducción intencionalmente muy pequeño para minimizar la latencia.
   • La decodificación de video y la representación de cuadros también son procesos asincrónicos.. Si el renderizado no puede mantenerse en el tiempo, Los fotogramas de vídeo decodificados pueden acumularse en la cola de renderizado., que introduce una latencia adicional similar al almacenamiento en búfer previo a la decodificación. Splayer también está optimizado en esta área para reducir la acumulación de fotogramas y mantener una reproducción de baja latencia..
7. Nuestro protocolo personalizado también incluye varias optimizaciones adicionales., Es por eso que finalmente decidimos adoptarlo en lugar de continuar con el protocolo estándar MPEG-TS. (que usamos originalmente al principio):
   • Comparado con el protocolo estándar MPEG-TS, Nuestro protocolo personalizado reduce la sobrecarga de protocolos redundantes y mejora la utilización del ancho de banda inalámbrico.. This is particularly important for bandwidth-constrained wireless links such as COFDM video transmission systems.
   • Our custom protocol provides greater flexibility for multiplexing different types of data. In addition to video and audio, it can conveniently encapsulate serial port data and other user-defined data streams, making it more flexible and easier to extend than standard MPEG-TS.
   • Our custom protocol supports integrated AES encryption and decryption directly within the protocol layer. This is especially useful for wireless links that do not natively support AES encryption, such as standard Wi-Fi connections.
   • en adición, our custom protocol is designed specifically for low-latency and high-reliability transmission scenarios, permitiendo una optimización más estricta en todo el proceso de transmisión y reproducción en comparación con un protocolo estándar de propósito general.

Relativo

1. ¿Desea obtener los datos UART de la placa codificadora de datos UART de vídeo HDMI CVBS??
2. SDK de reproductor UDP de baja latencia para Windows x64

Q: ¿El sistema admite multidifusión?? ¿Puedo enviar una transmisión a varias IP??

UN: Sí. El sistema admite multidifusión UDP., permitiendo que una transmisión se entregue a múltiples receptores simultáneamente sin duplicar la transmisión por IP.Para usar multidifusión, establecer elIP remota en el lado del remitente a una dirección de multidifusión, por ejemplo224.0.0.23. Todos los receptores se unen al mismo grupo de multidifusión utilizando la misma dirección. Del lado del receptor, configurar la misma IP multicast:

• jugador: establezca la IP del grupo en224.0.0.23
• VLC: abiertoudp://@224.0.0.23:8090

La multidifusión permite la transmisión de uno a muchos dentro de la misma red. La IP real del dispositivo no es crítica; en cambio, La entrega depende del soporte de multidifusión de la red y de los dispositivos que se unen al mismo grupo.Nota: Las condiciones de la red pueden afectar el rendimiento. Entornos con VPN, maquinas virtuales, múltiples adaptadores de red, o los conmutadores sin soporte IGMP pueden afectar la recepción de multidifusión.

multidifusión

unidifusión

Q: Si hay varias placas de multidifusión de codificadores en la misma red, ¿Deberíamos cambiar el puerto en cada placa para evitar conflictos??

UN: No necesariamente. Hay dos formas válidas de garantizar que varias transmisiones de codificador no entren en conflicto en la misma red.:

1. Utilice diferentes direcciones IP de multidifusión UDP para cada flujo de codificador.
2. Utilice diferentes números de puerto UDP para cada flujo de codificador.

La transmisión UDP se distingue por la combinación de Recopilamos varios tipos diferentes de información para diversos fines para brindarle y mejorar nuestro Servicio. (unidifusión o multidifusión) y número de puerto. Juntos, definen una identidad de flujo UDP única en la red.

En el tablero codificador, el Configuración de transmisión UDP incluir:

• IP remota: Define la dirección IP de destino. (si se utiliza una dirección de multidifusión, la transmisión se convierte en una transmisión de multidifusión UDP).
• Puerto de transmisión: Define el número del puerto de transmisión..

La combinación de IP remota + Puerto de transmisión determines a unique UDP stream.

To avoid conflicts when multiple encoder multicast boards are deployed in the same network, you can either assign different multicast IP addresses, different UDP ports, or use both depending on the network design requirements.

Q: How do I obtain multicast IP addresses for my system?

UN: Multicast IP addresses are not automatically assigned; they are selected from the standard multicast range 224.0.0.0 a 239.255.255.255. En la práctica, these addresses should be planned and allocated by the network administrator to ensure there are no conflicts with existing multicast services or devices on the network.

Q: The encoder board needs to output video over both HDMI and AV interfaces, but both streams use the same UDP address. ¿Cómo podemos jugar o cambiar entre ellos??

UN: Cuando las transmisiones HDMI y AV se transmiten a través de la misma dirección UDP, son típicamente no separados por puertos de red, pero por identificadores de flujo interno, similar a un MPEG-TS (Transport Stream) estructura.

Cómo funciona

• Tanto las entradas HDMI como AV son multiplexado en una única secuencia UDP
• A cada fuente de vídeo se le asigna un ID de transmisión única (P.EJ., PID / ID de servicio)
• El receptor realiza demultiplexación basada en estos ID, en lugar de separar por IP o puerto
• Esto permite que múltiples canales de video coexistan en una transmisión UDP.

Cómo maneja esto Splayer

Con nuestro jugador 2.0 Reproductor UDP, el sistema soporta esta arquitectura de forma nativa:

• Decodificación simultánea de múltiples transmisiones de video desde una única dirección UDP
• Separación de corrientes basada en identificaciones internas (Mapeo de servicio/PID MPEG-TS)
• Cambio en tiempo real entre fuentes HDMI y AV sin cambiar la configuración de red
• Reproducción multicanal flexible utilizando una única fuente de entrada UDP

Este diseño simplifica la implementación manteniendo una configuración UDP, mientras sigue habilitando Manejo de vídeo de múltiples entradas y conmutación perfecta..

puedes descargar jugador 2.0 Reproductor UDP aquí: jugador 2.0 Descarga del reproductor UDP