Налаштування потокового програвача Splayer UDP для протоколу потоку приймача COFDM Vcan1776-RX

Налаштування плеєра UDP Stream на відеопередавачі та приймачі COFDM HDMI Wireless

Програвач потоків UDP є найкращим рішенням для аналогового відеокодера CVBS із найменшою затримкою. Стандартне програмне забезпечення бездротового відеоприймача COFDM Vcan1776-RX підтримує програвач RTSP. Деяким клієнтам потрібно використовувати протокол UDP.

IP-адресу та номер порту можна налаштувати на веб-сторінці, http://192.168.0.215 (за замовчуванням)

1. Після оновлення прошивки, приймаюча сторона відновить заводські параметри за замовчуванням (центральна частота: 320MHz, бездротова пропускна здатність: 6MHz, 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. Можна побачити, що номер порту порту встановлено на 1234, який жорстко закодований потоковою програмою UDP приймача і не може бути змінений;
2. У колонці Декодування, налаштувати відповідно до властивостей поточного відеопотоку, наприклад конфігурація відеопотоку з низькою затримкою H264, як зазначено вище;

4. Після налаштування та натискання “Підтвердити” кнопку для збереження параметрів, натисніть кнопку відтворення в нижньому лівому куті. Після того, як ПК з Windows отримає push-потік UDP, він негайно розкодує та відтворить.

Наведене вище налаштування потокового програвача UDP підходить для наведеної нижче моделі.

Як він підтримує програвач VLC Linux? Відтворення потоку з низькою затримкою під Linux?

Question: Тепер потік 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, незалежно від того, як ми перевіряли тут, ми не знайшли цю проблему. У той час, ви використовували Windows для перевірки. Можливо, якби його змінили на Linux, не було б проблеми потокового передавання RTSP. Спробуйте протестувати зразок Vcan1726 із першою версією мікропрограми на Linux. Можливо, це не проблема в ОС Linux.

Question: Чи можете ви створити образ докера для цієї програми? Який порт використовується для вхідного потоку, і інший порт для вихідного потоку з деякими широко використовуваними кодеками (h264)?

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

SPlayer — це медіаплеєр, який підтримує різні формати відео, включаючи потокове передавання UDP.

Потокове передавання UDP — це метод надсилання відеоданих через Інтернет за допомогою протоколу дейтаграм користувача (UDP), це швидкий і простий протокол, який не гарантує доставку чи замовлення пакетів.

Потокове передавання UDP можна використовувати для трансляції відео в реальному часі або передачі відео з низькою затримкою, але він також може страждати від втрати або пошкодження пакетів.

За результатами веб-пошуку, SPlayer може відтворювати потоки UDP, виконавши такі кроки:

• Відкрийте SPlayer і натисніть на “Відкрити URL” у верхньому правому куті.
• Введіть URL-адресу потоку UDP у форматі udp://@ip: порт, де ip — IP-адреса сервера, а port — номер порту потоку. Наприклад, udp://@224.0.0.1:1234.
• Натисніть на “добре” і зачекайте, поки потік завантажиться.

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

Question: Ми не можемо запустити Splayer 4.2 and 4.3 під Windows 10. Чи можете ви надати нам правильну версію Splayer для Windows? 10 and 11?

4.2 починається і закривається в даний момент. 4.3 починається з повідомлення про помилку.

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

Відповідь: Будь ласка, спробуйте скористатися нашим Splayer_qt_v1.0.zip (103.5Mb).

Зворотній зв'язок: Нова версія SPlayer добре працює на проблемному сайті з Win 10! дякую!

Question: Ми виявили, що затримка збільшується під час відтворення відео з програми 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, вивести на дисплей, і тест затримки відтворення на комп’ютері плеєра Splayer

Ми не знаходимо зазначеної вами проблеми.

Можна побачити, що поточний екран плеєра Splayer і вихід HDMI приймача узгоджуються, і затримка між ними дуже мала.

Не могли б ви запитати клієнта, яка роздільна здатність і частота кадрів вхідного сигналу камери? Припустимо, що камера клієнта 1080p60, ви також можете виконати наступні два кроки для подальшого усунення проблеми:

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

Примітка:

1. Splayer спеціально розроблено для нашого власного/настроюваного протоколу потокової передачі й наразі не підтримує аналіз або відтворення стандартних протоколів MPEG-TS.
2. Splayer наразі доступний лише для Windows. Версії для Linux і Android ще не розроблено і на даному етапі не підтримуються.
3. In addition, це не протокол mpeg-ts, який викликає збільшення затримки. Навіть якщо він переведений на наш спеціальний протокол, затримка не зменшиться (наш спеціальний протокол в основному виконує перевірки CRC для всіх пакетів даних, а протокол mpeg-ts — ні, що є найбільшою різницею між протоколами). Найбільший вплив на затримку має обробка декодування відео та відображення в плеєрі. Наш власний програвач Splayer буде оптимізовано для прикладних сценаріїв передачі зображень.
4. Навіть якщо клієнт отримує нашу бібліотеку демультиплексорів і витягує аудіо- та відеопотоки, він все ще повинен виконувати декодування та відображення відео самостійно. Цей звичайний клієнт не має такої можливості. Більшість клієнтів використовуватимуть лише програвачі з відкритим кодом (наприклад на основі gstreamer), і затримка відео цих програвачів з відкритим кодом не буде хорошою. Якщо вам потрібна хороша затримка відео, ви, в основному, повинні розробити власного гравця.
5. Якщо замовник наполягає на бібліотеці demux і каже, що він має можливість розібратися з подальшим декодуванням і відтворенням відео, Я також можу співпрацювати з вами (але ми надаємо лише бібліотеку demux та процедури під Linux/android, і не забезпечують подальше декодування та підтримку, пов’язану з відображенням)
6. Наш спеціальний протокол в основному покращує перевірку CRC для кращої обробки помилок передачі, що допомагає запобігти неочікуваним проблемам декодування відео або навіть збоям у програвачі, спричиненим пошкодженими пакетами даних. Сам протокол демультифікації не створює значної затримки, будь то наш спеціальний протокол чи стандартний протокол MPEG-TS. Основними факторами, які впливають на затримку, є етапи декодування та рендерингу. Загалом:
   • Оскільки потокове передавання UDP і декодування/рендеринг програвача є асинхронними процесами, більшість програвачів вводять певну кількість буферизації перед початком відтворення. Чим більше буфер, тим вище затримка.
     Наприклад, Медіаплеєр VLC зазвичай використовує відносно велику буферизацію, і розмір його буфера може навіть динамічно збільшуватися під час відтворення. На противагу, Splayer навмисно підтримує дуже малий буфер відтворення, щоб мінімізувати затримку.
   • Декодування відео та рендеринг кадрів також є асинхронними процесами. Якщо візуалізація не встигає за часом, декодовані відеокадри можуть накопичуватися в черзі візуалізації, що вводить додаткову затримку, подібну до буферизації перед декодуванням. Splayer також оптимізовано в цій області, щоб зменшити накопичення кадрів і підтримувати відтворення з низькою затримкою.
7. Наш спеціальний протокол також включає кілька додаткових оптимізацій, тому ми зрештою вирішили прийняти його замість стандартного протоколу MPEG-TS (який ми спочатку використовували на початку):
   • У порівнянні зі стандартним протоколом MPEG-TS, Наш спеціальний протокол зменшує накладні витрати на резервний протокол і покращує використання пропускної здатності бездротової мережі. Це особливо важливо для бездротових каналів з обмеженою пропускною здатністю, таких як системи передачі відео COFDM.
   • Наш спеціальний протокол забезпечує більшу гнучкість для мультиплексування різних типів даних. Крім відео та аудіо, він може зручно інкапсулювати дані послідовного порту та інші визначені користувачем потоки даних, що робить його більш гнучким і легшим для розширення, ніж стандартний MPEG-TS.
   • Наш спеціальний протокол підтримує інтегроване шифрування та дешифрування AES безпосередньо на рівні протоколу. Це особливо корисно для бездротових з’єднань, які не підтримують шифрування AES, наприклад стандартні з’єднання Wi-Fi.
   • In addition, наш спеціальний протокол розроблено спеціально для сценаріїв передачі з низькою затримкою та високою надійністю, дозволяючи більш точну оптимізацію всього конвеєра передачі та відтворення порівняно зі стандартним протоколом загального призначення.

Відносна

1. Ви бажаєте отримати дані UART із плати кодера HDMI CVBS Video UART DATA?
2. Пакет SDK UDP-плеєра з низькою затримкою для Windows x64

Q: Чи підтримує система мультикаст? Чи можу я виводити один потік на кілька IP-адрес?

A: Yes. Система підтримує UDP multicast, дозволяючи доставляти один потік до кількох приймачів одночасно без дублювання потоку на IP.Для використання багатоадресної передачі, встановитиВіддалений IP на стороні відправника на багатоадресну адресу, наприклад224.0.0.23. Усі отримувачі приєднуються до однієї багатоадресної групи, використовуючи ту саму адресу. На стороні приймача, налаштувати ту саму багатоадресну IP-адресу:

• Плеєр: встановіть IP групи224.0.0.23
• VLC: ВІДЧИНЕНОudp://@224.0.0.23:8090

Групова розсилка дозволяє потокове передавання один до багатьох у межах однієї мережі. Фактична IP-адреса пристрою не є критичною; замість цього, доставка залежить від підтримки багатоадресної передачі в мережі та пристроїв, які приєднуються до однієї групи.Примітка: Умови мережі можуть впливати на продуктивність. Середовища з VPN, віртуальні машини, кілька мережевих адаптерів, або комутатори без підтримки IGMP можуть впливати на багатоадресний прийом.

Багатоадресна розсилка

Одноадресний

Q: Якщо в одній мережі є багатоканальні плати кодера, чи варто змінювати порт на кожній платі, щоб уникнути конфлікту?

A: Не обов'язково. Є два дійсні способи переконатися, що кілька потоків кодера не конфліктують в одній мережі:

1. Використовуйте різні багатоадресні IP-адреси UDP для кожного потоку кодера.
2. Використовуйте інші номери портів UDP для кожного потоку кодера.

Потокова передача UDP відрізняється поєднанням IP адреса (одноадресний або багатоадресний) and номер порту. Разом, вони визначають унікальний ідентифікатор потоку UDP у мережі.

На платі шифратора, в Налаштування потоку UDP включити:

• Віддалений IP: Визначає IP-адресу призначення (якщо використовується багатоадресна адреса, потік стає багатоадресним потоком UDP).
• Порт Tx: Визначає номер порту передачі.

Поєднання Віддалений IP + Порт Tx визначає унікальний потік UDP.

Щоб уникнути конфліктів, коли в одній мережі розгорнуто багатоадресні плати кодера, ви можете призначити різні багатоадресні IP-адреси, різні порти UDP, або використовувати обидва залежно від вимог до дизайну мережі.

Q: Як мені отримати багатоадресні IP-адреси для моєї системи?

A: Групова IP-адреса не призначається автоматично; вони вибираються зі стандартного діапазону багатоадресної передачі 224.0.0.0 до 239.255.255.255. На практиці, ці адреси повинні бути сплановані та призначені мережевим адміністратором, щоб гарантувати відсутність конфліктів з існуючими службами багатоадресної передачі або пристроями в мережі.

Q: Плата кодера повинна виводити відео через інтерфейси HDMI та AV, але обидва потоки використовують ту саму адресу UDP. Як ми можемо грати або перемикатися між ними?

A: Коли потоки HDMI та AV передаються через одну адресу UDP, вони типові не розділені мережевими портами, але по ідентифікатори внутрішнього потоку, подібний до an MPEG-TS (Транспортний потік) структура.

Як це працює

• І HDMI, і AV входи є мультиплексуються в єдиний потік UDP
• Кожному джерелу відео призначається a унікальний ідентифікатор потоку (напр., PID / ID служби)
• Приймач виконує демультиплексування на основі цих ідентифікаторів, а не розділення за IP або портом
• Це дозволяє кільком відеоканалам співіснувати в одному потоці UDP

Як Splayer справляється з цим

З нашими Плеєр 2.0 Програвач UDP, система підтримує цю архітектуру нативно:

• Одночасне розшифровування кілька відеопотоків з однієї адреси UDP
• Розділення потоків на основі внутрішні ідентифікатори (Відображення MPEG-TS PID/послуги)
• Перемикання в реальному часі між джерелами HDMI і AV без зміни налаштувань мережі
• Гнучке багатоканальне відтворення за допомогою одного джерела вхідного сигналу UDP

Ця конструкція спрощує розгортання шляхом збереження одна конфігурація UDP, поки ввімкнено обробка відео з кількома входами та плавне перемикання.

Ви можете завантажити Плеєр 2.0 Програвач UDP тут: Плеєр 2.0 Завантажити UDP Player