Нам потрібні пристрої, для отримання інформації про відео камери Full HD з SDI (Інтерфейс серійних даних) У рядку та кодуйте інформацію в стандарті H.265. Стисні дані повинні передаватися в або DVB-T (Цифрове відео мовлення наземного) або стандарт DVB-S. Аналоговий вихід розробленого модуля може приймати як I, так і Q сигналів, а також модульовані сигнали.
Зміст
Q: Чи підтримує ваш Encoder SDI Video Conder / вихід?
A: Наша існуюча плата кодування до плати модуляції передає дані через мережевий порт. А не інтерфейс TSI, про який ви згадали. Це не впливає на використання передавача до приймача. Це внутрішній інтерфейс передавача.
Q: Зробіть підтримку своїх дощок декодера кодера 525 i50 до 1080 P60 у форматі відео?
A: Тепер наші дошки для відео кодера SDI підтримують HD: 720P @ 23,98 Гц/24 Гц/25 Гц/29,97 Гц/30 Гц/50 Гц59,94 Гц/60 Гц та 1080p @ 23,98 Гц/24 Гц/25 Гц/29,97 Гц/30 Гц/50 Гц/59,94 Гц/60 Гц. Це не підтримує 525 I50 відео формат, це нормально？
Q: Ваш SDI COFDM DVB-T H265 SDI ENCODER RF Вихідна потужність підтримка 0 ~ 10DBM？
A: Ваша вихідна частота від 400 МГц до 2800 МГц, необхідна дуже широка.
Важко досягти виходу 0 ~ 10 дб в такій широкій частотній точці, і додавання підсилювача потужності на дошці збільшить споживання електроенергії та тепло (Ви також зазначили, що немає потреби в вентиляторі для розсіювання тепла).
Чи готові ви погодитися на наш існуючий -3 до виходу -10dbm, а потім додайте власний ПА (підсилювач потужності)?
Q: Який розмір вашого кодера SDI COFDM DVB-T H265 SDI?
Чи є у вас спеціальний запит? Наш існуючий розмір - 70х45мм.
A: Наші наявні відео -кодера та дошки декодера можуть задовольнити потреби вашого проекту.
Найбільша хвилювання мого інженера полягає в тому, що ваша компанія, Як член трансляції та телевізійної індустрії має відносно високі вимоги до якості відео зображення.
Наша дошка для кодування відео виконає стиснення втрат для низької затримки. Чи можете ви взяти набір існуючих зразків для тестування та підтвердження якості зображення? Якщо ви думаєте, що наші зразки можуть відповідати вимогам вашої компанії, Ми переробляємо та намалюємо дошку відповідно до вимог вашої компанії.
Q: Чи можете ви надати більше інформації про VBR?
Застосовуючи відео до TX, Параметр VBR з часом змінюватиметься і не є статичним значенням. Чи можете ви надати більше інформації про це?
A: VBR - це відео кодування біта на передавачі. Оскільки відео -зображення динамічно змінюється, VBR, звичайно, змінна, але він коливається навколо кодування швидкості біта, встановленого системою передачі: 7.81*0.8= 6,248 Мбіт / с.
Q: Незважаючи на те, що на моєму приймачі було спалах, Відповідь і на екрані не відображається зберігання. Чому це відбувається?
Ви сказали в описі: Key2: кнопка перемикання відеозапису, коротко натисніть, щоб змінити його статус. Приймач автоматично перевірить запам'ятовуючий пристрій (карта micro SD або USB-диск, Пріоритет SD -карта) після ввімкнення живлення та почніть записувати відео, коли вставлено накопичувач. Просто натисніть кнопку, щоб зупинити або записувати знову.
A: Система прийому не може виявити флеш -накопичувач USB. Флеш -накопичувач USB потрібно відформатовано до формату, який може розпізнати наша система.
Q: І B1, і B2 дорівнюють нулю. Це вказує на те, що є 0 % Швидкість помилок укусу!!! Який діапазон цих параметрів є прийнятним?
A: Поява швидкості помилок може спричинити проблеми із зображенням відеозапис. Коли швидкість помилок біта дуже мала, це не вплине на ефект відеозаписів.
Q: Чи можу я налаштувати вміст екрана програміста?
A: Вміст дисплея на панелі конфігурації (програміст) не відкритий для клієнтів для модифікації.
Q: Чому не запрограмований канал S2? Здається, що другий тюнер наразі функціонує.
A: S2 відноситься до отримання антени 2, що може працювати нормально. Частота та пропускна здатність - однакові S1 і S2.
Q: Чому затримка, яку я розрахував, величезна? Це поруч 470 Міссісіпі.
У вашому описі: Звичайні функції нашого модуля приймача можна поєднати з нашим модулем передавача H.265. Затримка відео HD від його введення передавача на екран HDMI, що відображає приймача, становить приблизно 200 мс до 250 мс.
A: Затримка, яку ми перевірили, становила близько 250 мс. Як ви це перевірили? Затримка, який ми протестували, Будь ласка, перевірте Відео -посилання на YouTube.
Q: Скільки затримки має ваш модуль передавача Encoder SDI та модуль приймача декодера?
Я пам’ятаю, що ви сказали, що оптимізували протокол для кращої затримки. Оскільки я не використовую вашу швидку затримку H.264 (130 Міссісіпі) скільки затримки ми маємо на моєму налаштуванні?
A: Ви підтвердили, що вам потрібно підтримати H265, але не H264 Режим низької затримки. Для досягнення режиму низької затримки, приймач повинен бути змінений на інше обладнання приймача, і відповідна прошивка повинна бути спалена перед відвантаженням.
Q: Чи можу я використовувати ваш приймач COFDM для отримання звичайного телевізійного каналу DVB-T?
Ви сказали, що змінили відео протокол для кращої затримки в TX. Чи можу я використовувати ваш RX як комерційний DVB-T? Як я можу отримати звичайний канал DVB-T?
A: Якщо ви дійсно хочете використовувати його як звичайний приймач DVB-T, Ми повинні оновити іншу прошивку. (Видаліть шифрування на кодері та дешифрування на декодері).
Q: Як я можу використовувати функцію меню OSD на приймачі COFDM?
У вашому описі:
Модуль приймача також включає функцію запису DVR за допомогою карти Micro SD або USB-диска. Модуль приймача також дозволяє передавати відео на USB для віддалених декодерів пристроїв Android, як смартфони або Android Pad. Це дозволяє декільком віддаленим глядачам контролювати одне і те ж відео
одночасно. Модуль приймача також підтримує відображення рядка символів на екрані відеодисплея разом із відео в режимі OSD.
A: Побачити Онлайн -документація OSD.
Q: Як я можу увімкнути шифрування AES? Де я повинен ввести ключ?
A: Панель конфігурації може редагувати та змінити пароль.
Q: Вкажіть питання зображення тексту лука:
A: Ця необов'язкова функція потрібна іншими продуктами (Функція мережевого порту використовується для підключення до двостороннього бездротового посилання). Будь ласка, ігноруйте це у вашій заявці.
Q: Яка часова затримка даних UART на односторонній передачі?
Для даних UART від TX до RX, -це дані, оброблені за допомогою процесу кодування або передаються в режимі реального часу? Мені потрібна передача даних у режимі реального часу.
A: Дані та відео надсилаються разом через бездротовий пакет COFDM. Тож затримка така ж, як і у відео.
Q: Для передавача. Можна змінити GI та FEC та інший параметр відповідно до вашої таблиці в описі?
A: Так.
Q: Яка точна сила в цей момент 1350 в 1450 МГц? Мені потрібна ця інформація для розробки ПА.
Максимальний вихід діапазону частот 1350 ~ 1450 становить близько -10 ± 2dbm. Рекомендується розробити ПА на основі введення -15dbm. Наш передавач можна відрегулювати до -15 дб.
Q: Чи має ваш програміст функції скидання заводського відновлення?
Якщо я змінюю будь -які параметри будь -якої сторони, як частота GI або FEC або пропускна здатність відео, Як я можу скинути всі параметри в режимі скидання заводських? Я новачок у цій дошці, І мені потрібно змінити деякі параметри, щоб досягти свого бажання. Але я боюся змінити деталі інформації за замовчуванням.
A: Наш TX / Програміст RX не має функції скидання фабрики.
Q: Чи підтримує ваш вхідний кодер SDI 1080I25/1080I30?
Він підтримує 1080i50 та 1080i60, він не підтримує 1080i25 або 1080i30.
Q: Чи можете ви запропонувати мені кілька технічних файлів для ремонту живної частини VCAN1731 BOANTE CONDODER SDI?
A: Будь ласка, перевірте файли за посиланням нижче.
- https://ivcan.com/wp-content/uploads/Vcan1731-Component-Part-Number-Map-1.pdf
- https://ivcan.com/wp-content/uploads/Vcan1731-Component-Part-Number-Map-2.pdf
- https://ivcan.com/wp-content/uploads/vcan1731_A01_power.pdf
Наша ідея технічного обслуговування полягає в тому, щоб спочатку виключити, чи є коротке замикання та де коротке замикання. Наприклад, Відключіть магнітну намистину або резистор 0-Ом між силою ІМ та наступним ланцюгом, а потім використовуйте мультиметр, щоб виміряти, чи зламана живлення або наступна схема коротка замикання. Якщо силова ІС зламана, Замініть живлення ІС; Якщо наступна схема буде короткокрукованою, Ви повинні перевірити наступну схему.
Q: Чи може плата кодера отримувати та пересилати дані UART через зв’язок UDP (IP:порт)?
A: Так, Передача даних UART підтримується нашою настроюваний протокол за замовчуванням, з деякими важливими міркуваннями:
1. Спеціальний протокол (Прошивка за замовчуванням)
Наша мікропрограма для доставки за умовчанням використовує a настроюваний мультиплексований протокол що підтримує Прозора передача UART (серійне проходження).
- Дані UART мультиплексуються разом з аудіо/відеопотоками.
- тому, приймаюча сторона повинна використовувати відповідні бібліотека демекс протоколу користувача щоб відокремити дані UART від медіа-потоку.
- При використанні разом із нашою платою декодера, Прозора передача UART працює належним чином і може пересилатися/отримуватись належним чином.
Примітка для гравців на ПК
Наше поточне програмне забезпечення програвача для ПК лише демультифікує та обробляє:
- Дані відео
- Аудіодані
Наразі, це робить НЕ обробляти або виводити послідовні дані UART.
2. Стандартний протокол MPEG-TS
Якщо плата кодера прошита з стандартне мікропрограмне забезпечення/протокол MPEG-TS:
- Підтримуються лише аудіо- та відеопотоки.
- UART/послідовна передача даних Не підтримується у режимі MPEG-TS.
Враховуйте це під час вибору мікропрограми/протоколу.
| Тип протоколу | Аудіо / Відео | Прозора передача UART |
|---|---|---|
| Спеціальний протокол (дефолт) | Підтримується | Підтримується |
| Стандарт MPEG-TS | Підтримується | Не підтримується |
Q: Чи є у вас вбудоване програмне забезпечення, яке підтримує необроблений H.264 або RTP замість MPEG-TS для потокової передачі UDP?
A: Наше мікропрограмне забезпечення UDP не передає необроблені елементарні потоки H.264. Потокове передавання UDP підтримується у двох форматах залежно від версії мікропрограми:
- A спеціальний власний формат, або
- The стандарт MPEG-TS (Транспортний потік MPEG) формат
Вони відповідають різним версіям прошивки (зазвичай розрізняються суфіксом, таким як версії «T» або не «T».).
Q: Чи підтримуєте ви RTP як окремий потоковий протокол??
A: Ми не надаємо окремого «режим потокової передачі необробленого RTP». Проте, RTP уже використовується внутрішньо в потоковій передачі RTSP. У режимі RTSP, аудіо та відео передаються через пакети RTP як частину стеку RTSP/RTP/RTCP. тому, RTP підтримується опосередковано через RTSP, а не як незалежний потоковий формат UDP.
Q: Чи може система виводити необроблений H.264 через UDP?
A: Немає. Необроблена передача елементарного потоку H.264 не підтримується через UDP. Це пов’язано з розміром пакета та мережевими обмеженнями. Один I-кадр може бути дуже великим і не може бути надійно переданий в одному IP-пакеті.
Для стабільної передачі, відеопотоки мають бути інкапсульовані за допомогою транспортного формату, наприклад:
- MPEG-TS, або
- RTP (через RTSP)
Q: Як виглядає ключовий кадр (GOP) налаштований інтервал?
A: Інтервал ключових кадрів контролюється за допомогою Параметр GOP у веб-інтерфейсі (сторінку налаштувань відео).
- Якщо GOP встановлено на 0 (за замовчуванням/автоматичний режим), система автоматично вирівнює інтервал I-кадру з частотою вхідних кадрів.
- приклад: Якщо введення є 1080p60, тоді інтервал I-кадру буде 60 кадри (1 друга GOP).
Це забезпечує адаптивну поведінку кодування на основі характеристик джерела вхідного сигналу.
Q: Чому необроблений H.264 не можна передати безпосередньо через IP/UDP?
A: Оскільки кадри H.264 (особливо I-frames) може бути дуже великим і перевищувати максимальну одиницю передачі (Людина) мережевих пакетів. Без капсулювання, надійна доставка не може бути гарантована. тому, для належної сегментації відео має бути пакетовано за допомогою стандартизованих потокових форматів, таких як MPEG-TS або RTP, терміни, і повторне складання.
Q: Загальна затримка моєї системи становить ~230 мс. Декодер і дисплей займають ~45 мс, залишаючи ~185 мс для камери та кодера. Я очікую, що камера вносить ~60 мс (4 кадрів при 60 кадрів в секунду), тому кодер, здається, становить ~120 мс. Чи є спосіб зменшити затримку кодера? Я розумію, що MPEG-TS в основному впливає на декодування, не кодується.
A: Розподіл затримок і вказівки з оптимізації
Щоб точно оптимізувати затримку системи, важливо спочатку перевірити кожен етап незалежно, перш ніж припускати вузькі місця.
1. Спочатку перевірте затримку камери (Критичний крок)
Перед оптимізацією кодування, ви повинні підтвердити фактичний внесок камери.
Практичний метод вимірювання:
- Підключіть вихід HDMI камери безпосередньо до дисплея
- Наведіть камеру на високоточний секундомір, який відображається на окремому моніторі ПК
- Одночасно знімайте живу сцену та вихід HDMI
- Порівняйте часові позначки кадрів, щоб обчислити наскрізну затримку камери
Примітки:
- Використовуйте високоточний секундомір (менший інтервал тактів покращує точність)
- Обробка камери ISP часто є основним внеском
- З нашого досвіду:
- 1080p-камери зазвичай мають затримку ~100 мс
- Деякі моделі можуть перевищувати цей показник через більш важкі конвеєри ISP
2. Конфігурація камери має великий вплив
Якщо затримка камери велика, оптимізація повинна починатися з цього:
- Менша роздільна здатність (напр., 720p проти 1080p) → зменшує затримку ISP і трубопроводу
- Вища частота кадрів (напр., 60 fps проти 30 кадрів в секунду) → зменшує затримку буферизації кадрів
- Простіший конвеєр обробки зображень → зменшує навантаження на провайдера
Ці зміни часто зменшують затримку ефективніше, ніж налаштування кодера.
3. Затримка кодувальника ймовірно переоцінена
A 120 Затримка кодування мс зазвичай малоймовірна для типових апаратних кодерів.
На основі внутрішніх вимірювань:
- Апаратний кодер + декодер + спосіб передавання + конвеєр відображення через Ethernet зазвичай призводить до:
- ~80–100 мс загальна наскрізна затримка
Це означає:
- Затримка лише кодера значно нижча, ніж 120 Міссісіпі
- Кодування зазвичай не є домінуючим фактором у правильно налаштованій системі
4. Спосіб передачі має значення (Особливо бездротовий)
Перевірте, чи використовує система:
- Провідний Ethernet
- Бездротова передача
Якщо використовується бездротове з’єднання:
- Низька пропускна здатність (<20 Mbps) може викликати значну затримку
- Велика передача I-кадру може спричинити буферизацію та затримки в черзі
- Це може помітно збільшити наскрізну затримку, навіть якщо кодування ефективне
5. MPEG-TS і роз'яснення службових витрат протоколу
Ваше розуміння в цілому правильне:
- MPEG-TS незначно додає затримку на етапі кодування
- Більшість накладних витрат на протокол пов’язані з пакетуванням і поведінкою декодування, не кодуючи себе
- Операції мультиплексування/демультиплексування — це в основному операції з пам’яттю і мають незначну затримку в типових системах
6. Рекомендований підхід до налагодження
Щоб точно визначити джерела затримки:
- Додайте внутрішні позначки часу на кожному етапі конвеєра:
- Час зйомки камерою
- Вхід/вихід кодера
- Мережа надсилання/отримання
- Вихід декодера
- Оновлення дисплея
- Переконайтеся, що ведення журналу є легким і не впливає на продуктивність
- Відстежуйте глибину буфера в реальному часі, щоб виявити накопичення черги
Підсумуйте нашу відповідь
- Затримка камери ISP часто є основною прихованою причиною (~100 мс при 1080p є звичайним явищем)
- Затримка кодера зазвичай набагато нижча, ніж передбачається
- Бездротова передача та буферизація можуть значно збільшити затримку
- Систематичне вимірювання часових позначок є найнадійнішим способом виявлення справжнього вузького місця
задавати питання
Дякуємо за вашу відповідь. ✨