Impostazione del lettore di flusso UDP Splayer per il protocollo di flusso del ricevitore COFDM Vcan1776-RX

Impostazione del lettore UDP Stream sul trasmettitore e ricevitore video wireless HDMI COFDM

Il lettore di streaming UDP è la soluzione migliore per il codificatore video analogico CVBS a latenza più bassa. Il firmware predefinito del ricevitore video wireless COFDM Vcan1776-RX supporta il lettore RTSP. Alcuni client devono utilizzare il protocollo UDP.

L'indirizzo IP e il numero di porta possono essere configurati sulla pagina web, http://192.168.0.215 (predefinito)

1. Dopo aver aggiornato il firmware, l'estremità ricevente ripristinerà i parametri predefiniti di fabbrica (frequenza centrale: 320MHz, larghezza di banda wireless: 6MHz, indirizzo IP della porta di rete: 192.168.0.215), i clienti devono modificare la frequenza centrale e la larghezza di banda tramite Strumento della scheda di configurazione dei parametri, e il trasmettitore salva in modo coerente.

2. Il cliente accede al server web del ricevitore attraverso la pagina web (HTTP://192.168.0.215), e modifica il proprio indirizzo IP e l'impostazione dell'indirizzo IP del PC Windows collegato al ricevitore:

Nota: Tra loro, l’IP locale è l’IP del destinatario, e l'IP remoto è l'IP finale del PC Windows docking. Il cliente può configurarlo in base alla sua situazione reale. Tieni presente che la modifica avrà effetto solo dopo aver riavviato il ricevitore.

Scarica il lettore UDP Giocatore

3. Scarica il lettore UDP Giocatore.
   • 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
   • Splayer_v4.3.1_2024.4.16
   • https://drive.google.com/file/d/1uv7GqP8P4r6qGOWJ5gYn0b8bZ4ptL8H6/view?usp=drive_link
   • Giocatore_QT_V1.0 per Win10 o Win11
   • https://drive.google.com/file/d/1VAegQjd-PmIL2XbJf7K8dnujMxhoIuhd/view?usp=drive_link
   • Splayer_QT_V1.1.1 per Win10 o Win11
   • https://drive.google.com/file/d/1YMr2xxurGnbIBjFihc7f77afrdbOcc6l/view?usp=drive_link
   • Giocatore_QT_V2.0
   • https://drive.google.com/file/d/1sASbARCL1lXAIsVKqkmEObRGPREbaSES/view?usp=drive_link
4. Apri il lettore Splayer sul PC Windows, fare clic sul pulsante di impostazione nell'angolo in basso a destra, e verrà visualizzata la pagina delle impostazioni:

Nota:

1. Si può vedere che il numero della porta della porta è impostato su 1234, che è codificato dal programma di streaming UDP del ricevitore e non può essere modificato;
2. Nella colonna Decodifica, configurare in base alle proprietà del flusso video corrente, come la configurazione del flusso video a bassa latenza H264 come sopra;

4. Dopo aver impostato e fatto clic su “Confermare” pulsante per salvare i parametri, fare clic sul pulsante di riproduzione nell'angolo in basso a sinistra. Dopo che il PC Windows ha ricevuto il flusso push UDP, decodificherà e giocherà immediatamente.

L'impostazione del lettore stream UDP sopra è adatta per il modello seguente.

Come supporta il lettore VLC Linux? Riproduzione di streaming a basso ritardo sotto Linux?

Domanda: Ora lo streaming UDP non viene riprodotto con il lettore VLC. Devo riprodurre questo flusso UDP sotto Linux e cerco di comprendere i dettagli di questo flusso. Eventuali script, chiavi o altre cose?

Voglio creare il mio lettore sotto Linux e voglio capire i dettagli di questo flusso video UDP dal demodulatore.

Se si tratta di un normale flusso video UDP, quindi chiediti perché non funziona con VLC o OBS Studio.

Risposta: Per il modello Vcan1726-RX, Abbiamo due firmware per facoltativo, Il primo firmware per il lettore RTSP supporta il lettore VLC, ma alcuni clienti hanno menzionato che ha una lunga latenza, quindi abbiamo realizzato il secondo firmware, Trasmissione UDP sullo Splayer, che supporta una latenza inferiore.

Questo flusso audio e video UDP è il nostro formato personalizzato, quindi VLC non può spiegarlo. Se il tuo cliente desidera aprire il proprio lettore (sotto Linux), al momento ci sono due opzioni:

1. Aggiorna all'accesso al flusso RTSP predefinito (primo firmware per lettore RTSP)
2. Forniamo la biblioteca Demux e le routine corrispondenti (Dobbiamo comprendere l'ambiente Linux del cliente per compilare un file di biblioteca adatto)
3. Questo è il “Biblioteca e routine Demux” Scritto dai nostri ingegneri sotto l'Ubuntu 14.04 64sistema bit

Il secondo tipo è troppo difficile per i clienti ordinari, E non conosciamo le capacità di sviluppo del giocatore del tuo cliente.

Perché alcuni clienti incontrano il problema a bassa latenza presso Windows OS VLC Player, Non importa come abbiamo testato qui, Non abbiamo trovato questo problema. A quel tempo, Hai usato Windows per testare. Forse se fosse cambiato in Linux, Non ci sarebbe alcun problema di streaming RTSP. Prova a testare il campione VCAN1726 con la prima versione del firmware su Linux. Forse questo non è un problema sul sistema operativo Linux.

Domanda: Puoi creare un'immagine Docker per questa applicazione? Quale porta viene utilizzata per il flusso in arrivo, e un'altra porta per il flusso in uscita con un codec ampiamente usato (H264)?

Cosa sono Splayer e UDP Stream Player?

Splayer è un lettore multimediale che supporta vari formati video, Compreso lo streaming UDP.

Lo streaming UDP è un metodo per inviare dati video su Internet utilizzando il protocollo del datagram utente (UDP), che è un protocollo veloce e semplice che non garantisce la consegna o l'ordine dei pacchetti.

Lo streaming UDP può essere utilizzato per la trasmissione video in diretta o la trasmissione video a bassa latenza, ma può anche soffrire di perdita di pacchetti o corruzione.

Secondo i risultati della ricerca web, Splayer può riprodurre flussi UDP utilizzando i seguenti passaggi:

• Apri Splayer e fai clic su “URL aperto” pulsante nell'angolo in alto a destra.
• Immettere l'URL del flusso UDP nel formato UDP://@ip: porta, dove IP è l'indirizzo IP del server e la porta è il numero di porta del flusso. Per esempio, UDP://@224.0.0.1:1234.
• Fare clic su “ok” pulsante e attendere il caricamento del flusso.

Come funziona bene Splayer per Win10?

Domanda: Non possiamo iniziare lo frayer 4.2 e 4.3 sotto finestre 10. Potresti fornirci la versione corretta di Splayer per Windows 10 e 11?

4.2 inizia e si chiude al momento. 4.3 Inizia con il messaggio di errore.

Nome dell'applicazione difettoso: Splayer.exe, versione: 1.0.0.1, timestamp: 0X646D83E2
Nome del modulo difettoso: dvb_demux.dll, versione: 1.0.0.1, timestamp: 0x5fe5bdbf
Codice di eccezione: 0XC0000005
Offset di errore: 0X0001484A
ID processo di errazione: 0X3888
Ora di inizio dell'applicazione difettosa: 0X01DA1164B89C78EB
Percorso di applicazione difettosi: C:\Users\admin\Downloads\Splayer_v4.3_2022.10.22\Splayer.exe
Percorso del modulo difettoso: C:\Users\admin\Downloads\Splayer_v4.3_2022.10.22\dvb_demux.dll
Report ID: 4AF19407-045E-48E5-A0F7-86FC90C6B3D3
Pacchetto difettoso Nome completo:
ID applicazione relativa al pacchetto difettoso:

Risposta: Prova a utilizzare il nostro Splayer_Qt_v1.0.Zip (103.5mb).

Risposta: La nuova versione di Splayer funziona bene sul sito del problema con Win 10! Grazie!

Domanda: Abbiamo riscontrato che il ritardo temporale aumenta durante la riproduzione del video dal programma Reciver by Splayer (flusso UDP).

Se parlare in dettaglio – Il ricevitore si collega con un cavo Ethernet direttamente al PC. Il PC e il ricevitore sono nella stessa rete locale. Quando iniziamo lo splayer il ritardo è normale e il conteggio preciso ci mostra 330 msec, che è un po 'più di uno dall'output HDMI in cui abbiamo osservato 270 msec. È buono. Ma se aspettiamo alcuni minuti senza cambiamenti sul posto di lavoro osserviamo un continuo aumento del tempo che raggiunge 1-1,5 SEC che non è accettabile nella domanda del cliente.
Ieri l'ho provato io stesso alla vittoria 10, e win11 su diversi PC con complesso svolta vinci brandmauer con qt di splayer (Ultima versione da te), e splayer 4.3 (Vecchia versione). Ripeto questo problema ogni volta in qualsiasi configurazione.
Per favore aiutami a risolvere questo problema. Abbiamo bisogno di un ritardo costante nel tempo dal gioco di frayer che potrebbe non essere più di 350 msec.

Risposta: Un tale problema non dovrebbe verificarsi, Perché il giocatore non ha cache in modalità a bassa latenza, e il ritardo dipende completamente dalla capacità di decodifica del PC. Gli ingegneri creeranno l'ambiente e lo testreranno il prossimo lunedì.

Un altro punto è chiedere ai clienti di controllare l'impostazione della frequenza di aggiornamento del monitor del laptop. Per esempio, Se la fotocamera inserisce 1080p60, Quindi la frequenza di aggiornamento del monitor del laptop del cliente deve essere anche 60Hz. Altrimenti, Il display sarà troppo lento, che causerà anche la congestione dei dati e introdurrà ritardi.

Il giocatore di Slayer ha un grande ritardo, o la decodifica è lenta oppure la visualizzazione è lenta, è tutto causato dal PC.

Codifica fotocamera HDMI Decodifica ricevitore HDMI, uscita sul display, e test di ritardo della riproduzione su computer del lettore Splayer

Non troviamo il problema che hai menzionato.

Si può vedere che la schermata attuale del lettore Splayer e l'uscita HDMI del ricevitore sono coerenti, e il ritardo tra loro è molto basso.

Potresti chiedere al cliente?, qual è la risoluzione e il frame rate dell'ingresso della telecamera? Supponendo che la fotocamera del cliente sia 1080p60, puoi anche eseguire i due passaggi seguenti per risolvere ulteriormente il problema:

1. Consenti al cliente di modificare la fotocamera con una frequenza fotogrammi inferiore per eseguire il test, come 1080p50/30;
2. È possibile impostare i parametri del segmento di codifica per consentire la codifica down-frame. Per esempio, Invia il comando ATSO0,30_ tramite la porta dei parametri, e le uscite di codifica 1080p30 per il test.

Nota:

1. Splayer è sviluppato specificatamente per il nostro protocollo di streaming proprietario/personalizzato e attualmente non supporta l'analisi o la riproduzione dei protocolli MPEG-TS standard.
2. Splayer è attualmente disponibile solo su Windows. Le versioni Linux e Android non sono state ancora sviluppate e non sono supportate in questa fase.
3. Inoltre, non è il protocollo mpeg-ts a causare l'aumento del ritardo. Anche se è passato al nostro protocollo personalizzato, il ritardo non sarà ridotto (il nostro protocollo personalizzato esegue principalmente controlli CRC su tutti i pacchetti di dati, mentre il protocollo mpeg-ts no, che è la più grande differenza tra i protocolli). L'impatto maggiore sulla latenza è l'elaborazione della decodifica video e la visualizzazione nel lettore. Il nostro lettore Splayer sarà ottimizzato per scenari applicativi di trasmissione di immagini.
4. Anche se il cliente ottiene la nostra libreria demux ed estrae i flussi audio e video, deve ancora eseguire la decodifica e la visualizzazione del video da solo. Questo cliente normale non ha questa capacità. La maggior parte dei clienti utilizzerà solo lettori open source (come basato su gstreamer), e il ritardo video di questi lettori open source non sarà positivo. Se vuoi un buon ritardo video, fondamentalmente devi sviluppare il tuo giocatore.
5. Se il cliente insiste sulla libreria demux e afferma di avere la capacità di occuparsi della successiva decodifica e riproduzione video, Posso anche collaborare con te (ma forniamo solo la libreria e le routine demux sotto Linux/Android, e non forniscono la successiva decodifica e supporto relativo alla visualizzazione)
6. Il nostro protocollo personalizzato migliora principalmente la verifica CRC per gestire meglio gli errori di trasmissione, che aiuta a prevenire problemi imprevisti di decodifica video o addirittura arresti anomali del lettore causati da pacchetti di dati danneggiati. Il protocollo di demuxing in sé non introduce una latenza significativa, che si tratti del nostro protocollo personalizzato o del protocollo MPEG-TS standard. I principali fattori che influenzano la latenza sono in realtà le fasi successive di decodifica e rendering. Generalmente:
   • Poiché lo streaming UDP e la decodifica/rendering del lettore sono processi asincroni, la maggior parte dei lettori introduce una certa quantità di buffering prima di avviare la riproduzione. Più grande è il buffer, maggiore è la latenza.
     Per esempio, Il lettore multimediale VLC utilizza in genere un buffer relativamente grande, e la dimensione del buffer potrebbe persino aumentare dinamicamente durante la riproduzione. Al contrario, Splayer keeps the playback buffer intentionally very small to minimize latency.
   • Video decoding and frame rendering are also asynchronous processes. If rendering cannot keep up in time, decoded video frames may accumulate in the rendering queue, which introduces additional latency similar to pre-decoding buffering. Splayer is also optimized in this area to reduce frame accumulation and maintain low-latency playback.
7. Our custom protocol also includes several additional optimizations, which is why we ultimately decided to adopt it instead of continuing with the standard MPEG-TS protocol (which we originally used at the beginning):
   • Compared with the standard MPEG-TS protocol, our custom protocol reduces redundant protocol overhead and improves wireless bandwidth utilization. Ciò è particolarmente importante per i collegamenti wireless con limiti di larghezza di banda come i sistemi di trasmissione video COFDM.
   • Il nostro protocollo personalizzato offre una maggiore flessibilità per il multiplexing di diversi tipi di dati. Oltre a video e audio, può incapsulare comodamente i dati della porta seriale e altri flussi di dati definiti dall'utente, rendendolo più flessibile e più facile da estendere rispetto allo standard MPEG-TS.
   • Il nostro protocollo personalizzato supporta la crittografia e la decrittografia AES integrate direttamente all'interno del livello del protocollo. Ciò è particolarmente utile per i collegamenti wireless che non supportano nativamente la crittografia AES, come le connessioni Wi-Fi standard.
   • Inoltre, il nostro protocollo personalizzato è progettato specificamente per scenari di trasmissione a bassa latenza e ad alta affidabilità, consentendo un'ottimizzazione più rigorosa dell'intera pipeline di trasmissione e riproduzione rispetto a un protocollo standard generico.

Parente

1. Vuoi ottenere i dati UART dalla scheda encoder UART video HDMI CVBS?
2. SDK del lettore UDP a bassa latenza per Windows x64

Q: Il sistema supporta il multicast? Posso inviare un flusso a più IP?

UN: sì. Il sistema supporta il multicast UDP, consentendo di fornire un flusso a più ricevitori contemporaneamente senza duplicare il flusso per IP.Per utilizzare il multicast, impostare ilIP remoto dal lato mittente a un indirizzo multicast, per esempio224.0.0.23. Tutti i ricevitori si uniscono allo stesso gruppo multicast utilizzando lo stesso indirizzo. Dal lato del ricevitore, configurare lo stesso IP multicast:

• Giocatore: impostare l'IP del gruppo su224.0.0.23
• VLC: aprireudp://@224.0.0.23:8090

Il multicast consente lo streaming uno-a-molti all'interno della stessa rete. L'IP effettivo del dispositivo non è fondamentale; invece, la consegna dipende dal supporto multicast della rete e dai dispositivi che si uniscono allo stesso gruppo.Nota: Le condizioni della rete possono influire sulle prestazioni. Ambienti con VPN, macchine virtuali, più adattatori di rete, o gli switch senza supporto IGMP potrebbero influire sulla ricezione multicast.

Multicast

Unicast

Q: Se sono presenti più schede multicast encoder nella stessa rete, dovremmo cambiare la porta su ciascuna scheda per evitare conflitti?

UN: Non necessariamente. Esistono due modi validi per garantire che più flussi di codifica non entrino in conflitto sulla stessa rete:

1. Utilizzare indirizzi IP multicast UDP diversi per ogni flusso di codifica.
2. Utilizza numeri di porta UDP diversi per ogni flusso di codifica.

Lo streaming UDP si distingue per la combinazione di indirizzo IP (unicast o multicast) e numero di porta. Insieme, definiscono un'identità di flusso UDP univoca sulla rete.

Sulla scheda encoder, il Impostazioni del flusso UDP includere:

• IP remoto: Definisce l'indirizzo IP di destinazione (se viene utilizzato un indirizzo multicast, il flusso diventa un flusso multicast UDP).
• Porto di trasmissione: Definisce il numero della porta di trasmissione.

La combinazione di IP remoto + Porto di trasmissione determina un flusso UDP univoco.

Per evitare conflitti quando più schede multicast codificatore vengono distribuite nella stessa rete, è possibile assegnare diversi indirizzi IP multicast, diverse porte UDP, oppure utilizzarli entrambi a seconda dei requisiti di progettazione della rete.

Q: Come posso ottenere indirizzi IP multicast per il mio sistema?

UN: Gli indirizzi IP multicast non vengono assegnati automaticamente; sono selezionati dalla gamma multicast standard 224.0.0.0 a 239.255.255.255. In pratica, questi indirizzi dovrebbero essere pianificati e assegnati dall'amministratore di rete per garantire che non vi siano conflitti con i servizi o i dispositivi multicast esistenti sulla rete.

Q: La scheda codificatore deve trasmettere video su entrambe le interfacce HDMI e AV, ma entrambi i flussi utilizzano lo stesso indirizzo UDP. Come possiamo giocare o passare da uno all'altro??

UN: Quando i flussi HDMI e AV vengono trasmessi sullo stesso indirizzo UDP, sono tipicamente non separati da porte di rete, ma da identificatori di flusso interni, simile ad un MPEG-TS (Transport stream) struttura.

Come funziona

• Sia gli ingressi HDMI che AV lo sono multiplex in un unico flusso UDP
• Ad ogni sorgente video viene assegnato un ID flusso univoco (per esempio., PID / identificativo del servizio)
• Il ricevitore esegue demultiplexing basato su questi ID, anziché separarli per IP o porta
• Ciò consente a più canali video di coesistere in un flusso UDP

Come Splayer gestisce questa situazione

Con il nostro Giocatore 2.0 Lettore UDP, il sistema supporta nativamente questa architettura:

• Decodifica simultanea di più flussi video da un singolo indirizzo UDP
• Separazione del flusso basata su ID interni (Mappatura PID/servizi MPEG-TS)
• Passaggio in tempo reale tra sorgenti HDMI e AV senza modificare le impostazioni di rete
• Riproduzione multicanale flessibile utilizzando un'unica sorgente di ingresso UDP

Questo design semplifica la distribuzione mantenendo una configurazione UDP, pur continuando ad abilitare gestione video multi-ingresso e commutazione continua.

Puoi scaricare Giocatore 2.0 Lettore UDP Qui: Giocatore 2.0 Scarica il lettore UDP