Комментарии 23
Основной недостаток такого подхода — зависимость от чужой инфраструктуры, ведь endpoint сервер всегда остается в вашей зоне ответственности. И установить у себя его нельзя по вашей политике.
А в целом продукт интересен.
А в целом продукт интересен.
как раз не так. endpoint здесь — это экземпляр флюссоника, который стоит у вас. Его адрес пишется в конфиг при первом запуске агента и потом агент ходит уже к нему, т.е. к серверу у вас.
Спасибо за ответ. Тогда разрешите более общий вопрос: Все ли элементы системы могут находиться у владельца сервиса? Если да, то мы с менеджерами Erlyvideo не поняли друг-друга.
на самом старте камера один раз идет к нам, что бы выяснить, куда идти дальше. Потом она уже общается только с вашими серверами.
Этот момент мы менять не будем, потому что зашивать в прошивку адрес клиента мы не будем. За все годы работы ни разу не было ситуации, что бы клиент с первого раза выбрал себе домен для камер раз и навсегда. Мы всем говорим, что надо выбрать и потом не менять, все говорят ага и меняют.
Этот момент мы менять не будем, потому что зашивать в прошивку адрес клиента мы не будем. За все годы работы ни разу не было ситуации, что бы клиент с первого раза выбрал себе домен для камер раз и навсегда. Мы всем говорим, что надо выбрать и потом не менять, все говорят ага и меняют.
Можете написать статью о том, как потрошить прошивки? Я пробовал разобраться с прошивкой одной глючной камеры, но ни с какими утилитами я не получил положительного результата.
Вы не сообщили производителя, модель и SoC камеры. Напишите, попробуем вместе.
От этого зависит и метод распаковки. Некоторые примеры были тут и на GT.
От этого зависит и метод распаковки. Некоторые примеры были тут и на GT.
если походить по ссылкам из статьи можно найти историю как разбирали и чинили прошивку на камере
habrahabr.ru/post/219537
habrahabr.ru/post/219537
Вот еще прекрасный образец — https://justpaste.it/1g3o2
Спасибо за статью, было достаточно интересно.
Сообщите пожалуйста, какого размера исполняемых файлов и библиотек вам удалось достичь?
Ведь не секрет, что в некоторых камерах места, ну как кот наплакал.
Свои задачи я решил путём интеграции в прошивки к камерам XM небольшой утилитки VTUNd, которая строит L2/L3 туннель на мой сервер, а китайское облако отключил. Ну и скриптов и утилиток еще докинул до кучи в прошивку.
Сообщите пожалуйста, какого размера исполняемых файлов и библиотек вам удалось достичь?
Ведь не секрет, что в некоторых камерах места, ну как кот наплакал.
Свои задачи я решил путём интеграции в прошивки к камерам XM небольшой утилитки VTUNd, которая строит L2/L3 туннель на мой сервер, а китайское облако отключил. Ну и скриптов и утилиток еще докинул до кучи в прошивку.
не занимаясь сжатием получается порядка 350 килобайт.
Туннель + шифрация + какие-то свои алгоритмы = 350k
Достаточно хороший результат. Мои искренние поздравления!
Достаточно хороший результат. Мои искренние поздравления!
Минусующих заело что-ли, что разговор пошел в техническую сторону? Повторюсь — указанный выше результат вполне хорош. Любой туннель с более-менее адекватной шифрацией для Embedded систем будет занимать не менее 160-220 килобайт.
Занимаюсь сейчас моддингом прошивок к камерам XM на базе SoC HI3518E, с интеграцией в камеры низшей ценовой категории, которые с флешкой 8 Mb, дополнительных возможностей в виде поддержки USB WiFi/Flash/3Gmodem, туннелей для создания своего «облака» (повторить сможет каждый на роутере/сервере с одним белым IP), подключения датчиков и исполнительных устройств. Так что немного «в теме» как достаточно непросто происходит там борьба за каждые свободные 50-10 килобайт.
Занимаюсь сейчас моддингом прошивок к камерам XM на базе SoC HI3518E, с интеграцией в камеры низшей ценовой категории, которые с флешкой 8 Mb, дополнительных возможностей в виде поддержки USB WiFi/Flash/3Gmodem, туннелей для создания своего «облака» (повторить сможет каждый на роутере/сервере с одним белым IP), подключения датчиков и исполнительных устройств. Так что немного «в теме» как достаточно непросто происходит там борьба за каждые свободные 50-10 килобайт.
на каких камерах экспериментируете с датчиками?
XM с SoC HI3518E v1 и v2
XM с SoC HI3516C
XM с SoC IPC 510A1
XM с SoC GM8135S
На данный момент вот такой моддинг пилю. Планирую метод сделать универсальным, под разные PCB. За основу взял специально самую дешевую и массовую плату, ну и относительно старую уже, конечно.
XM с SoC HI3516C
XM с SoC IPC 510A1
XM с SoC GM8135S
На данный момент вот такой моддинг пилю. Планирую метод сделать универсальным, под разные PCB. За основу взял специально самую дешевую и массовую плату, ну и относительно старую уже, конечно.
это перекликается с нашим Flussonic Iris. Он развивается не так быстро, как хотелось бы, но дело движется.
Мы полностью выкинули всё с камеры.
Мы полностью выкинули всё с камеры.
Оставили только модули ядра для матриц ;)?
Или Hisilicon поделился таки с вашей компанией исходниками под NDA?
Или Hisilicon поделился таки с вашей компанией исходниками под NDA?
не, исходниками не делятся даже на таобао =)
Модули конечно штатные, равно как и ещё несколько утилит, без которых оно не взлетит
Модули конечно штатные, равно как и ещё несколько утилит, без которых оно не взлетит
Под процессор IPC XM510 находили что-нибудь из документации?
Хочется камерам на их базе скриншоты научиться делать, но информации полный ноль. Может это просто какой-то перемаркированный чип?
Если кому интересно, поделки свои выкладываю тут
Хочется камерам на их базе скриншоты научиться делать, но информации полный ноль. Может это просто какой-то перемаркированный чип?
Если кому интересно, поделки свои выкладываю тут
я не знаю, за что минусуют, если честно.
Очень легко написать минимальнейший кусок кода, который работает на стенде, но мы поддерживаем большое разнообразие окружений (т.е. свой libevent, свой ssl), плюс к этому на некоторых камерах нам приходится добавлять юзера, ведь сейчас начали борьбу с мираи, поэтому надо тащить ещё обвязку к этому.
Очень легко написать минимальнейший кусок кода, который работает на стенде, но мы поддерживаем большое разнообразие окружений (т.е. свой libevent, свой ssl), плюс к этому на некоторых камерах нам приходится добавлять юзера, ведь сейчас начали борьбу с мираи, поэтому надо тащить ещё обвязку к этому.
Почему при ручном пробросе портов камера по RTSP будет отдавать рассыпающуюся картинку?
Не принимайте это утверждение дословно.
Просто при пробросе портов камера может отдавать картинку, которая будет рассыпаться. Дело в том, что во многих камерах бинарник, который является RTSP сервером еще выполняет кучу дополнительных функций и старые прошивки, особенно, работают на грани фола. И каждый «чих», в данном случае трансляция адресов, пусть и не на самой камере, вносит некий дисбаланс в эту хрупкую конструкцию. Выше давали ссылки на статью, там всё достаточно хорошо и подробно объясняется.
Просто при пробросе портов камера может отдавать картинку, которая будет рассыпаться. Дело в том, что во многих камерах бинарник, который является RTSP сервером еще выполняет кучу дополнительных функций и старые прошивки, особенно, работают на грани фола. И каждый «чих», в данном случае трансляция адресов, пусть и не на самой камере, вносит некий дисбаланс в эту хрупкую конструкцию. Выше давали ссылки на статью, там всё достаточно хорошо и подробно объясняется.
да, есть статья про баг, которого нет.
Если вкратце, то ситуация такая: китайские программисты обнаружили что если слать видео по TCP, то сокет начинает блокироваться и возникают дропы фреймов на захвате. А потом они обнаружили, что если перевести сокет в неблокирующий режим, то блокировки и дропа fps не будет. Но при этом не сделали всю ту обвязку, которая нужна вокруг неблокирующих сокетов.
Поэтому если хоть чуток проседает сеть (а это бывает в 99,9999999% случаев), то большие кадры (кейфреймы т.е.) при моментальной отправке в сеть частично теряются юзерлендом на камере. Бороться с этим чрезвычайно сложно.
Если вкратце, то ситуация такая: китайские программисты обнаружили что если слать видео по TCP, то сокет начинает блокироваться и возникают дропы фреймов на захвате. А потом они обнаружили, что если перевести сокет в неблокирующий режим, то блокировки и дропа fps не будет. Но при этом не сделали всю ту обвязку, которая нужна вокруг неблокирующих сокетов.
Поэтому если хоть чуток проседает сеть (а это бывает в 99,9999999% случаев), то большие кадры (кейфреймы т.е.) при моментальной отправке в сеть частично теряются юзерлендом на камере. Бороться с этим чрезвычайно сложно.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Flussonic Agent — прошивка для камер