Съдържание
Платка за видео енкодер на USB камера
Днес, един клиент ме помоли да му покажа UVC към RTSP платката за видео енкодер. Така че във видеото по-долу, Показвам работата на USB камерата с нашия видео енкодер, HDMI CVBS UVC USB към IP Ethernet RTSP UDP видео енкодер, и изходен жив поток.
Уеб камерата се въвежда през USB към платката за видео енкодер, и видео потокът се извежда през мрежовия кабел към компютър. На компютъра, използваме Easyplayer като RTSP плейър. Нашият HDMI / CVBS / USB видео вход, чрез RTSP / Платка за кодиране на UDP видео поток, също поддържа VLC плейър, но това е универсален софтуер, така че забавянето ще бъде по-голямо.
Нашата платка за видео енкодер също поддържа UDP протокол. Освен стартиране на RTSP плейър на компютъра, ние също така изпълняваме UDP плейър, Плейър. Във видеото, можем да видим, че Splayer, който поддържа UDP протокола, има по-ниска латентност. Разбира се, това забавяне е на ниво милисекунди, и разликата е само няколко десетки милисекунди. Ако нашата платка за декодер и платка за енкодер се използват заедно, закъснението е около 80-100 милисекунди.
Нека да разгледаме още веднъж USB камера, свързана към нашата енкодерна платка с ултра ниска латентност като източник на видео. Видео потокът се извежда към компютъра през мрежовия кабел и се възпроизвежда в реално време с помощта на Easyplayer, който поддържа протокола RTSP и Splayer, който поддържа UDP протокола.
За този тест, използваме обикновена USB уеб камера, чиято латентност не е оптимизирана. Ако имате специална камера, можете също да ни кажете чипа на камерата и модела на обектива, и ние също можем да тестваме забавянето в реално време заедно.

Това е друг модел USB камера. Ето видео входа към нашата видео кодираща платка. Ethernet кабелът свързва нашата видео кодираща платка и компютъра. Към компютъра, чрез мрежов порт RJ45.
На компютъра, този път стартираме LVC плейъра. LVC плейърът поддържа и RTSP протокола. От менюто Медия, изберете отворен мрежов поток, и въведете RTSP URL адреса на нашата платка за видео енкодер по подразбиране.
Основното предимство на енкодерите от UVC към RTSP са техните възможности за ниска латентност. Нашата платка за видео енкодер с по-ниска латентност може да постигне толкова ниска латентност, колкото 60-90 милисекунди за CVBS входове. 90-130 милисекунди за HDMI входове, което ги прави подходящи за приложения в реално време като наблюдение и излъчване на живо.
Нашите UVC HDMI CVBS към IP RTSP UDP енкодери поддържат различни входни формати, което позволява гъвкавост при избора на камера, за системи за наблюдение, стрийминг предавания на живо, видеоконферентна връзка, и индустриален мониторинг.
ЧЗВ
Q1: Работя върху вашия енкодер. Мога да получа rtsp поток от VLC плейър и udp поток от Splayer. Но искам да получавам mpeg-ts udp пакет при vlc, работещ на ubuntu.
A1: Ако клиентът няма специални изисквания към фърмуера при поръчка, ще използваме персонализиран протокол, който е оптимизиран на базата на протокола MPEGTS, има по-високо използване на честотната лента, поддържа прозрачно предаване на сериен порт и AES криптиране и декриптиране, така че DVB-T приемниците на пазара не са съвместими. Ако използвате VLC плейъра, можете да използвате само протокола RTSP за получаване на аудио и видео потоци. Този фърмуер също поддържа UDP протокола и трябва да се играе с Плейър.
Ако клиентът се съгласи да надстрои стандартния MPEG-TS протокол, те също могат да използват UDP протокола на VLC плейъра за игра.
въпреки това, този стандартен протокол губи функциите за AES криптиране и прозрачно предаване на сериен порт след надстройката, и не може да се играе с помощта на Splayer. VLC плейърът може да се използва както на Windows, така и на Ubuntu Linux системи.
Q2: Защо клиентът се нуждае от UDP, за да възпроизвежда MPEGTS потоци с VLC?
A2: Трябва да използваме udp потока, за да може да работи симплексна връзка. Как можем да използваме udp потока за получаване на Ubuntu? Моля, споделете нещо, от което можем да получим udp потока на Ubuntu PC.
Искате да изтеглите фърмуера на стандартния MPEG-TS протокол за Vcan1746?https://drive.google.com/file/d/1YFhPQM6GcofvjtBWgpe3rY0Gwh7Da3mB/view?usp=drive_link
Как да надстроите фърмуера на борда на енкодерите?
Моля, следвайте стриктно инструкциите на въвеждащия документ за надстройка на уеб страница, за да завършите надстройката в две стъпки. Не извършвайте допълнителни операции (като натискане на бутона за надграждане многократно) по време на процеса на надграждане. Не изключвайте захранването по време на процеса на надграждане.
Използването на VLC плейър е същото в Windows и Ubuntu, така че няма нужда да наблягаме на системата. Ако сте сигурни, че трябва да използвате UDP на VLC плейъра, за да възпроизвеждате видео потоци, тогава трябва да надстроите стандартния MPEG-TS фърмуер.
- Следвайте инструкциите за надстройка по-горе и надстройте до фърмуера на стандартния MPEGTS протокол чрез уеб страницата. Дали надстройката е успешна може да се потвърди чрез достъп до системната страница на уеб сървъра.

