Имаме нужда от устройства, за получаване на информация за Full HD видеозаписи от камери със SDI (Сериен интерфейс за данни) на линията и кодиране на информация в стандарт H.265. Компресираните данни трябва да се предават или в DVB-T (Наземно цифрово видеоразпръскване) или DVB-S стандарт. Аналоговият изход на проектирания модул може да приема както I, така и Q сигнали, както и модулирани сигнали.
Съдържание
Q: Вашият SDI видео енкодер поддържа ли TSI вход / продукция?
A: Нашата съществуваща платка за кодиране към платка за модулация предава данни през мрежовия порт. Вместо TSI интерфейса, който споменахте. Това не засяга използването на предавателя към приемника. Това е вътрешен интерфейс на предавателя.
Q: Поддържат ли вашите платки за декодер на енкодер 525 i50 до 1080 P60 на видео формат?
A: Сега нашите платки за SDI видео енкодер поддържат HD: 720p @ 23,98Hz/24Hz/25Hz/29,97Hz/30Hz/ 50Hz59,94Hz/60Hz и 1080p @ 23,98Hz/24Hz/25Hz/29,97Hz/30Hz/50Hz/59,94Hz/60Hz. Не поддържа 525 i50 видео формат, добре ли е?
Q: Вашият SDI COFDM DVB-T H265 SDI енкодер RF изходна мощност поддържа ли 0~10dBm？
A: Вашата изходна честотна точка от 400Mhz до 2800Mhz е много широка.
Трудно е да се постигне 0~10dBm изход при такава широка честотна точка, и добавянето на усилвател на мощност на платката ще увеличи консумацията на енергия и топлината (също спомена, че няма нужда от вентилатор за разсейване на топлината).
Готови ли сте да се съгласите с нашето съществуване -3 до -10dBm изход и след това добавете свой собствен PA (усилвател на мощност)?
Q: Какъв е размерът на вашия COFDM DVB-T H265 SDI енкодер?
Имате ли специално искане за размери? Нашият съществуващ размер е 70x45 мм.
A: Нашите съществуващи платки за видео енкодер и декодер могат да отговорят на нуждите на вашия проект.
Най-голямото притеснение на моя инженер е, че вашата компания, като член на радиоразпръсквателната и телевизионната индустрия има относително високи изисквания към качеството на изображението и видеото.
Нашата платка за видео кодиране ще извърши компресия със загуби за ниска латентност. Можете ли да вземете набор от съществуващи проби, за да тествате и потвърдите качеството на изображението? Ако смятате, че нашите проби могат да отговорят на изискванията на вашата компания, ние ще преработим и начертаем дъската според изискванията на вашата компания.
Q: Бихте ли предоставили повече информация за VBR?
Чрез прилагане на видео към TX, параметърът VBR ще се променя с времето и не е статична стойност. Бихте ли предоставили повече информация за това?
A: VBR е побитовата скорост на видео кодиране в предавателя. Тъй като видео картината се променя динамично, VBR разбира се е променлива, но се колебае около битовата скорост на кодиране, зададена от предавателната система: 7.81*0.8=6,248Mbps.
Q: Въпреки че имам флаш памет на моя приемник, На екрана се показват REC OFF и No Storage. Защо се случва това?
Казахте в описанието: key2: бутон за превключване за запис на видео, натиснете кратко, за да промените състоянието му. Приемникът автоматично ще провери устройството за съхранение (micro SD карта или USB диск, приоритетна SD карта) след включване и започнете да записвате видео, когато устройството за съхранение е поставено. Просто натиснете бутона, за да спрете или да запишете отново.
A: Получаващата система не успява да открие USB флаш устройството. USB флаш устройството трябва да бъде форматирано във формат, който нашата система може да разпознае.
Q: И B1, и B2 са нула. Това показва, че има a 0 % Честота на грешка при захапване!!! Кой диапазон от тези параметри е приемлив?
A: Появата на битова грешка може да причини проблеми с видео изображението. Когато битовата грешка е много малка, това няма да повлияе на ефекта на видео изображението.
Q: Мога ли да персонализирам съдържанието на екрана на програмиста?
A: Съдържанието на дисплея на конфигурационния панел (програмист) не е отворен за клиенти за модификация.
Q: Защо каналът S2 не е програмиран? Изглежда, че вторият тунер не работи в момента.
A: S2 се отнася за приемна антена 2, който може да работи нормално. Честотата и честотната лента са еднакви s1 и s2.
Q: Защо латентността, която изчислих, е огромна? Наоколо е 470 Госпожица.
Във вашето описание идва: Нормалните характеристики по подразбиране на нашия приемен модул могат да бъдат сдвоени с нашия H.265 предавателен модул. Закъснението на HD видеото от въвеждането му на предавателя до дисплея на HDMI екрана на приемника е около 200ms до 250ms.
A: Закъснението, което тествахме, беше около 250 ms. Как го тествахте? Начинът на забавяне, който тествахме, моля, проверете Youtube видео връзка.
Q: Колко латентност има вашият SDI енкодер предавател и декодер приемен модул?
Спомням си, че казахте, че сте оптимизирали протокола за по-добро забавяне. Тъй като не използвам вашата бърза H.264 латентност (130 Госпожица) колко забавяне трябва да имаме за моята настройка?
A: Вие потвърдихте, че трябва да поддържате H265, но не и H264 режим с ниска латентност. За постигане на режим на ниска латентност, приемникът трябва да бъде сменен с друг хардуерен приемник, и съответният фърмуер трябва да бъде записан преди изпращане.
Q: Мога ли да използвам вашия COFDM приемник, за да получа нормалния DVB-T телевизионен канал?
Казахте, че сте променили видео протокола за по-добра латентност в TX. Мога ли да използвам вашия RX като комерсиален DVB-T? как мога да приема нормалния DVB-T канал?
A: Ако наистина искате да го използвате като нормален DVB-T приемник, трябва да надстроим друг фърмуер. (премахнете криптирането на енкодера и декриптирането на декодера).
Q: Как мога да използвам функцията на екранното ви меню на 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 MHz? Имам нужда от тази информация, за да проектирам PA.
Максималната мощност на честотната лента 1350~1450 е около -10±2dBm. Препоръчително е да се проектира PA въз основа на -15dBm вход. Нашият предавател може да се регулира до -15dBm.
Q: Вашият програмист има ли функция за възстановяване на фабричните настройки?
Ако променя параметри от която и да е страна, като честота GI или FEC или честотна лента на видео, как мога да нулирам всички параметри в режим на нулиране на фабричните настройки? Аз съм нов в този форум, и трябва да променя някои параметри, за да постигна желанието си. Но ме е страх да не променя информацията по подразбиране.
A: Нашият TX / RX програматорът няма функция за възстановяване на фабричните настройки.
Q: Вашият SDI Video input енкодер поддържа ли 1080i25/1080i30?
Поддържа 1080i50 и 1080i60, не поддържа 1080i25 или 1080i30.
Q: Можете ли да ми предложите някои технически файлове за ремонт на силовата част на Платка за видео енкодер Vcan1731 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 ома между захранващия IC и последващата верига, и след това използвайте мултицет, за да измерите дали захранващата IC е прекъсната или последващата верига е късо. Ако захранването IC е счупено, сменете захранващата IC; ако последващата верига е късо съединение, трябва да проверите следващата верига.
Q: Може ли енкодерната платка да получава и препраща UART данни чрез UDP комуникация (IP:порт)?
A: да, UART предаването на данни се поддържа от нашите потребителски протокол по подразбиране, с някои важни съображения:
1. Персонализиран протокол (Фърмуер по подразбиране)
Нашият фърмуер за доставка по подразбиране използва a потребителски мултиплексиран протокол който поддържа UART прозрачно предаване (серийно преминаване).
- UART данните се мултиплексират заедно с аудио/видео потоци.
- Следователно, приемащата страна трябва да използва съответния персонализиран протокол demux библиотека за отделяне на 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 потребителски патентован формат, или
- Най- стандартен 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 ms. Декодерът и дисплеят отнемат ~45 ms, оставяйки ~185 ms за камера и енкодер. Очаквам камерата да допринесе ~60 ms (4 рамки при 60 кадъра в секунда), така че енкодерът изглежда е ~120 ms. Има ли начин да се намали латентността на енкодера? Разбирам, че MPEG-TS засяга главно декодирането, не кодира.
A: Разбивка на латентността и насоки за оптимизиране
За точно оптимизиране на латентността на системата, важно е първо да валидирате всеки етап независимо, преди да приемете тесни места.
1. Първо проверете латентността на камерата (Критична стъпка)
Преди оптимизиране на кодирането, трябва да потвърдите действителния принос на камерата.
Практичен метод за измерване:
- Свържете HDMI изхода на камерата директно към дисплей
- Насочете камерата към високоточен хронометър, показан на отделен компютърен монитор
- Заснемайте както сцената на живо, така и HDMI изхода едновременно
- Сравнете времевите отпечатъци на кадрите, за да изчислите закъснението на камерата от край до край
Бележки:
- Използвайте хронометър с висока точност (по-малкият тик интервал подобрява точността)
- Обработката на ISP на камера често е основен фактор
- Според нашия опит:
- 1080p камерите обикновено въвеждат ~100 ms латентност
- Някои модели може да надхвърлят това поради по-тежки ISP тръбопроводи
2. Конфигурацията на камерата има голямо влияние
Ако латентността на камерата е голяма, оптимизацията трябва да започне там:
- Долна разделителна способност (e.g., 720p срещу 1080p) → намалява забавянето на ISP и тръбопровода
- По-висока скорост на кадрите (e.g., 60 fps срещу 30 кадъра в секунда) → намалява латентността на буферирането на рамката
- По-опростен канал за обработка на изображения → намалява натоварването на ISP
Тези промени често намаляват латентността по-ефективно от настройката на енкодера.
3. Латентността на енкодера вероятно е надценена
A 120 ms забавянето на кодирането обикновено е малко вероятно за типичните хардуерни енкодери.
Въз основа на вътрешни измервания:
- Хардуерен енкодер + декодер + предаване + тръбопроводът на дисплея през Ethernet обикновено води до:
- ~80–100 ms общо закъснение от край до край
Това предполага:
- Закъснението само за енкодер е значително по-ниско от 120 Госпожица
- Кодирането обикновено не е доминиращият фактор в правилно конфигурирана система
4. Методът на предаване има значение (Особено безжични)
Моля, проверете дали системата използва:
- Кабелен Ethernet
- Безжично предаване
Ако се използва безжична връзка:
- Ниска честотна лента (<20 Mbps) може да доведе до значително забавяне
- Големият I-frame предаване може да причини буфериране и закъснения в опашка
- Това може значително да увеличи латентността от край до край, дори ако кодирането е ефективно
5. Изясняване на MPEG-TS и протокола
Вашето разбиране като цяло е правилно:
- MPEG-TS не добавя значително забавяне на етапа на кодиране
- Повечето режийни разходи на протокола са свързани с поведението на пакетиране и декодиране, не кодира себе си
- Мукс/демукс операциите са основно операции с памет и имат незначително забавяне в типичните системи
6. Препоръчителен подход за отстраняване на грешки
За точно локализиране на източниците на латентност:
- Добавете вътрешни времеви клейма на всеки етап от конвейера:
- Време за заснемане на камерата
- Вход/изход на енкодер
- Мрежово изпращане/получаване
- Изход на декодера
- Опресняване на дисплея
- Уверете се, че регистрирането е леко и не влияе на производителността
- Наблюдавайте дълбочината на буфера в реално време, за да откриете натрупване на опашка
Обобщете нашия отговор
- Забавянето на ISP на камерата често е основен скрит фактор (~100 ms при 1080p е обичайно)
- Забавянето на енкодера обикновено е много по-ниско от предполагаемото
- Безжичното предаване и буферирането могат значително да увеличат забавянето
- Систематичното измерване на времевия печат е най-надеждният начин за идентифициране на истинското тясно място
Задай въпрос
Вашето съобщение е изпратено