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

kak-dela007
HardRock:

Почему не рассматривается вариант с USB хабом?

Как тут верно аметили, USB- камер в мелком размере нет хороших за разумную сумму. А IP-камер на али довольно большое разнообразие. Вот и смотрю на Ethernet

schs
kak-dela007:

А Стивен не сказал, это можно вылечить? Видел, вы вроде в телеграм кидали видео о вашем сетапе…

Ему не до этого, сосредоточился на новом железе\софте. Вылечить можно, ибо передача _уже_ сжатого потока - несложная задача.

Только вот как обычно - те, кто умеет им некогда, кому хочется - не умеют 😃

kak-dela007:

А вот смотрите, какая платка компактная есть

По ссылке фото

raspi.tv/wp-content/…/ethernet-portsplus_700.jpg
Почти как zero

kak-dela007:

Как думаете, заработает?

Скорее всего да, только вряд ли это чем то поможет.
Поток с камеры 3-4Мбит, больше радиканал не даст, без увеличения полосы и уменьшения расстояния.
Считаем 3 пришло, 3 ушло на свисток, итоговая загрузка шины USB 6 Мбит, что для неё совсем не о чём.
То есть не тут затык.
Хотя польза может быть от разгрузки контроллера USB.

kak-dela007:

Но я бы попробовал.

Попробуйте, отпишите. Плата эта есть, но пробовать не буду, не верю в результат.

HardRock:

Почему не рассматривается вариант с USB хабом? Например таким

Спасибо за ссылку на безразъёмный, я потрошил корпусные мелкие.
С хабом подключить можно, я чуть выше писал, но вот процессора не хватает, как то сильно неудачно gststreamer забирает поток.

HardRock
kak-dela007:

Как тут верно аметили, USB- камер в мелком размере нет хороших за разумную сумму. А IP-камер на али довольно большое разнообразие. Вот и смотрю на Ethernet

Имелось ввиду хаб + USB-Ethernet и в камеру. Это самое простое и одновременно дешевое решение.
Ещё есть вариант AHD камера + AHD-HDMI конвертер. Это уже не дешево (конвертер), зато AHD камер выбор больше чем всех остальных вместе взятых 😃
Хотя за сумму в 3+тр наверно можно найти нормальную USB h264 камеру. Их не тестировал, не знаю.
Пробовал только MJPEG камеру, но там динамический фреймрейт был и это грустно.

schs
kak-dela007:

А вот смотрите, какая платка компактная есть

Из статьи:
Speed Test Results

Pi Zero at 12 MHz 3.33 Mbaud down, 2.82 Mbaud up, 39.956 ms latency, 52.19km
Pi Zero at 16 MHz 3.67 Mbaud down, 2.90 Mbaud up, 37.749 ms latency, 43.57km
Pi Zero at 20 MHz 3.88 Mbaud down, 3.10 Mbaud up, 42.474 ms latency, 43.57km
Pi2 with ethernet onboard 74 Mbaud down, 5.86 MBaud up

То есть в лучшем случае сию удовольствие даст ~3Mb

kak-dela007
schs:

Pi Zero at 12 MHz 3.33 Mbaud down, 2.82 Mbaud up, 39.956 ms latency, 52.19km
***
То есть в лучшем случае сию удовольствие даст ~3Mb

Километраж то внушительный! Я согласен на такое)) А вот эти мегаГерцы что значат? Где-то выставляются?
Т.е., получается такая схема с низким битрейтом только для дальнолёта подходит

schs:

Почти как zero

Нене, там на Али 2 варианта, одна обрезанная по самый чип почти

=Vlad
kak-dela007:

А IP-камер на али довольно большое разнообразие.

Только они все китайские кривые и работают только через свой софт.
Нормально не настраиваются и не управляются, картинка до ужаса перешарплена, ОСД поверх видео не наложишь.
Более менее прямые отдают RTSP протокол, но китайцы не факт что отдадут RTSP хотя это заявлено. Моя IMX291 не отдает, фиг знает что там в ее кривой прошивке нагородили.

Все эти “IP камеры” это тривиальные камеры для китайского видеонаблюдения.
Качество картинки и баги исполнения не сложно представить.
Я купил себе две таких, на IMX291 и SmartSence матрицах. Готов отдать в 2-3 раза дешевле чем купил. Вот только они и даром никому такие не нужны.

HardRock:

Ещё есть вариант AHD камера + AHD-HDMI конвертер.

И забудьте про качество и детализацию картинки.
Она и так будет очень низкая, а уж после второй конвертации в h264 - просто никакое мыло. Хуже аналога.
И смысл городьбу городить?

khomyakk

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

schs
=Vlad:

Только они все китайские кривые и работают только через свой софт.

Вы похоже совсем не в теме.

=Vlad:

Нормально не настраиваются и не управляются, картинка до ужаса перешарплена, ОСД поверх видео не наложишь.

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

=Vlad:

Качество картинки и баги исполнения не сложно представить.

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

=Vlad:

Она и так будет очень низкая, а уж после второй конвертации в h264 - просто никакое мыло. Хуже аналога.

Вы опять не в теме. Зайдите в фирмочку, занимающуюся видеонаблюдением и попросите показать картинку с AHD камеры.

kak-dela007:

Т.е., получается такая схема с низким битрейтом только для дальнолёта подходит

Не для чего не подходит.

HardRock:

зато AHD камер выбор больше чем всех остальных вместе взятых

Тут Вы не правы, IP камер всё же больше хороших, и они отдают _уже_ в h264/h265, без отдельной и большой платы, требуемой для AHD

HardRock:

Хотя за сумму в 3+тр наверно можно найти нормальную USB h264 камеру. Их не тестировал, не знаю.

В эту сумму нормальных немного.

kak-dela007:

Километраж то внушительный! Я согласен на такое)) А вот эти мегаГерцы что значат? Где-то выставляются?

Смотрите на скорость, по SPI у человека получилось всего около 3Мбит против 74Мбит у порта на PI2.
Я не проверял этот вариант.

HardRock
=Vlad:

Только они все китайские кривые и работают только через свой софт.

Ещё семь лет назад я отреверсил их протокол NETIP для камер на Hisilicon и CMS соответственно. Позволяет управлять камерой и забирать потоки. Даже перепрошивать можно)
Задержка сильно меньше RTSP, оверхед тоже. Там идёт просто h264 поток без какой либо обертки. Звук также инкапсулирован в h264 NAL’ы. Идёт по TCP. По сути поток с аппаратного энкодера сразу отправляется в сеть без всей этой монструозной хрени в виде OnVIF + RTSP и миллиона промежуточных буфферов.

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

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 китайских камер видеонаблюдения.