OpenHD: DIY/opensource HD/FHD цифровое видео своими руками
Если кто серьезно готов заняться поддержкой работы с этими камерами, то обращайтесь, поделюсь исходным кодом С++. Самому сейчас нет времени этим заниматься.
где то натыкался на целый сайт с прошивками для этих камер, которые пилят сами люди.
Это не так, по обоим пунктам.
Это так по всем пунктам.
Вы не программист и не в теме.
Ну или можете подробно рассказать как же именно и какими командами вы заходите внутрь embedded linux прошивки и управляете камерами xiongmaitech ? 😃))
Я их использую около десятка лет, всё очень даже неплохо.
Я вас поздравляю что вы их “используете десяток лет” но вот у вас у самого как вы выше написали это нормально не работает.
Но вы упорно советуете другим людям ходить по граблям.
Вы опять не в теме. Зайдите в фирмочку,
Это вы не в теме.
Я порядка пяти лет летал с камерой с двойной переконвертацией и h264 транспортом по воздуху (первая конвертация всегда происходит на чипе матрицы если камера не цифровая).
Качество и разрешение при этом падает катастрофически.
Если вас подобна жуть устраивает - мои соболезнования, но мои глаза это не устраивает никак - я привык к полноценной HD картинке с борта дрона.
Идёт по TCP. По сути поток с аппаратного энкодера сразу отправляется в сеть без всей этой монструозной хрени
По TCP как раз и очень очень плохо и медленно. Это нормально для кабельных сетей но очень и очень плохо для стрима по воздуху.
А чистый h264 поток легко отдается прямо с RPI и значительно проще чем RTSP
где то натыкался на целый сайт с прошивками для этих камер, которые пилят сами люди.
Ну или можете подробно рассказать как же именно и какими командами вы заходите внутрь embedded linux прошивки и управляете камерами xiongmaitech ? 😃))
Всё слишком просто. Серьезно 😃 Хотя иногда бывает нужен паяльник и SPI программатор. Но это редко и на совсем убогих железках.
По TCP как раз и очень очень плохо и медленно. Это нормально для кабельных сетей но очень и очень плохо для стрима по воздуху.
А чистый h264 поток легко отдается прямо с RPI и значительно проще чем RTSP
Это не имеет к воздуху ни какого отношения.
TCP идёт от камеры к малине, дальше уже обычным способом по воздуху, если говорить о том как бы это работало в наших целях.
На системе (камера с TCP на локалхосте -> 4G модем -> Сервер в интернете -> мобильное приложение) задержка получалась около 250мс - 300мс.
Кардинальное отличие их закрытого протокола от RTSP в том что есть возможность максимально эффективно отказаться от буферов, что хорошо сказывается на задержке.
Но для этого нужна реализация приема потока непосредственно в опенхд.
Вы не программист и не в теме. Ну или можете подробно рассказать как же именно и какими командами вы заходите внутрь embedded linux прошивки и управляете камерами xiongmaitech ? 😃))
Причём тут программирование? Тут люди _используют_ оборудование, а не прошивки пишут.
Я вас поздравляю что вы их “используете десяток лет” но вот у вас у самого как вы выше написали это нормально не работает.
Что у меня нормально не работает, касаемоего IP камер?
Я порядка пяти лет летал с камерой с двойной переконвертацией и h264 транспортом по воздуху (первая конвертация всегда происходит на чипе матрицы если камера не цифровая). Качество и разрешение при этом падает катастрофически.
Зачем??? двойная переконвертация??? Вообще зачем переконвертация, применительно к теме где мы находимся?
Тут максимум инкапсуляция сжатого потока происходит, без его обработки, до момента вывода на экран.
из пустого в порожнее
У Зипрея всё получается, но он здесь редкий гость, здесь присутствующие редкие гости в телеграмме. Н265 уже передаётся существующими средствами.
У Зипрея много чего получается на словах, причем повторить это не может никто. Существующими средствами можно было изначально передавать ЛЮБЫЕ данные, не только H.265, внутри tx_rawsock нет привязки к содержимому.
Звук также инкапсулирован в h264 NAL’ы … OnVIF + RTSP и миллиона промежуточных буфферов.
Икспёрд детектед? Ну где в H.264 хоть словo про звук??? Причем здесь OnVIF??? Какое отношение имеет RTSP к буферизации???
Икспёрд детектед? Ну где в 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?
У вас одинаковые антенны на земле и на воздухе и одинаковые настройки мощности?