Конечно очень хочется сделать одну прошивку, которая будет работать под всеми 3518, 3516 и 3519, но пока, судя по всему, нет даже способа программно определить разные сенсоры. Т.е. прежде чем заливать прошивку, надо точно знать, какой там сенсор.
Это как если бы надо было точно знать, какой линукс скачивать под распаянный на материнке жесткий диск, учитывая, что нет програмного способа его сдетектировать.
> как плохо масштабируемый и предъявляющий к железу камеры серьезные технические требования. Стоимость камеры, удовлетворяющий таким требованиям на входе: ~60-70$
…
> В традиционных решениях 'прошивка вендора + облачный плагин', которые не могут
> работать на дешевом железе, видео внутри камеры передается по протоколу RTSP — а это
> огромный оверхед
какие например? Очень интересно, как можно сделать _огромный_ оверхед на проксировании RTSP внутри камеры. У нас сделать огромный не получилось, наш агент для облака работает на камерах от $8 с шифрованием, проксированием и очень несложным процессом адаптации вендорской прошивки. По крайней мере он сильно проще, чем портирование целой прошивки под очередную комбинацию сенсор+чип+всё остальное.
>Наиболее уязвимый момент — перезапись раздела с ядром Linux и корневой файловой системой.
Угу. Поэтому её вообще часто не трогают никак. У вас прикольно получилось.
нестабильность потока с IP камер отчасти чинится агентом, софтиной которую мы ставим.
можно обойтись и без нашего агента, а поставить какой-нибудь ssh туннель, но здесь очень важно, что бы был L7 туннель, а не L2. Если поставить openvpn, то можно схлопотать очень серьезные накладные расходы при том же рассыпании картинки.
Я не оставляю надежду на то, что общением через i2c получится хотя бы косвенными способами угадать сенсор.
Конечно очень хочется сделать одну прошивку, которая будет работать под всеми 3518, 3516 и 3519, но пока, судя по всему, нет даже способа программно определить разные сенсоры. Т.е. прежде чем заливать прошивку, надо точно знать, какой там сенсор.
Это как если бы надо было точно знать, какой линукс скачивать под распаянный на материнке жесткий диск, учитывая, что нет програмного способа его сдетектировать.
Грустно.
…
> В традиционных решениях 'прошивка вендора + облачный плагин', которые не могут
> работать на дешевом железе, видео внутри камеры передается по протоколу RTSP — а это
> огромный оверхед
какие например? Очень интересно, как можно сделать _огромный_ оверхед на проксировании RTSP внутри камеры. У нас сделать огромный не получилось, наш агент для облака работает на камерах от $8 с шифрованием, проксированием и очень несложным процессом адаптации вендорской прошивки. По крайней мере он сильно проще, чем портирование целой прошивки под очередную комбинацию сенсор+чип+всё остальное.
>Наиболее уязвимый момент — перезапись раздела с ядром Linux и корневой файловой системой.
Угу. Поэтому её вообще часто не трогают никак. У вас прикольно получилось.
так всё просто: раз ничего не рассказываете, значит о вас ничего и не думают.
С таким требованием пора идти на пенсию.
Другой вопрос, что «чисто потестить» всё равно хочется что бы было попроще.
При этом SSH берет на себя буферизацию трафика.
В случае с OpenVPN вы получаете управление трафиком со стороны камеры и «баг которого нет» (см соответствующий бессмертный пост на хабре).
можно обойтись и без нашего агента, а поставить какой-нибудь ssh туннель, но здесь очень важно, что бы был L7 туннель, а не L2. Если поставить openvpn, то можно схлопотать очень серьезные накладные расходы при том же рассыпании картинки.
Та обертка для rust nif, которую я гонял, адски текла и ездила по памяти
Модули конечно штатные, равно как и ещё несколько утилит, без которых оно не взлетит