Splayer UDP stream player setting for stream protocol of COFDM Receiver Vcan1776-RX

Настройка на UDP Stream плейър на безжичния видео предавател и приемник COFDM HDMI

UDP поточен плейър е най-доброто решение за CVBS аналогов видео енкодер с най-ниска латентност. Фърмуерът по подразбиране на COFDM безжичен видео приемник Vcan1776-RX поддържа RTSP плейър. Някои клиенти трябва да използват UDP протокола.

IP адресът и номерът на порта могат да бъдат конфигурирани на уеб страницата, HTTP://192.168.0.215 (по подразбиране)

Splayer UDP stream player setting for stream protocol of COFDM Receiver Vcan1776-RX 1
  1. След надграждане на фърмуера, приемащата страна ще възстанови фабричните параметри по подразбиране (централна честота: 320MHz, безжичните връзки: 6MHz, IP адрес на мрежов порт: 192.168.0.215), клиентите трябва да променят централната честота и честотната лента през Инструмент за платка за конфигуриране на параметри, и предавателят запазва последователно.
  1. Клиентът осъществява достъп до уеб сървъра на приемника през уеб страницата (HTTP://192.168.0.215), и променя собствения си IP адрес и настройката на IP адреса на компютъра с Windows, свързан към приемника:

Забележка: Между тях, локалният IP е собственият IP на получателя, и отдалеченият IP е крайният IP адрес на докинг компютър с Windows. Клиентът може да го конфигурира според реалната си ситуация. Имайте предвид, че промяната ще влезе в сила само след рестартиране на приемника.

Изтеглете UDP плейъра Плейър

  1. Изтеглете UDP плейъра Плейър.
  2. Отворете плейъра Splayer на компютър с Windows, щракнете върху бутона за настройка в долния десен ъгъл, и страницата за настройка ще изскочи:
Splayer UDP stream player setting for stream protocol of COFDM Receiver Vcan1776-RX 2

Забележка:

  1. Може да се види, че номерът на порта на порта е зададен на 1234, който е твърдо кодиран от UDP стрийминг програмата на приемника и не може да бъде модифициран;
  2. В колоната Декодиране, конфигурирайте според текущите свойства на видеопотока, като H264 конфигурация на видео поток с ниска латентност, както по-горе;
  1. След като зададете и щракнете върху “Потвърдете” бутон за запазване на параметрите, щракнете върху бутона за възпроизвеждане в долния ляв ъгъл. След като компютърът с Windows получи UDP push потока, той ще декодира и ще се възпроизведе веднага.
UDP stream player setting for wireless video transmitter and receiver
Настройка на UDP поточен плейър за безжичен видео предавател и приемник

Горната настройка на UDP поточен плейър е подходяща за модела по-долу.

Как поддържа Linux VLC плейър? Възпроизвеждане на поток с ниско забавяне под Linux?

въпрос: Сега UDP потокът не се възпроизвежда с VLC плейъра. Трябва да пусна този UDP поток под Linux и се опитвам да разбера подробностите за този поток. Всякакви скриптове или ключове или други неща?

Искам да направя свой собствен плейър под Linux и искам да разбера подробностите за този UDP видео поток от демодулатора.

Ако това е обикновен UDP видео поток, след това попитайте защо не се възпроизвежда с VLC или OBS студио.

Отговор: За модел Vcan1726-RX, Имаме два фърмуера за избор, Първият фърмуер за RTSP плейър поддържа VLC плейър, но някои клиенти споменаха, че има дълга латентност, така че направихме втория фърмуер, UDP излъчване в Splayer, който поддържа по-ниска латентност.

Този UDP аудио и видео поток е нашия персонализиран формат, така че VLC не може да го обясни. Ако вашият клиент иска да отвори свой собствен плейър (под Linux), в момента има два варианта:

  1. Актуализирайте до стандартния RTSP достъп до потоци (първи фърмуер за RTSP плейър)
  2. Ние предоставяме съответната библиотека DEMUX и процедури (трябва да разберем Linux средата на клиента, за да компилираме подходящ библиотечен файл)
  3. Това е “DEMUX библиотека и рутинни процедури” написани от нашите инженери под Ubuntu 14.04 64битова система

Вторият тип е твърде труден за обикновените клиенти, и ние не знаем възможностите за разработка на собствения играч на вашия клиент.

Тъй като някои клиенти се сблъскват с проблема с ниска латентност при VLC плейъра на Windows OS, без значение как тествахме тук, не открихме този проблем. По това време, използвахте Windows за тестване. Може би, ако беше сменен на Linux, няма да има проблем с RTSP стрийминг. Моля, опитайте да тествате пробата Vcan1726 с първата версия на фърмуера на Linux. Може би това не е проблем на Linux OS.

въпрос: Можете ли да създадете докер изображение за това приложение? Кой порт се използва за входящия поток, и друг порт за изходящия поток с някои широко използвани кодеци (h264)?

Какво представляват Splayer и UDP Stream Player?

SPlayer е медиен плейър, който поддържа различни видео формати, включително UDP стрийминг.

UDP стрийминг е метод за изпращане на видео данни по интернет с помощта на протокола за потребителска дейтаграма (UDP), който е бърз и лесен протокол, който не гарантира доставка или поръчка на пакетите.

UDP стрийминг може да се използва за видео излъчване на живо или видео предаване с ниска латентност, но може също да страда от загуба на пакети или повреда.

Според резултатите от търсенето в мрежата, SPlayer може да възпроизвежда UDP потоци, като използва следните стъпки:

  • Отворете SPlayer и щракнете върху “Отворете URL” бутон в горния десен ъгъл.
  • Въведете URL адреса на UDP потока във формат udp://@ip: порт, където ip е IP адресът на сървъра, а портът е номерът на порта на потока. Например, udp://@224.0.0.1:1234.
  • Кликнете върху “Добре” и изчакайте потокът да се зареди.

Как Splayer работи добре за Win10?

въпрос: Не можем да стартираме Splayer 4.2 и 4.3 под Windows 10. Бихте ли ни предоставили правилната версия на Splayer за Windows 10 и 11?

4.2 започва и затваря в момента. 4.3 започва със съобщението за грешка.

Име на неизправно приложение: Splayer.exe, версия: 1.0.0.1, времеви печат: 0x646d83e2
Име на повреден модул: dvb_demux.dll, версия: 1.0.0.1, времеви печат: 0x5fe5bdbf
Код на изключение: 0xc0000005
Отместване на грешката: 0x0001484a
Идентификатор на процес с грешка: 0x3888
Начален час на неизправно приложение: 0x01da1164b89c78eb
Грешен път на приложение: ° С:\ПотребителиadminDownloadsSplayer_v4.3_2022.10.22Splayer.exe
Път на повреден модул: ° С:\ПотребителиadminDownloadsSplayer_v4.3_2022.10.22dvb_demux.dll
Идент. № на отчета: 4af19407-045e-48e5-a0f7-86fc90c6b3d3
Пълно име на пакет с грешка:
Идентификатор на приложение, свързан с дефектен пакет:

Отговор: Моля, опитайте да използвате нашия Splayer_qt_v1.0.zip (103.5Mb).

Обратна връзка: Новата версия на 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, тогава честотата на опресняване на монитора на лаптопа на клиента също трябва да бъде 60Hz. В противен случай, дисплеят ще бъде твърде бавен, което също ще доведе до претоварване на данни и ще доведе до забавяния.

Играчът Slayer има голямо забавяне, или декодирането е бавно, или дисплеят е бавен, всичко е причинено от компютъра.

Кодиране на HDMI камера Декодиране на HDMI приемник, изход към дисплея, и компютърен тест за забавяне на възпроизвеждането на плейъра Splayer

Splayer UDP stream player setting for stream protocol of COFDM Receiver Vcan1776-RX 3
Splayer UDP stream player setting for stream protocol of COFDM Receiver Vcan1776-RX 4

Не откриваме проблема, който споменахте.

Може да се види, че текущият екран на плейъра на Splayer и 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. 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.
    • В допълнение, 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 данни от HDMI CVBS Video UART DATA енкодер платка?
  2. SDK за UDP Player с ниска латентност за Windows x64

Задай въпрос

← Назад

Вашето съобщение е изпратено