Налада струменевага прайгравальніка UDP Splayer для пратаколу струменевага прыёмніка COFDM Vcan1776-RX

Налада плэера UDP Stream на перадатчыку і прымачы відэа COFDM HDMI Wireless

Прайгравальнік патокаў UDP - лепшае рашэнне для аналагавага кадавальніка CVBS з найменшай затрымкай. Прашыўка па змаўчанні бесправаднога відэапрыёмніка COFDM Vcan1776-RX падтрымлівае прайгравальнік RTSP. Некаторым кліентам неабходна выкарыстоўваць пратакол UDP.

IP-адрас і нумар порта можна наладзіць на вэб-старонцы, HTTP://192.168.0.215 (дэфолт)

1. Пасля абнаўлення прашыўкі, прымаючы бок адновіць заводскія параметры па змаўчанні (цэнтральная частата: 320МГц, шырыня паласы бесправаднога доступу: 6МГц, IP-адрас сеткавага порта: 192.168.0.215), кліентам неабходна змяніць цэнтральную частату і прапускную здольнасць праз Інструмент платы канфігурацыі параметраў, і Transmitter захоўвае паслядоўна.

2. Кліент атрымлівае доступ да вэб-сервера прымача праз вэб-старонку (HTTP://192.168.0.215), і змяняе свой уласны IP-адрас і настройку IP-адраса ПК з Windows, падлучанага да прымача:

Нататка: Сярод іх, лакальны IP - гэта ўласны IP атрымальніка, а аддалены IP - гэта канчатковы IP-адрас для ПК з Windows. Кліент можа наладзіць яго ў адпаведнасці са сваёй рэальнай сітуацыяй. Звярніце ўвагу, што мадыфікацыя ўступіць у сілу толькі пасля перазапуску рэсівера.

Спампаваць UDP плэер Плэер

3. Спампаваць UDP плэер Плэер.
   • 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 для Win10 або Win11
   • https://drive.google.com/file/d/1VAegQjd-PmIL2XbJf7K8dnujMxhoIuhd/view?usp=drive_link
   • Splayer_QT_V1.1.1 для Win10 або 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. Адкрыйце прайгравальнік Splayer на ПК з Windows, націсніце кнопку налады ў правым ніжнім куце, і з'явіцца старонка налад:

Нататка:

1. Відаць, што нумар порта Port усталяваны на 1234, які жорстка закадзіраваны праграмай струменевай перадачы UDP прымача і не можа быць зменены;
2. У слупку Расшыфроўка, наладзіць у адпаведнасці з бягучымі ўласцівасцямі відэапатоку, напрыклад, канфігурацыя патоку відэа з нізкай затрымкай H264, як паказана вышэй;

4. Пасля ўстаноўкі і націску “Пацвердзіць” кнопку для захавання параметраў, націсніце кнопку прайгравання ў левым ніжнім куце. Пасля таго, як ПК з Windows атрымае націскны паток UDP, ён будзе дэкадзіраваць і прайграць неадкладна.

Прыведзеная вышэй налада прайгравальніка патоку UDP падыходзіць для мадэлі ніжэй.

Як ён падтрымлівае плэер Linux VLC? Прайграванне патоку з нізкай затрымкай пад Linux?

пытанне: Цяпер паток UDP не прайграваецца з прайгравальнікам VLC. Мне трэба прайграць гэты паток UDP пад Linux, і я спрабую зразумець дэталі гэтага патоку. Любыя скрыпты, ключы ці іншыя рэчы?

Я хачу зрабіць свой уласны прайгравальнік пад Linux і хачу зразумець дэталі гэтага UDP-відэапатоку з дэмадулятара.

Калі гэта звычайны відэаструмень UDP, затым задайце пытанне, чаму ён не гуляе з VLC або OBS studio.

адказ: Для мадэлі Vcan1726-RX, У нас ёсць дзве прашыўкі па жаданні, Першая прашыўка для прайгравальніка RTSP падтрымлівае прайгравальнік VLC, але некаторыя кліенты адзначылі, што ў яго доўгая затрымка, таму мы зрабілі другую прашыўку, Трансляцыя UDP на Splayer, які падтрымлівае меншую затрымку.

Гэты аўдыя- і відэаплынь UDP - наш карыстальніцкі фармат, таму VLC не можа растлумачыць гэта. Калі ваш кліент хоча адкрыць свой уласны плэер (пад Linux), у цяперашні час ёсць два варыянты:

1. Абнавіце стандартны доступ да патоку RTSP (першая прашыўка для прайгравальніка rtsp)
2. Мы прапануем адпаведную бібліятэку DEMUX і працэдуры (нам трэба разумець асяроддзе Linux заказчыка, каб скампіляваць прыдатны файл бібліятэкі)
3. Гэта “Бібліятэка і працэдуры DEMUX” напісаны нашымі інжынерамі пад Ubuntu 14.04 64разрадная сістэма

Другі тып занадта складаны для звычайных кліентаў, і мы не ведаем магчымасці распрацоўкі ўласнага прайгравальніка вашага кліента.

Таму што некаторыя кліенты сутыкаюцца з праблемай нізкай затрымкі ў плэеры Windows OS VLC, незалежна ад таго, як мы правяралі тут, мы не знайшлі гэтай праблемы. У той час, вы выкарыстоўвалі Windows для тэставання. Магчыма, калі б яго змянілі на Linux, не было б праблем з трансляцыяй RTSP. Калі ласка, паспрабуйце праверыць узор Vcan1726 з першай версіяй прашыўкі на Linux. Магчыма, гэта не праблема ў АС Linux.

пытанне: Ці можаце вы стварыць вобраз докера для гэтага прыкладання? Які порт выкарыстоўваецца для ўваходнага патоку, і іншы порт для выходнага патоку з некаторымі шырока выкарыстоўванымі кодэкамі (h264)?

Што такое Splayer і UDP Stream Player?

SPlayer - гэта медыяплэер, які падтрымлівае розныя фарматы відэа, у тым ліку паток UDP.

Паток па UDP - гэта метад адпраўкі відэададзеных праз Інтэрнэт з выкарыстаннем пратакола датаграм карыстальніка (UDP), гэта хуткі і просты пратакол, які не гарантуе дастаўку або заказ пакетаў.

Паток UDP можна выкарыстоўваць для трансляцыі відэа ў прамым эфіры або перадачы відэа з нізкай затрымкай, але ён таксама можа пакутаваць ад страты або пашкоджання пакетаў.

Па выніках вэб-пошуку, SPlayer можа прайграваць патокі UDP, выканаўшы наступныя дзеянні:

• Адкрыйце SPlayer і націсніце на “Адкрыць URL” кнопка ў правым верхнім куце.
• Увядзіце URL патоку UDP у фармаце udp://@IP: порт, дзе ip - IP-адрас сервера, а порт - нумар порта патоку. Напрыклад, адп://@224.0.0.1:1234.
• Націсніце на “добра” кнопку і дачакайцеся загрузкі патоку.

Як добра працуе Splayer для Win10?

пытанне: Мы не можам запусціць Splayer 4.2 і 4.3 пад Windows 10. Не маглі б вы даць нам правільную версію Splayer для Windows 10 і 11?

4.2 пачынаецца і зачыняецца ў дадзены момант. 4.3 пачынаецца з паведамлення пра памылку.

Няспраўнае імя прыкладання: Прайгравальнік.exe, версія: 1.0.0.1, пазнака часу: 0x646d83e2
Назва няспраўнага модуля: dvb_demux.dll, версія: 1.0.0.1, пазнака часу: 0x5fe5bdbf
Код выключэння: 0xc0000005
Зрушэнне віны: 0x0001484a
Ідэнтыфікатар няспраўнага працэсу: 0x3888
Няспраўны час запуску прыкладання: 0x01da1164b89c78eb
Памылковы шлях прыкладання: З:\КарыстальнікіадміністратараСпампоўкіSplayer_v4.3_2022.10.22Splayer.exe
Няспраўны шлях модуля: З:\КарыстальнікіадміністратараСпампоўкіSplayer_v4.3_2022.10.22dvb_demux.dll
Ідэнтыфікатар справаздачы: 4af19407-045e-48e5-a0f7-86fc90c6b3d3
Поўнае імя пакета з памылкай:
Няспраўны ідэнтыфікатар адносна пакета:

адказ: Калі ласка, паспрабуйце выкарыстоўваць наш Splayer_qt_v1.0.zip (103.5Мб).

зваротная сувязь: Новая версія SPlayer добра працуе на праблемным сайце з Win 10! Дзякуй!

пытанне: Мы выявілі, што затрымка павялічваецца падчас прайгравання відэа з праграмы Reciver by Splayer (Паток UDP).

Калі гаварыць падрабязна – Прыёмнік падключаецца з дапамогай кабеля Ethernet непасрэдна да ПК. ПК і прыёмнік знаходзяцца ў адной лакальнай сетцы. Калі мы запускаем Splayer, затрымка часу нармальная, і дакладны падлік паказвае нам 330 мс, што крыху больш, чым адзін выхад HDMI, дзе мы назіралі 270 мс. Гэта добра. Але калі мы пачакаем некалькі хвілін без якіх-небудзь змен на працоўным месцы, мы назіраем бесперапыннае павелічэнне часу затрымкі, якое дасягае 1-1,5 sec, што непрымальна ў дадатку кліента.
Учора сам тэставаў на Win 10, і Win11 на розных ПК са складаным адключэннем Win Brandmauer з Splayer qt (апошняя версія ад вас), і Splayer 4.3 (старая версія). Я паўтараю гэтую праблему кожны раз у любой канфігурацыі.
Калі ласка, дапамажыце мне вырашыць гэтую праблему. Нам патрэбна пастаянная затрымка часу ад прайгравання Splayer, якая можа быць не больш чым 350 мс.

адказ: Такая праблема паўстаць не павінна, таму што ў прайгравальніка няма кэша ў рэжыме нізкай затрымкі, і затрымка цалкам залежыць ад здольнасці дэкадавання ПК. Інжынеры наладзяць асяроддзе і выпрабуюць яго ў наступны панядзелак.

Іншы момант - папрасіць кліентаў праверыць наладу частаты абнаўлення манітора ноўтбука. Напрыклад, калі камера ўводзіць 1080p60, тады частата абнаўлення манітора ноўтбука кліента таксама павінна быць 60 Гц. у адваротным выпадку, дысплей будзе занадта павольным, што таксама прывядзе да перагрузкі дадзеных і ўнясе затрымкі.

Гулец Slayer мае вялікую затрымку, Альбо дэкадаванне павольнае, альбо дысплей павольны, усё гэта выклікана ПК.

HDMI камера, якая кадуе дэкадаванне прыёмніка HDMI, выхад на дысплей, і тэст затрымкі прайгравання камп'ютэраў прайгравальніка прайгравальніка

Мы не знаходзім праблему, якую вы згадалі.

Відаць, што бягучы экран прайгравальніка і выхад HDMI прыёмніка адпавядае, і затрымка паміж імі вельмі нізкая.

Не маглі б вы спытаць кліента, Што такое дазвол і частата кадраў уводу камеры? Мяркуючы, што камера кліента складае 1080p60, Вы таксама можаце зрабіць наступныя два крокі для далейшага ліквідацыі праблем:

1. Дазвольце кліенту змяніць камеру на больш нізкую частату кадраў для тэставання, напрыклад, 1080p50/30;
2. Вы можаце ўсталяваць параметры сегмента кадавання, каб падвесці кадаванне кадраў. Напрыклад, адправіць каманду ATSO0,30_ праз порт параметраў, і кадзіроўка выводзіць 1080p30 для тэставання.

Нататка:

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. У дадатак, 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. Увогуле:
   • 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.
     Напрыклад, VLC media player typically uses relatively large buffering, and its buffer size may even increase dynamically during playback. У адрозненне, 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. Акрамя відэа і аўдыё, 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.
   • У дадатак, 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.

Адносны

1. Хочаце атрымаць даныя UART з платы кадавальніка DATA Video UART HDMI CVBS??
2. SDK UDP Player з нізкай затрымкай для Windows x64

Q: Ці падтрымлівае сістэма multicast? Ці магу я вывесці адзін паток на некалькі IP?

А: ды. Сістэма падтрымлівае UDP multicast, allowing one stream to be delivered to multiple receivers simultaneously without duplicating the stream per IP.Для выкарыстання шматадраснай перадачы, ўсталявацьАддалены IP на баку адпраўніка на шматадрасны адрас, напрыклад224.0.0.23. Усе атрымальнікі далучаюцца да адной групы шматадраснай перадачы, выкарыстоўваючы адзін і той жа адрас. На баку ствольнай скрынкі, наладзіць той жа шматадрасны IP:

• Плэер: усталяваць IP групы224.0.0.23
• VLC: адкрытыudp://@224.0.0.23:8090

Шматадрасная перадача дазваляе струменевую перадачу "адзін да многіх" у адной сетцы. Фактычны IP прылады не з'яўляецца крытычным; замест гэтага, delivery depends on network multicast support and devices joining the same group.Нататка: Умовы сеткі могуць паўплываць на прадукцыйнасць. Асяроддзі з VPN, віртуальныя машыны, некалькі сеткавых адаптараў, або камутатары без падтрымкі IGMP могуць паўплываць на шматадрасны прыём.

Мультыкаст

Аднакастная

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

А: Не абавязкова. 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-адрас (unicast or multicast) і port number. Разам, they define a unique UDP stream identity on the network.

On the encoder board, ў UDP Stream settings ўключаюць:

• Аддалены 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.

Спалучэнне Аддалены 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?

А: Multicast IP addresses are not automatically assigned; they are selected from the standard multicast range 224.0.0.0 у 239.255.255.255. На практыцы, 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?

А: When HDMI and AV streams are transmitted over the same UDP address, they are typically not separated by network ports, але па internal stream identifiers, similar to an MPEG-TS (транспартны паток) структура.

Як гэта працуе

• Both HDMI and AV inputs are multiplexed into a single UDP stream
• Each video source is assigned a unique stream ID (напр., 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

З нашым Плэер 2.0 Прайгравальнік UDP, 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 Плэер 2.0 Прайгравальнік UDP тут: Плэер 2.0 UDP Player Download