OpenHD: DIY/opensource HD/FHD цифровое видео своими руками

schs
khomyakk:

Н265 уже передаётся существующими средствами.

Может добавят в Open.HD, было бы неплохо получить уменьшение занимаемой полосы где то на 30%
PI4 умеет аппаратно декодировать, телефоны тоже.

HardRock:

Если кто серьезно готов заняться поддержкой работы с этими камерами, то обращайтесь, поделюсь исходным кодом С++.

Я вот не программист, не потяну, может выложить куда и дать ссылку в телеграме? Может кто подхватит.
А из gstreamer можно поток получить?

kak-dela007
=Vlad:

Готов отдать в 2-3 раза дешевле чем купил. Вот только они и даром никому такие не нужны.

А покажите пожалуйста, что именно за камерки? Можете в личку ссылочку прислать. Я бы взял для тестов, тем более рядом.

tuskan
HardRock:

Если кто серьезно готов заняться поддержкой работы с этими камерами, то обращайтесь, поделюсь исходным кодом С++. Самому сейчас нет времени этим заниматься.

где то натыкался на целый сайт с прошивками для этих камер, которые пилят сами люди.

=Vlad
schs:

Это не так, по обоим пунктам.

Это так по всем пунктам.
Вы не программист и не в теме.
Ну или можете подробно рассказать как же именно и какими командами вы заходите внутрь embedded linux прошивки и управляете камерами xiongmaitech ? 😃))

schs:

Я их использую около десятка лет, всё очень даже неплохо.

Я вас поздравляю что вы их “используете десяток лет” но вот у вас у самого как вы выше написали это нормально не работает.
Но вы упорно советуете другим людям ходить по граблям.

schs:

Вы опять не в теме. Зайдите в фирмочку,

Это вы не в теме.
Я порядка пяти лет летал с камерой с двойной переконвертацией и h264 транспортом по воздуху (первая конвертация всегда происходит на чипе матрицы если камера не цифровая).
Качество и разрешение при этом падает катастрофически.
Если вас подобна жуть устраивает - мои соболезнования, но мои глаза это не устраивает никак - я привык к полноценной HD картинке с борта дрона.

HardRock:

Идёт по TCP. По сути поток с аппаратного энкодера сразу отправляется в сеть без всей этой монструозной хрени

По TCP как раз и очень очень плохо и медленно. Это нормально для кабельных сетей но очень и очень плохо для стрима по воздуху.
А чистый h264 поток легко отдается прямо с RPI и значительно проще чем RTSP

HardRock
tuskan:

где то натыкался на целый сайт с прошивками для этих камер, которые пилят сами люди.

openipc.org

=Vlad:

Ну или можете подробно рассказать как же именно и какими командами вы заходите внутрь embedded linux прошивки и управляете камерами xiongmaitech ? 😃))

Всё слишком просто. Серьезно 😃 Хотя иногда бывает нужен паяльник и SPI программатор. Но это редко и на совсем убогих железках.

=Vlad:

По TCP как раз и очень очень плохо и медленно. Это нормально для кабельных сетей но очень и очень плохо для стрима по воздуху.
А чистый h264 поток легко отдается прямо с RPI и значительно проще чем RTSP

Это не имеет к воздуху ни какого отношения.
TCP идёт от камеры к малине, дальше уже обычным способом по воздуху, если говорить о том как бы это работало в наших целях.
На системе (камера с TCP на локалхосте -> 4G модем -> Сервер в интернете -> мобильное приложение) задержка получалась около 250мс - 300мс.

Кардинальное отличие их закрытого протокола от RTSP в том что есть возможность максимально эффективно отказаться от буферов, что хорошо сказывается на задержке.
Но для этого нужна реализация приема потока непосредственно в опенхд.

schs
=Vlad:

Вы не программист и не в теме. Ну или можете подробно рассказать как же именно и какими командами вы заходите внутрь embedded linux прошивки и управляете камерами xiongmaitech ? 😃))

Причём тут программирование? Тут люди _используют_ оборудование, а не прошивки пишут.

=Vlad:

Я вас поздравляю что вы их “используете десяток лет” но вот у вас у самого как вы выше написали это нормально не работает.

Что у меня нормально не работает, касаемоего IP камер?

=Vlad:

Я порядка пяти лет летал с камерой с двойной переконвертацией и h264 транспортом по воздуху (первая конвертация всегда происходит на чипе матрицы если камера не цифровая). Качество и разрешение при этом падает катастрофически.

Зачем??? двойная переконвертация??? Вообще зачем переконвертация, применительно к теме где мы находимся?
Тут максимум инкапсуляция сжатого потока происходит, без его обработки, до момента вывода на экран.

lelik
khomyakk:

У Зипрея всё получается, но он здесь редкий гость, здесь присутствующие редкие гости в телеграмме. Н265 уже передаётся существующими средствами.

У Зипрея много чего получается на словах, причем повторить это не может никто. Существующими средствами можно было изначально передавать ЛЮБЫЕ данные, не только H.265, внутри tx_rawsock нет привязки к содержимому.

lelik
HardRock:

Звук также инкапсулирован в h264 NAL’ы … OnVIF + RTSP и миллиона промежуточных буфферов.

Икспёрд детектед? Ну где в H.264 хоть словo про звук??? Причем здесь OnVIF??? Какое отношение имеет RTSP к буферизации???

HardRock
lelik:

Икспёрд детектед? Ну где в H.264 хоть словo про звук??? Причем здесь OnVIF??? Какое отношение имеет RTSP к буферизации???