- Как да получите аудио и видео потоци във vlc плейър: Влезте в уеб сървъра на платката за енкодер Vcan1746, променете отдалечения IP на IP на компютъра, и променете протокола и на двете (за улесняване на демонстрацията на udp и rtsp протоколи едновременно)

- Как VLC плейърът получава аудио и видео потоци чрез UDP?

- Как VLC плейърът получава аудио и видео потоци чрез RTSP?

- Използването на VLC плейър е същото в Windows и Ubuntu.
Q3: Компилирах и стартирах dvb_demux_test приложение в Linux. Виждам, че това приложение задава нишка и получава udp пакети на порт 1234. Искам да знам какво прави с тези пакети след това. Какво правят dbv функциите с тези пакети?
A3: Кой номер на порт да се използва зависи от настройките на платката за кодиране на клиента. Например, ако използваният номер на порт по подразбиране UDP е 8090, клиентът трябва да промени тестовата програма и да я използва 8090 вместо.

- Отдалеченият IP трябва да бъде зададен на IP адреса на компютъра
- Портът може да бъде зададен от клиента, като 1234, или по подразбиране 8090;
- Протоколът трябва да е UDP, или и двете
Q4: Как мога да разработя Linux версия на Splayer въз основа на примера, който предоставихте?
A4: В parse_pal, Анализират се времевата марка и nal_type на видео рамката NAL, И това вече е цялостно видео.

След това клиентът може да се обади на библиотеката за декодиране, която е написал (като ffmpeg) да го декодира.

Можете да се обърнете към нашите splay player SDK (базиран на Windows система).
dvb_demux_test прилага обработката отпред в плейъра Splayer. Завършеният играч изисква следните части: демокс, декодирам, дисплей, рекорд. dvb_demux_test прилага demux.
С изключение на demux, което включва нашия персонализиран протокол и изисква от нас да предоставим библиотека, другите части са отворени и прозрачни и могат да бъдат изпълнени по различни начини. Клиентите могат да използват нашите, като нашия Splayer под Windows, или могат да използват свои собствени (например, те са написали свой собствен плейър), или дори да намерите други лица и компании, които правят играчи, за да ги развиват.
Тъй като много клиенти, дори ако развиват свои собствени играчи, всъщност може да извика ffmpeg/vlc, за да го приложи, което е само маскировка. В такъв случай, те трудно могат да се справят с протоколите, които ffmpeg/vlc не поддържа (като нашите персонализирани протоколи) (защото те няма да развият играч от нулата). Преминаването към стандартния mpegts протокол е осъществимо за такива клиенти. dvb_demux_тест, подходящ за клиенти, които искат да разработят играч от нулата.

Задай въпрос
Вашето съобщение е изпратено