Оглавление
Настройка проигрывателя UDP Stream на беспроводном видеопередатчике и приемнике COFDM HDMI
Проигрыватель потоков UDP — лучшее решение для аналогового видеокодера CVBS с минимальной задержкой.. Беспроводной видеоприемник COFDM Vcan1776-RX. Прошивка по умолчанию поддерживает RTSP-плеер.. Некоторым клиентам необходимо использовать протокол UDP..
IP-адрес и номер порта можно настроить на веб-странице., HTTP://192.168.0.215 (по умолчанию)
- После обновления прошивки, принимающая сторона восстановит заводские параметры по умолчанию (центральная частота: 320МГц, ширина полосы беспроводного доступа: 6МГц, IP-адрес сетевого порта: 192.168.0.215), клиентам необходимо изменить центральную частоту и полосу пропускания через Инструмент для настройки параметров, и передатчик постоянно сохраняет.
- Клиент получает доступ к веб-серверу получателя через веб-страницу. (HTTP://192.168.0.215), и изменяет свой собственный IP-адрес и настройку IP-адреса ПК с Windows, подключенного к приемнику:
Заметка: Среди них, локальный IP-адрес — это собственный IP-адрес получателя, а удаленный IP-адрес — это конечный IP-адрес док-станции с Windows-компьютером.. Клиент может настроить его в соответствии со своей реальной ситуацией.. Обратите внимание, что изменение вступит в силу только после перезапуска ресивера..
Загрузите UDP-плеер Сплейер
- Загрузите 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
- Сплейер_v4.3.1_2024.4.16
- https://drive.google.com/file/d/1uv7GqP8P4r6qGOWJ5gYn0b8bZ4ptL8H6/view?usp=drive_link
- Спплеер_QT_V1.0 для Вин10 или Вин11
- https://drive.google.com/file/d/1VAegQjd-PmIL2XbJf7K8dnujMxhoIuhd/view?usp=drive_link
- Сплейер_QT_V1.1.1 для Вин10 или Вин11
- 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
- Откройте проигрыватель Splayer на ПК с Windows., нажмите кнопку настройки в правом нижнем углу, и появится страница настроек:
Заметка:
- Видно, что номер порта порта установлен на 1234, который жестко запрограммирован программой потоковой передачи UDP получателя и не может быть изменен;
- В столбце Декодирование, настроить в соответствии с текущими свойствами видеопотока, например, конфигурация видеопотока H264 с малой задержкой, как указано выше.;
- После установки и нажатия кнопки “Подтверждать” кнопка для сохранения параметров, нажмите кнопку воспроизведения в левом нижнем углу. После того, как ПК с Windows получит push-поток UDP, он немедленно раскодирует и воспроизведет.

Вышеуказанная настройка проигрывателя потока UDP подходит для указанной ниже модели..
Как он поддерживает проигрыватель Linux VLC? Воспроизведение потока с низкой задержкой под Linux?
Вопрос: Теперь поток UDP не воспроизводится с помощью проигрывателя VLC.. Мне нужно воспроизвести этот UDP-поток под Linux, и я пытаюсь понять детали этого потока.. Любые сценарии, ключи или другие вещи?
Хочу сделать свой плеер под Linux и хочу разобраться в деталях этого UDP видеопотока с демодулятора.
Если это обычный видеопоток UDP, тогда спросите, почему он не работает со студией VLC или OBS..
Ответ: Для модели Vcan1726-RX, У нас есть две прошивки на выбор, Первая прошивка для RTSP-плеера с поддержкой VLC-плеера, но некоторые клиенты отметили, что у него большая задержка, вот мы и сделали вторую прошивку, UDP-трансляция на Splayer, который поддерживает более низкую задержку.
Этот аудио- и видеопоток UDP является нашим собственным форматом., поэтому VLC не может это объяснить. Если ваш клиент хочет открыть собственный плеер (под Linux), на данный момент есть два варианта:
- Обновление доступа к потоку RTSP по умолчанию. (первая прошивка для RTSP плеера)
- Мы предоставляем соответствующую библиотеку DEMUX и процедуры. (нам необходимо понять среду Linux клиента, чтобы скомпилировать подходящий файл библиотеки)
- Это “Библиотека и процедуры DEMUX” написано нашими инженерами под Ubuntu 14.04 64битовая система
Второй тип слишком сложен для обычных клиентов., и мы не знаем возможностей разработки собственного плеера вашего заказчика.
Поскольку некоторые клиенты сталкиваются с проблемой низкой задержки в проигрывателе VLC ОС Windows., как бы мы здесь ни тестировали, мы не нашли этой проблемы. В это время, вы использовали 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-адрес сервера, а порт — номер порта потока.. Например, UDP://@ 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
Идентификатор сбойного процесса: 0х3888
Неверное время запуска приложения: 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 сек, что неприемлемо в клиентском приложении.
Вчера сам проверял на Win 10, и Win11 на разных ПК при комплексном отключении Win Brandmauer со Splayer qt (последняя версия от тебя), и Сплейер 4.3 (старая версия). Повторяю эту проблему каждый раз в любой конфигурации.
Пожалуйста, помогите мне решить эту проблему. Нам нужна постоянная задержка во времени от воспроизведения Splayer, которая может быть не более 350 мс.
Ответ: Такая проблема не должна возникать, потому что у плеера нет кеша в режиме с низкой задержкой, а задержка полностью зависит от возможностей декодирования ПК. Инженеры настроят среду и протестируют ее в следующий понедельник..
Еще один момент — попросить клиентов проверить настройку частоты обновления монитора их ноутбука.. Например, если камера вводит 1080p60, тогда частота обновления монитора ноутбука клиента также должна быть 60Гц. В противном случае, дисплей будет слишком медленным, что также приведет к перегрузке данных и задержкам.
У игрока Slayer большая задержка, либо декодирование медленное, либо дисплей медленный, это все из-за ПК.
Кодирование камеры HDMI Декодирование приемника HDMI, вывод на дисплей, и компьютерный тест задержки воспроизведения проигрывателя Splayer


Мы не находим указанную вами проблему.
Видно, что текущий экран проигрывателя Splayer и выход HDMI ресивера совпадают., и задержка между ними очень мала.
Не могли бы вы спросить клиента, каково разрешение и частота кадров на входе камеры? Предполагая, что камера клиента имеет разрешение 1080p60., вы также можете выполнить следующие два шага для дальнейшего устранения проблемы.:
- Позвольте клиенту изменить камеру на более низкую частоту кадров для тестирования., например 1080p50/30;
- Вы можете установить параметры сегмента кодирования, чтобы разрешить кодирование с понижением частоты кадров.. Например, отправьте команду ATSO0,30_ через порт параметров, и кодирование выводит 1080p30 для тестирования.
Заметка:
- Splayer is specifically developed for our proprietary/custom streaming protocol and currently does not support parsing or playback of standard MPEG-TS protocols.
- Splayer is currently available only on Windows. Linux and Android versions have not been developed yet and are not supported at this stage.
- К тому же, 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.
- 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.
- 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)
- 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.
- 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.
- 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.
Родственник
- Хотите ли вы получить данные UART с платы кодера HDMI CVBS Video UART DATA??
- SDK UDP-плеера с низкой задержкой для Windows x64
Q: Поддерживает ли система многоадресную рассылку? Могу ли я вывести один поток на несколько IP-адресов??
А: да. The system supports UDP multicast, allowing one stream to be delivered to multiple receivers simultaneously without duplicating the stream per IP.To use multicast, установитьУдаленный IP-адрес on the sender side to a multicast address, например224.0.0.23. All receivers join the same multicast group using the same address. На стороне получателя, configure the same multicast IP:
- Сплейер: set Group IP to
224.0.0.23 - VLC: открыть
udp://@224.0.0.23:8090
Multicast enables one-to-many streaming within the same network. The actual device IP is not critical; вместо, delivery depends on network multicast support and devices joining the same group.Заметка: Network conditions may affect performance. Environments with VPNs, virtual machines, multiple network adapters, or switches without IGMP support may impact multicast reception.
Мультикаст


Одноадресная передача


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:
- Use different UDP multicast IP addresses for each encoder stream.
- Use different UDP port numbers for each encoder stream.
UDP streaming is distinguished by the combination of айпи адрес (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.



Задайте вопрос
Спасибо за ответ! ✨