Ustawienia odtwarzacza strumieniowego Splayer UDP dla protokołu strumieniowego odbiornika COFDM Vcan1776-RX

Ustawienia odtwarzacza strumieniowego UDP w bezprzewodowym nadajniku i odbiorniku wideo COFDM HDMI

Odtwarzacz strumieniowy UDP to najlepsze rozwiązanie dla analogowego kodera wideo CVBS o najniższym opóźnieniu. Domyślne oprogramowanie sprzętowe bezprzewodowego odbiornika wideo COFDM Vcan1776-RX obsługuje odtwarzacz RTSP. Niektórzy klienci muszą używać protokołu UDP.

Adres IP i numer portu można skonfigurować na stronie internetowej, http://192.168.0.215 (zaniedbanie)

1. Po aktualizacji oprogramowania sprzętowego, strona odbiorcza przywróci domyślne parametry fabryczne (częstotliwość środkowa: 320MHz, przepustowość bezprzewodowej: 6MHz, adres IP portu sieciowego: 192.168.0.215), klienci muszą zmodyfikować częstotliwość środkową i szerokość pasma poprzez Narzędzie do konfiguracji parametrów, i nadajnik zapisuje konsekwentnie.

2. Klient uzyskuje dostęp do serwera WWW odbiorcy poprzez stronę internetową (HTTP://192.168.0.215), i modyfikuje swój własny adres IP oraz ustawienie adresu IP komputera PC z systemem Windows podłączonego do odbiornika:

Uwaga: Pomiędzy nimi, lokalny adres IP jest własnym adresem IP odbiorcy, a zdalny adres IP to końcowy adres IP dokującego komputera z systemem Windows. Klient może skonfigurować go zgodnie ze swoją aktualną sytuacją. Należy pamiętać, że modyfikacja zacznie obowiązywać dopiero po ponownym uruchomieniu odbiornika.

Pobierz odtwarzacz UDP Rozpylacz

3. Pobierz odtwarzacz UDP Rozpylacz.
   • 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 dla Win10 lub Win11
   • https://drive.google.com/file/d/1VAegQjd-PmIL2XbJf7K8dnujMxhoIuhd/view?usp=drive_link
   • Splayer_QT_V1.1.1 dla Win10 lub 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. Otwórz odtwarzacz Splayer na komputerze z systemem Windows, kliknij przycisk ustawień w prawym dolnym rogu, i pojawi się strona ustawień:

Uwaga:

1. Można zauważyć, że numer portu portu jest ustawiony na 1234, który jest zakodowany na stałe w programie do przesyłania strumieniowego UDP odbiornika i nie można go modyfikować;
2. W kolumnie Dekodowanie, skonfiguruj zgodnie z bieżącymi właściwościami strumienia wideo, takie jak konfiguracja strumienia wideo H264 o niskim opóźnieniu, jak powyżej;

4. Po ustawieniu i kliknięciu przycisku “Potwierdzać” przycisk, aby zapisać parametry, kliknij przycisk odtwarzania w lewym dolnym rogu. Gdy komputer z systemem Windows odbierze strumień push UDP, odszyfruje i odtworzy natychmiast.

Powyższe ustawienie odtwarzacza strumieniowego UDP jest odpowiednie dla poniższego modelu.

Jak obsługuje odtwarzacz Linux VLC? Odtwarzanie strumienia z niskim opóźnieniem pod Linuksem?

Pytanie: Teraz strumień UDP nie jest odtwarzany w odtwarzaczu VLC. Muszę odtworzyć ten strumień UDP pod Linuksem i próbuję zrozumieć szczegóły tego strumienia. Wszelkie skrypty, klucze lub inne rzeczy?

Chcę stworzyć własny odtwarzacz pod Linuksem i chcę poznać szczegóły tego strumienia wideo UDP z demodulatora.

Jeśli jest to zwykły strumień wideo UDP, następnie zapytaj, dlaczego nie działa w studiu VLC lub OBS.

Odpowiedź: Dla modelu Vcan1726-RX, Mamy dwa oprogramowanie sprzętowe opcjonalnie, Pierwsze oprogramowanie odtwarzacza RTSP obsługuje odtwarzacz VLC, ale niektórzy klienci wspomnieli, że ma duże opóźnienie, więc zrobiliśmy drugie oprogramowanie, Transmisja UDP w Splayerze, który obsługuje mniejsze opóźnienia.

Ten strumień audio i wideo UDP jest naszym niestandardowym formatem, więc VLC nie może tego wyjaśnić. Jeśli Twój klient chce otworzyć własny odtwarzacz (pod Linuksem), obecnie są dwie opcje:

1. Zaktualizuj do domyślnego dostępu do strumienia RTSP (pierwsze oprogramowanie dla odtwarzacza RTSP)
2. Udostępniamy odpowiednią bibliotekę i procedury DEMUX (musimy zrozumieć środowisko Linux klienta, aby skompilować odpowiedni plik biblioteki)
3. To jest “Biblioteka i procedury DEMUX” napisany przez naszych inżynierów w ramach Ubuntu 14.04 64systemie bitowym

Drugi typ jest zbyt trudny dla zwykłych klientów, i nie znamy możliwości rozwoju odtwarzacza Twojego klienta.

Ponieważ niektórzy klienci napotykają problem małych opóźnień w odtwarzaczu VLC systemu operacyjnego Windows, niezależnie od tego, jak tutaj testowaliśmy, nie znaleźliśmy tego problemu. W tym czasie, użyłeś systemu Windows do testowania. Może gdyby przesiadł się na Linuksa, nie byłoby problemu ze strumieniowaniem RTSP. Spróbuj przetestować próbkę Vcan1726 z pierwszą wersją oprogramowania układowego w systemie Linux. Być może nie jest to problem w systemie operacyjnym Linux.

Pytanie: Czy możesz zbudować obraz okna dokowanego dla tej aplikacji? Który port jest używany dla strumienia przychodzącego, i inny port dla strumienia wychodzącego z niektórymi powszechnie używanymi kodekami (h264)?

Czym są Splayer i odtwarzacz strumieniowy UDP?

SPlayer to odtwarzacz multimedialny obsługujący różne formaty wideo, łącznie ze strumieniowaniem UDP.

Przesyłanie strumieniowe UDP to metoda przesyłania danych wideo przez Internet przy użyciu protokołu User Datagram Protocol (UDP), który jest szybkim i prostym protokołem, który nie gwarantuje dostarczenia ani uporządkowania pakietów.

Przesyłanie strumieniowe UDP może być wykorzystywane do transmisji wideo na żywo lub transmisji wideo z niskim opóźnieniem, ale może również ucierpieć z powodu utraty pakietów lub uszkodzenia.

Według wyników wyszukiwania w Internecie, SPlayer może odtwarzać strumienie UDP, wykonując poniższe czynności:

• Otwórz SPlayer i kliknij “Otwórz URL” przycisk w prawym górnym rogu.
• Wprowadź adres URL strumienia UDP w formacie udp://@ip: Port, gdzie ip to adres IP serwera, a port to numer portu strumienia. Na przykład, udp://@224.0.0.1:1234.
• Kliknij na “ok” i poczekaj na załadowanie strumienia.

Jak Splayer działa dobrze w systemie Win10?

Pytanie: Nie możemy uruchomić Splayera 4.2 i 4.3 pod Windowsem 10. Czy możesz dostarczyć nam poprawną wersję Splayera dla Windows? 10 i 11?

4.2 zaczyna się i kończy w tej chwili. 4.3 zaczyna się od komunikatu o błędzie.

Nazwa aplikacji powodującej błąd: Splayer.exe, wersja: 1.0.0.1, znak czasu: 0x646d83e2
Nazwa modułu powodującego błąd: dvb_demux.dll, wersja: 1.0.0.1, znak czasu: 0x5fe5bdbf
Kod wyjątku: 0xc0000005
Przesunięcie błędu: 0x0001484a
Identyfikator procesu powodującego błąd: 0x3888
Czas rozpoczęcia aplikacji powodującej błąd: 0x01da1164b89c78eb
Ścieżka aplikacji powodującej błąd: do:\UsersadminDownloadsSplayer_v4.3_2022.10.22Splayer.exe
Ścieżka modułu powodującego błąd: do:\UsersadminDownloadsSplayer_v4.3_2022.10.22dvb_demux.dll
Identyfikator raportu: 4af19407-045e-48e5-a0f7-86fc90c6b3d3
Pełna nazwa pakietu powodującego błąd:
Identyfikator aplikacji związany z pakietem powodującym błąd:

Odpowiedź: Spróbuj użyć naszego Splayer_qt_v1.0.zip (103.5mb).

Informacje zwrotne: Nowa wersja SPlayera działa dobrze w miejscu problemu z Win 10! Dziękuję!

Pytanie: Stwierdziliśmy, że opóźnienie czasowe wzrasta podczas odtwarzania wideo z programu Reciver przez Splayer (Strumień UDP).

Jeśli porozmawiamy szczegółowo – Odbiornik łączy się kablem Ethernet bezpośrednio z komputerem. Komputer i odbiornik znajdują się w tej samej sieci lokalnej. Kiedy uruchamiamy Splayera, opóźnienie czasowe jest normalne i pokazuje nam to dokładna liczba 330 msek, czyli trochę więcej niż jeden z wyjścia HDMI, o którym zaobserwowaliśmy 270 msek. To jest dobre. Jeśli jednak poczekamy kilka minut bez żadnych zmian w miejscu pracy, zaobserwujemy ciągły wzrost osiąganego opóźnienia czasowego 1-1,5 sec, co jest niedopuszczalne w aplikacji klienta.
Wczoraj sam to przetestowałem na Win 10, i Win11 na różnych komputerach ze złożonym wyłączaniem Wygraj Brandmauera ze Splayer qt (ostatnia wersja od Ciebie), i Splayera 4.3 (stara wersja). Za każdym razem powtarzam ten problem w dowolnej konfiguracji.
Proszę o pomoc w rozwiązaniu tego problemu. Potrzebujemy stałego opóźnienia czasowego od gry w Splayerze, które nie może być większe niż 350 msek.

Odpowiedź: Taki problem nie powinien wystąpić, ponieważ odtwarzacz nie ma pamięci podręcznej w trybie małego opóźnienia, a opóźnienie całkowicie zależy od możliwości dekodowania komputera. Inżynierowie skonfigurują środowisko i przetestują je w najbliższy poniedziałek.

Kolejną kwestią jest poproszenie klientów o sprawdzenie ustawienia częstotliwości odświeżania monitora laptopa. Na przykład, jeśli kamera przesyła sygnał 1080p60, wówczas częstotliwość odświeżania monitora laptopa klienta musi również wynosić 60 Hz. W przeciwnym razie, wyświetlacz będzie zbyt wolny, co również spowoduje przeciążenie danych i wprowadzenie opóźnień.

Gracz Slayer ma duże opóźnienie, albo dekodowanie jest powolne, albo wyświetlanie jest wolne, wszystko jest spowodowane przez komputer.

Kodowanie kamery HDMI Dekodowanie odbiornika HDMI, wyjście na wyświetlacz, oraz test opóźnienia odtwarzania komputerowego odtwarzacza Splayer

Nie znaleźliśmy problemu, o którym wspomniałeś.

Można zauważyć, że bieżący ekran odtwarzacza Splayer i wyjście HDMI odbiornika są spójne, a opóźnienie między nimi jest bardzo małe.

Czy mógłbyś zapytać klienta, jaka jest rozdzielczość i liczba klatek na sekundę na wejściu kamery? Zakładając, że aparat klienta ma rozdzielczość 1080p60, możesz także wykonać poniższe dwa kroki, aby dokładniej rozwiązać problem:

1. Pozwól klientowi zmienić kamerę na niższą liczbę klatek na sekundę w celu przetestowania, np. 1080p50/30;
2. Możesz ustawić parametry segmentu kodowania, aby umożliwić kodowanie w dół. Na przykład, wyślij polecenie ATSO0,30_ przez port parametrów, a kodowanie wyprowadza 1080p30 do testów.

Uwaga:

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. Dodatkowo, 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. Zazwyczaj:
   • 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.
     Na przykład, VLC media player typically uses relatively large buffering, and its buffer size may even increase dynamically during playback. W przeciwieństwie do tego, 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.
   • Dodatkowo, 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.

Względny

1. Czy chcesz uzyskać dane UART z płyty enkodera HDMI CVBS Video UART DATA??
2. Zestaw SDK odtwarzacza UDP o niskim opóźnieniu dla systemu Windows x64

Q: Czy system obsługuje multiemisję?? Czy mogę wysłać jeden strumień do wielu adresów IP??

ZA: tak. The system supports UDP multicast, allowing one stream to be delivered to multiple receivers simultaneously without duplicating the stream per IP.To use multicast, ustawZdalne IP on the sender side to a multicast address, na przykład224.0.0.23. All receivers join the same multicast group using the same address. Po stronie odbiorcy, configure the same multicast IP:

• Rozpylacz: set Group IP to 224.0.0.23
• VLC: Otwarte udp://@224.0.0.23:8090

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

Multiemisja

Unicast

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

ZA: Niekoniecznie. 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 Adres IP (unicast or multicast) i port number. Razem, they define a unique UDP stream identity on the network.

On the encoder board, ten UDP Stream settings zawierać:

• Zdalne 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.

Połączenie Zdalne 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?

ZA: Multicast IP addresses are not automatically assigned; they are selected from the standard multicast range 224.0.0.0 do 239.255.255.255. W rzeczywistości, 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.