OpenHD: DIY/opensource HD/FHD цифровое видео своими руками
Икспёрд детектед? Ну где в H.264 хоть словo про звук??? Причем здесь OnVIF??? Какое отношение имеет RTSP к буферизации???
Именно так, эксперт детектед)))
Это же китайцы, они засунули звук в видео поток. Сам поток в h264 Annex-B. Звук идёт в NAL’ах с нестандартным типом (unspecified по спецификации). Конкретно китайцы используют тип 26, звук в ALAW (но может быть другой, там ещё ид типа передается). Для софта который об это не знает - схема прозрачна, он просто игнорирует такие NALU.
Слышите звук в потоке с китайской IP камеры или видеорегистратора? Нет? А он там есть! 😁
Могу ещё бесплатную идею подкинуть - таким же способом можно на лету подмешивать телеметрию в поток, обеспечивая тем самым высокую синхронность с картинкой в том числе на записи.
Парсинг NALU очень простой и дешевый, так что можно перед отправкой в воздух, мешать туда что угодно. Потом сохранять этот битстрим на диск и специальным проигрывателем воспроизводить (обычный проигрыватель будет читать только видео).
Собственно архив у китайцев так и работает, там и звук и события и собственно видео. При этом приёмная реалтайм часть вообще не заметит изменений. Трафик только подрастёт в зависимости от аппетитов подмешивателя 😁
Могу ещё бесплатную идею подкинуть - таким же способом можно на лету подмешивать телеметрию в поток, обеспечивая тем самым высокую синхронность с картинкой в том числе на записи.
мне понравилось, что в китайской камере есть штатное выбрасывание компорта в IP
прямо в настройках камеры указываешь IP клиента и порт.
эдак камаера стоит 10 долларов, а MOXA конвертер 323/485 стоит 60 долларов
Могу ещё бесплатную идею подкинуть - таким же способом можно на лету подмешивать телеметрию в поток, обеспечивая тем самым высокую синхронность с картинкой в том числе на записи.
Ну это палка о двух концах. Кому-то удобнее иметь телеметрию отдельно от потока, темболее сначала пропадает видео, а потом телеметрия. Или вообще телеметрию гнать через пульт, так там еще дальнобойнее.
Разумеется, каждое техническое решение должно применяться когда оно нужно и не применяться когда не нужно 😃
Кстати, тем кто летает с ИП камерами, стоит убедиться что звук выключен в настройках камеры. Это немного снизит поток. Точно не помню, вроде там по 160 байт несколько раз в секунду летит.
Всё слишком просто. Серьезно Хотя иногда бывает нужен паяльник и SPI программатор.
То есть когда у меня дрон летит в воздухе и мне нужно поменять параметр - мне нужен программатор?
Сильно. А я вот на пульте могу ручку покрутить и ИСО камеры изменится. Или выдержка. Или все что угодно. Для камер на распберри это очень просто
Это не имеет к воздуху ни какого отношения. TCP идёт от камеры к малине
Какая дремучесть.
вам бы для начала понять чем разные TCP/IP протоколы отличаются друг от друга. Но подозреваю что это вам будет сложно.
задержка получалась около 250мс - 300мс.
ПЦ (извините вырвалось)
У меня на 4G: камера - распберри - 4G - воздух- VPN сервер- воздух- 4G - ноутбук - меньше.
купив постоянный _один_ IP 4G адрес задержки можно снизить еще в 2 раза
Кардинальное отличие их закрытого протокола от RTSP
А чего вы уперлись в RTSP ? Кому он нужен и кто его рекламировал кроме вас?
Тут люди _используют_ оборудование, а не прошивки пишут.
Eсли вы не в курсе в какую тему пишете то OpenHD - это не прошивка.[quote=schs;8035771]
Тут максимум инкапсуляция сжатого потока происходит, без его обработки
Инкапсуляция аналога в H264 - это сильно )))
У меня есть только один комментарий по изложенному выше: “иногда лучше молчать чем говорить” 😉
С другой стороны, нет ни чего зазорного в том чтобы чего-то не знать или заблуждаться.
Плохо когда теряется стремление к познанию истины, иногда противоречащей ранее сформировавшейся точке зрения.
нет ни чего зазорного в том чтобы чего-то не знать или заблуждаться.
Открою для вас несекрет.
Распберри на котором построен OpenHD - это полноценный линукс компьютер.
Примерно как ваш домашний на котором вы в игрушки играете, или ваш ноутбук. Но послабее.
Там все можно сделать. Хоть письмо послать маме или в DOOM поиграть прямо в воздухе. А уж управлять камерами - там все прекрасно в отличии от embedded китайских камер видеонаблюдения.
Теперь всё сходится, спасибо
Причем здесь OnVIF??? Какое отношение имеет RTSP к буферизации???
ой
Хоть один человек тут программирует?
Там все можно сделать. Хоть письмо послать маме или в DOOM поиграть прямо в воздухе. А уж управлять камерами - там все прекрасно в отличии от embedded китайских камер видеонаблюдения.
Китайские IP камеры видеонаблюдения отлично управляются с Raspberry Pi пакетом python-dvr github.com/NeiroNx/python-dvr
Кстати это и есть тот самый протокол. Реализовано не много (видимо автору только админские функции нужны были) , но в целом заход верный
отлично управляются с Raspberry Pi пакетом python-dvr github.com/NeiroNx/python-dvr
спасибо, посмотрю
Шутка )))
однажды наши дроны будут хакать ( вскрывать) прям в полете и перехватывать root
все идет к тому и я не вижу проблеm
это серьезная проблема.
Привет! Чем объясняется большая разница между downlink и uplink rssi - в комнатных условиях первый -10-15dbm, второй -50-60dbm согласно osd.
Стоят одинаковые синие свистки на небе и земле, комбинация антенн (клевер, штырь, патч) мало влияет, кроме того что с патч-антенной на наземной части происходила пропажа uplink сигнала(!) и failsafe в результате. На rcgroups клевещут что это норма и всего лишь результат неверных вычислений: “…the uplink RSSI that you are seeing is the result of a incorrect signal quality calculation” (www.rcgroups.com/forums/showthread.php?3154184-Ope…).
Действительно ли это эффект близкого расположения и надо проверять в небесах/полях дальность uplink-a?
спасибо, посмотрю
Шутка )))
однажды наши дроны будут хакать ( вскрывать) прям в полете и перехватывать root
все идет к тому и я не вижу проблеm
это серьезная проблема.
Так это проблема или не проблема?
Привет! Чем объясняется большая разница между downlink и uplink rssi - в комнатных условиях первый -10-15dbm, второй -50-60dbm согласно osd.
Стоят одинаковые синие свистки на небе и земле, комбинация антенн (клевер, штырь, патч) мало влияет, кроме того что с патч-антенной на наземной части происходила пропажа uplink сигнала(!) и failsafe в результате. На rcgroups клевещут что это норма и всего лишь результат неверных вычислений: “…the uplink RSSI that you are seeing is the result of a incorrect signal quality calculation” (www.rcgroups.com/forums/showthread.php?3154184-Ope…).
Действительно ли это эффект близкого расположения и надо проверять в небесах/полях дальность uplink-a?
У вас одинаковые антенны на земле и на воздухе и одинаковые настройки мощности?
У вас одинаковые антенны на земле и на воздухе и одинаковые настройки мощности?
Да, одинаковые
Да, одинаковые
Значит так и должно быть, скорее всего. Большинство летают с отдельным управлением.
Дело было вечером, делать было нечего. Решил скачать прошивку inav 2.6rc2. Так там поправили телеметрию мавлинк, теперь выводит азимут как на арду, название полетных режимов на манер арду, потраченные миллиамперы и возможно системные сообщения. Но пока не летал, жду релиза.
Вопрос для тех, кто балуется с вайфай rtl8812au.
Мощность настраиватеся параметром TxPowerAir(TxPowerGround) или TXPOWER?
А то написано, что надо настраивать TxPowerAir(TxPowerGround) для данных модулей, а в логах используется параметр TXPOWER.
это просто был такой косяк в последних прошивках - настраивай что угодно, а используется значение Ground.
А так как у меня RC не используется, то TX Ground у меня стоял 3
B z dct levfk? xnj ; z ektntnm nj yt vjue/
ye djn/
B z dct levfk? xnj ; z ektntnm nj yt vjue/
ye djn/
Прожуй
Так в том то и вопрос: какой параметр вбивать? По описанию одно, по логу загрузки другое. Или можно как-то косвенно определить?
обновить на 2.0.5 там все поправлено
Что-то не нашел в примечании, но проверю.
Ничего там не поправленно. Описание одно, а мощность из других параметров берется.