Splayer UDP-Stream-Player-Einstellung für das Stream-Protokoll des COFDM-Empfängers Vcan1776-RX

UDP-Stream-Player-Einstellung am COFDM HDMI Wireless-Videosender und -empfänger

Der UDP-Stream-Player ist die beste Lösung für den analogen CVBS-Video-Encoder mit der niedrigsten Latenz. Die Standard-Firmware des drahtlosen COFDM-Videoempfängers Vcan1776-RX unterstützt den RTSP-Player. Einige Clients müssen das UDP-Protokoll verwenden.

Die IP-Adresse und Portnummer können auf der Webseite konfiguriert werden, http://192.168.0.215 (Standard)

1. Nach dem Upgrade der Firmware, Die empfangende Seite stellt die werkseitigen Standardparameter wieder her (Mittenfrequenz: 320MHz, wireless-Bandbreite: 6MHz, IP-Adresse des Netzwerkports: 192.168.0.215), Kunden müssen die Mittenfrequenz und Bandbreite ändern Parameterkonfigurations-Board-Tool, und der Sender speichert konsistent.

2. Der Kunde greift über die Webseite auf den Empfänger-Webserver zu (HTTP://192.168.0.215), und ändert seine eigene IP-Adresse und die Einstellung der IP-Adresse des mit dem Empfänger verbundenen Windows-PCs:

Hinweis: Darunter, Die lokale IP ist die eigene IP des Empfängers, und die Remote-IP ist die End-IP des Docking-Windows-PCs. Der Kunde kann es entsprechend seiner tatsächlichen Situation konfigurieren. Beachten Sie, dass die Änderung erst nach einem Neustart des Receivers wirksam wird.

Laden Sie den UDP-Player herunter Splayer

3. Laden Sie den UDP-Player herunter Splayer.
   • 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
   • Splayer_QT_V1.0 für Win10 oder Win11
   • https://drive.google.com/file/d/1VAegQjd-PmIL2XbJf7K8dnujMxhoIuhd/view?usp=drive_link
   • Splayer_QT_V1.1.1 für Win10 oder 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. Öffnen Sie den Splayer-Player auf dem Windows-PC, Klicken Sie auf die Einstellungsschaltfläche in der unteren rechten Ecke, und die Einstellungsseite wird angezeigt:

Hinweis:

1. Es ist ersichtlich, dass die Port-Portnummer auf eingestellt ist 1234, Dies ist vom UDP-Streaming-Programm des Empfängers fest codiert und kann nicht geändert werden;
2. In der Spalte „Dekodieren“., entsprechend den aktuellen Videostream-Eigenschaften konfigurieren, wie die oben beschriebene H264-Videostream-Konfiguration mit geringer Latenz;

4. Nach dem Einstellen und Klicken auf „Bestätigen“ Klicken Sie auf die Schaltfläche, um die Parameter zu speichern, Klicken Sie auf die Wiedergabetaste in der unteren linken Ecke. Nachdem der Windows-PC den UDP-Push-Stream empfangen hat, es wird sofort dekodiert und abgespielt.

Die obige UDP-Stream-Player-Einstellung ist für das folgende Modell geeignet.

Wie unterstützt es den Linux-VLC-Player?? Wiedergabe eines Streams mit geringer Verzögerung unter Linux?

Frage: Jetzt wird der UDP-Stream nicht mit dem VLC-Player abgespielt. Ich muss diesen UDP-Stream unter Linux abspielen und versuche, die Details dieses Streams zu verstehen. Irgendwelche Skripte oder Schlüssel oder andere Dinge?

Ich möchte meinen eigenen Player unter Linux erstellen und die Details dieses UDP-Videostreams vom Demodulator verstehen.

Wenn es sich um einen regulären UDP-Videostream handelt, Dann fragen Sie sich, warum es nicht mit VLC oder OBS Studio funktioniert.

Antworten: Für Modell Vcan1726-RX, Wir haben zwei Firmware für optional, Die erste Firmware für den RTSP-Player unterstützt den VLC-Player, aber einige Kunden erwähnten, dass es eine lange Latenz hat, Also haben wir die zweite Firmware erstellt, UDP-Übertragung im Splayer, was eine geringere Latenz unterstützt.

Dieser UDP-Audio- und Videostream ist unser benutzerdefiniertes Format, VLC kann es also nicht erklären. Wenn Ihr Kunde seinen eigenen Player eröffnen möchte (unter Linux), Derzeit gibt es zwei Möglichkeiten:

1. Aktualisieren Sie auf den standardmäßigen RTSP-Stream-Zugriff (erste Firmware für RTSP-Player)
2. Wir stellen die entsprechende DEMUX-Bibliothek und Routinen zur Verfügung (Wir müssen die Linux-Umgebung des Kunden verstehen, um eine geeignete Bibliotheksdatei zu kompilieren)
3. Das ist das „DEMUX-Bibliothek und Routinen“ geschrieben von unseren Ingenieuren unter Ubuntu 14.04 64Bitsystem

Der zweite Typ ist für normale Kunden zu schwierig, und wir kennen die Entwicklungsmöglichkeiten des eigenen Players Ihres Kunden nicht.

Da einige Clients beim VLC-Player des Windows-Betriebssystems auf das Problem der geringen Latenz stoßen, Egal wie wir hier getestet haben, Wir haben dieses Problem nicht gefunden. Damals, Sie haben Windows zum Testen verwendet. Vielleicht, wenn es auf Linux umgestellt würde, Es würde kein RTSP-Streaming-Problem geben. Bitte versuchen Sie, das Vcan1726-Beispiel mit der ersten Firmware-Version unter Linux zu testen. Möglicherweise ist dies unter Linux kein Problem.

Frage: Können Sie ein Docker-Image für diese Anwendung erstellen?? Welcher Port wird für den eingehenden Stream verwendet?, und ein weiterer Port für den ausgehenden Stream mit einem weit verbreiteten Codec (h264)?

Was sind Splayer und der UDP Stream Player??

SPlayer ist ein Mediaplayer, der verschiedene Videoformate unterstützt, inklusive UDP-Streaming.

UDP-Streaming ist eine Methode zum Senden von Videodaten über das Internet mithilfe des User Datagram Protocol (UDP), Dabei handelt es sich um ein schnelles und einfaches Protokoll, das keine Zustellung oder Reihenfolge der Pakete garantiert.

UDP-Streaming kann für Live-Videoübertragungen oder Videoübertragungen mit geringer Latenz verwendet werden, Es kann jedoch auch zu Paketverlusten oder -beschädigungen kommen.

Laut Web-Suchergebnissen, Mit den folgenden Schritten kann SPlayer UDP-Streams abspielen:

• Öffnen Sie SPlayer und klicken Sie auf „URL öffnen“ Schaltfläche in der oberen rechten Ecke.
• Geben Sie die URL des UDP-Streams im Format udp ein://@ip: Hafen, Dabei ist IP die IP-Adresse des Servers und Port die Portnummer des Streams. Beispielsweise, UDP://@224.0.0.1:1234.
• Klicken Sie auf „OK“ Klicken Sie auf die Schaltfläche und warten Sie, bis der Stream geladen ist.

Wie funktioniert der Splayer gut für Win10??

Frage: Wir können Splayer nicht starten 4.2 und 4.3 unter Windows 10. Könnten Sie uns die richtige Version von Splayer für Windows zur Verfügung stellen? 10 und 11?

4.2 startet und endet im Moment. 4.3 beginnt mit der Fehlermeldung.

Fehlerhafter Anwendungsname: Splayer.exe, Ausführung: 1.0.0.1, Zeitstempel: 0x646d83e2
Fehlerhafter Modulname: dvb_demux.dll, Ausführung: 1.0.0.1, Zeitstempel: 0x5fe5bdbf
Ausnahmecode: 0xc0000005
Fehler-Offset: 0x0001484a
Fehlerhafte Prozess-ID: 0x3888
Fehlerhafte Startzeit der Anwendung: 0x01da1164b89c78eb
Fehlerhafter Anwendungspfad: C:\Users\admin\Downloads\Splayer_v4.3_2022.10.22\Splayer.exe
Fehlerhafter Modulpfad: C:\Users\admin\Downloads\Splayer_v4.3_2022.10.22\dvb_demux.dll
Berichts-ID: 4af19407-045e-48e5-a0f7-86fc90c6b3d3
Vollständiger Name des fehlerhaften Pakets:
Fehlerhafte paketbezogene Anwendungs-ID:

Antworten: Bitte versuchen Sie, unsere Splayer_qt_v1.0.zip zu verwenden (103.5Mb).

Feedback: Die neue Version von SPlayer funktioniert auf der Problemseite unter Win gut 10! Danke schön!

Frage: Wir haben festgestellt, dass die Zeitverzögerung beim Abspielen des Videos aus dem Reciver by Splayer-Programm zunimmt (UDP-Stream).

Wenn wir im Detail sprechen – Der Receiver wird mit einem Ethernet-Kabel direkt an den PC angeschlossen. PC und Receiver befinden sich im selben lokalen Netzwerk. Wenn wir den Splayer starten, ist die Zeitverzögerung normal und die genaue Zählung zeigt es uns 330 ms, Das ist etwas mehr als eins vom HDMI-Ausgang, den wir gesehen haben 270 ms. Es ist gut. Wenn wir jedoch einige Minuten warten, ohne dass sich am Arbeitsplatz etwas ändert, beobachten wir eine kontinuierliche Zunahme der Zeitverzögerung, die erreicht wird 1-1,5 Sekunden, was in der Kundenanwendung nicht akzeptabel ist.
Gestern habe ich es selbst auf Win getestet 10, und Win11 auf verschiedenen PCs mit komplexer Abschaltung von Win Brandmauer mit Splayer qt (letzte Version von Ihnen), und Splayer 4.3 (alte Version). Ich wiederhole dieses Problem jedes Mal in jeder Konfiguration.
Bitte helfen Sie mir, dieses Problem zu beheben. Wir brauchen eine ständige Zeitverzögerung beim Splayer-Spielen, die nicht mehr als betragen darf 350 ms.

Antworten: Ein solches Problem sollte nicht auftreten, weil der Player im Low-Latency-Modus keinen Cache hat, und die Verzögerung hängt vollständig von der Dekodierungsfähigkeit des PCs ab. Ingenieure werden die Umgebung einrichten und am nächsten Montag testen.

Ein weiterer Punkt besteht darin, Kunden zu bitten, die Bildwiederholfrequenzeinstellung ihres Laptop-Monitors zu überprüfen. Beispielsweise, wenn die Kamera 1080p60 eingibt, dann muss die Bildwiederholfrequenz des Laptop-Monitors des Kunden ebenfalls 60 Hz betragen. Andernfalls, Die Anzeige wird zu langsam sein, Dies führt ebenfalls zu Datenstaus und Verzögerungen.

Der Slayer-Spieler hat eine große Verzögerung, Entweder ist die Dekodierung langsam oder die Anzeige ist langsam, Es wird alles vom PC verursacht.

HDMI-Kamera-Kodierung, HDMI-Empfänger-Dekodierung, Ausgabe auf dem Display, und Computer-Wiedergabeverzögerungstest des Splayer-Players

Wir finden das von Ihnen erwähnte Problem nicht.

Es ist ersichtlich, dass der aktuelle Bildschirm des Splayer-Players und der HDMI-Ausgang des Empfängers konsistent sind, und die Verzögerung zwischen ihnen ist sehr gering.

Könnten Sie bitte den Kunden fragen?, Wie hoch ist die Auflösung und Bildrate des Kameraeingangs?? Vorausgesetzt, die Kamera des Kunden ist 1080p60, Sie können auch die folgenden zwei Schritte ausführen, um das Problem weiter zu beheben:

1. Lassen Sie den Kunden die Kamera zum Testen auf eine niedrigere Bildrate umstellen, wie 1080p50/30;
2. Sie können die Parameter des Kodierungssegments so festlegen, dass die Frame-Kodierung heruntergefahren wird. Beispielsweise, Senden Sie den Befehl ATSO0,30_ über den Parameterport, und die Codierung gibt zum Testen 1080p30 aus.

Hinweis:

1. Splayer is specifically developed for our proprietary/custom streaming protocol and currently does not support parsing or playback of standard MPEG-TS protocols.
2. Splayer is currently available only on Windows. Linux and Android versions have not been developed yet and are not supported at this stage.
3. In Ergänzung, it is not the mpeg-ts protocol that causes the delay to increase. Even if it is switched to our custom protocol, the delay will not be reduced (our custom protocol mainly performs CRC checks on all data packets, while the mpeg-ts protocol does not, which is the biggest difference between the protocols). The biggest impact on latency is the processing of video decoding and display in the player. Our own player Splayer will be optimized for image transmission application scenarios.
4. Even if the customer gets our demux library and extracts the audio and video streams, it still has to do the video decoding and display by itself. This ordinary customer does not have this ability. Most customers will only use open source players (such as based on gstreamer), and the video delay of these open source players will not be good. If you want good video delay, you basically have to develop your own player.
5. If the customer insists on the demux library and says that he has the ability to deal with the subsequent video decoding and playback, I can also cooperate with you (but we only provide the demux library and routines under Linux/android, and do not provide subsequent decoding and display-related support)
6. Our custom protocol mainly enhances CRC verification to better handle transmission errors, which helps prevent unexpected video decoding issues or even player crashes caused by corrupted data packets. The demuxing protocol itself does not introduce significant latency, whether it is our custom protocol or the standard MPEG-TS protocol. The main factors affecting latency are actually the decoding and rendering stages afterward. Im Allgemeinen:
   • Since UDP streaming and player decoding/rendering are asynchronous processes, most players introduce a certain amount of buffering before starting playback. The larger the buffer, the higher the latency.
     Beispielsweise, VLC media player typically uses relatively large buffering, and its buffer size may even increase dynamically during playback. Im Gegensatz, 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. 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.
   • In Ergänzung, our custom protocol is designed specifically for low-latency and high-reliability transmission scenarios, allowing tighter optimization across the entire transmission and playback pipeline compared with a general-purpose standard protocol.

Relativ

1. Möchten Sie die UART-Daten von der HDMI-CVBS-Video-UART-DATA-Encoderplatine erhalten??
2. UDP Player SDK mit geringer Latenz für Windows x64

Q: Unterstützt das System Multicast?? Kann ich einen Stream an mehrere IPs ausgeben??

EIN: Ja. The system supports UDP multicast, allowing one stream to be delivered to multiple receivers simultaneously without duplicating the stream per IP.To use multicast, Stellen Sie die einRemote-IP on the sender side to a multicast address, zum Beispiel224.0.0.23. All receivers join the same multicast group using the same address. Auf der Empfängerseite, configure the same multicast IP:

• Splayer: set Group IP to224.0.0.23
• VLC: offenudp://@224.0.0.23:8090

Multicast enables one-to-many streaming within the same network. The actual device IP is not critical; stattdessen, delivery depends on network multicast support and devices joining the same group.Hinweis: Network conditions may affect performance. Environments with VPNs, virtual machines, multiple network adapters, or switches without IGMP support may impact multicast reception.

Multicast

Unicast

Q: If there are multiple encoder multicast boards in the same network, should we change the port on each board to avoid conflict?

EIN: Nicht unbedingt. There are two valid ways to ensure that multiple encoder streams do not conflict on the same network:

1. Use different UDP multicast IP addresses for each encoder stream.
2. Use different UDP port numbers for each encoder stream.

UDP streaming is distinguished by the combination of IP Adresse (unicast or multicast) und port number. Zusammen, they define a unique UDP stream identity on the network.

On the encoder board, das UDP Stream settings einschließen:

• Remote-IP: Defines the destination IP address (if a multicast address is used, the stream becomes a UDP multicast stream).
• Tx Port: Defines the transmission port number.

Die Kombination von Remote-IP + Tx Port 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?

EIN: Multicast IP addresses are not automatically assigned; they are selected from the standard multicast range 224.0.0.0 nach 239.255.255.255. In der Praxis, 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. How can we play or switch between them?

EIN: When HDMI and AV streams are transmitted over the same UDP address, they are typically not separated by network ports, aber durch internal stream identifiers, similar to an MPEG-TS (Transport Stream) Struktur.

Wie es funktioniert

• Both HDMI and AV inputs are multiplexed into a single UDP stream
• Each video source is assigned a unique stream ID (z.B., PID / service ID)
• The receiver performs demultiplexing based on these IDs, rather than separating by IP or port
• This allows multiple video channels to coexist in one UDP stream

How Splayer handles this

Mit unserer Splayer 2.0 UDP-Player, the system supports this architecture natively:

• Simultaneous decoding of multiple video streams from a single UDP address
• Stream separation based on internal IDs (MPEG-TS PID/service mapping)
• Real-time switching between HDMI and AV sources without changing network settings
• Flexible multi-channel playback using a single UDP input source

This design simplifies deployment by keeping one UDP configuration, while still enabling multi-input video handling and seamless switching.

You can download Splayer 2.0 UDP-Player Hier: Splayer 2.0 UDP Player Download