Именно так, эксперт детектед)))
Это же китайцы, они засунули звук в видео поток. Сам поток в h264 Annex-B. Звук идёт в NAL’ах с нестандартным типом (unspecified по спецификации). Конкретно китайцы используют тип 26, звук в ALAW (но может быть другой, там ещё ид типа передается). Для софта который об это не знает - схема прозрачна, он просто игнорирует такие NALU.

Слышите звук в потоке с китайской IP камеры или видеорегистратора? Нет? А он там есть! 😁

Могу ещё бесплатную идею подкинуть - таким же способом можно на лету подмешивать телеметрию в поток, обеспечивая тем самым высокую синхронность с картинкой в том числе на записи.
Парсинг NALU очень простой и дешевый, так что можно перед отправкой в воздух, мешать туда что угодно. Потом сохранять этот битстрим на диск и специальным проигрывателем воспроизводить (обычный проигрыватель будет читать только видео).
Собственно архив у китайцев так и работает, там и звук и события и собственно видео. При этом приёмная реалтайм часть вообще не заметит изменений. Трафик только подрастёт в зависимости от аппетитов подмешивателя 😁

tuskan
HardRock:

Могу ещё бесплатную идею подкинуть - таким же способом можно на лету подмешивать телеметрию в поток, обеспечивая тем самым высокую синхронность с картинкой в том числе на записи.

мне понравилось, что в китайской камере есть штатное выбрасывание компорта в IP
прямо в настройках камеры указываешь IP клиента и порт.
эдак камаера стоит 10 долларов, а MOXA конвертер 323/485 стоит 60 долларов

kasatka60
HardRock:

Могу ещё бесплатную идею подкинуть - таким же способом можно на лету подмешивать телеметрию в поток, обеспечивая тем самым высокую синхронность с картинкой в том числе на записи.

Ну это палка о двух концах. Кому-то удобнее иметь телеметрию отдельно от потока, темболее сначала пропадает видео, а потом телеметрия. Или вообще телеметрию гнать через пульт, так там еще дальнобойнее.

HardRock

Разумеется, каждое техническое решение должно применяться когда оно нужно и не применяться когда не нужно 😃

Кстати, тем кто летает с ИП камерами, стоит убедиться что звук выключен в настройках камеры. Это немного снизит поток. Точно не помню, вроде там по 160 байт несколько раз в секунду летит.

=Vlad
HardRock:

Всё слишком просто. Серьезно Хотя иногда бывает нужен паяльник и SPI программатор.

То есть когда у меня дрон летит в воздухе и мне нужно поменять параметр - мне нужен программатор?
Сильно. А я вот на пульте могу ручку покрутить и ИСО камеры изменится. Или выдержка. Или все что угодно. Для камер на распберри это очень просто

HardRock:

Это не имеет к воздуху ни какого отношения. TCP идёт от камеры к малине

Какая дремучесть.
вам бы для начала понять чем разные TCP/IP протоколы отличаются друг от друга. Но подозреваю что это вам будет сложно.

HardRock:

задержка получалась около 250мс - 300мс.

ПЦ (извините вырвалось)
У меня на 4G: камера - распберри - 4G - воздух- VPN сервер- воздух- 4G - ноутбук - меньше.
купив постоянный _один_ IP 4G адрес задержки можно снизить еще в 2 раза

HardRock:

Кардинальное отличие их закрытого протокола от RTSP

А чего вы уперлись в RTSP ? Кому он нужен и кто его рекламировал кроме вас?

schs:

Тут люди _используют_ оборудование, а не прошивки пишут.

Eсли вы не в курсе в какую тему пишете то OpenHD - это не прошивка.[quote=schs;8035771]

schs:

Тут максимум инкапсуляция сжатого потока происходит, без его обработки

Инкапсуляция аналога в H264 - это сильно )))

HardRock

У меня есть только один комментарий по изложенному выше: “иногда лучше молчать чем говорить” 😉

С другой стороны, нет ни чего зазорного в том чтобы чего-то не знать или заблуждаться.
Плохо когда теряется стремление к познанию истины, иногда противоречащей ранее сформировавшейся точке зрения.

=Vlad
HardRock:

нет ни чего зазорного в том чтобы чего-то не знать или заблуждаться.

Открою для вас несекрет.
Распберри на котором построен OpenHD - это полноценный линукс компьютер.
Примерно как ваш домашний на котором вы в игрушки играете, или ваш ноутбук. Но послабее.
Там все можно сделать. Хоть письмо послать маме или в DOOM поиграть прямо в воздухе. А уж управлять камерами - там все прекрасно в отличии от embedded китайских камер видеонаблюдения.

=Vlad
lelik:

Причем здесь OnVIF??? Какое отношение имеет RTSP к буферизации???

ой
Хоть один человек тут программирует?

DarkEye
=Vlad:

Там все можно сделать. Хоть письмо послать маме или в DOOM поиграть прямо в воздухе. А уж управлять камерами - там все прекрасно в отличии от embedded китайских камер видеонаблюдения.

Китайские IP камеры видеонаблюдения отлично управляются с Raspberry Pi пакетом python-dvr github.com/NeiroNx/python-dvr

HardRock

Кстати это и есть тот самый протокол. Реализовано не много (видимо автору только админские функции нужны были) , но в целом заход верный

=Vlad
DarkEye:

отлично управляются с Raspberry Pi пакетом python-dvr github.com/NeiroNx/python-dvr

спасибо, посмотрю

Шутка )))
однажды наши дроны будут хакать ( вскрывать) прям в полете и перехватывать root
все идет к тому и я не вижу проблеm
это серьезная проблема.