Как я вас понимаю… Практически со всем сказанным довелось столкнуться… А уж сколько это времени съедает… — прорву. Даже для самого что ни на есть примитивного проекта…
P.S. Есть в активе проект с пятьюстами звездами на гитхабе… и парочка помельче…
А еще можно использовать комментарии коммитов вида `fixup! комментарий коммита в истории`, и при `rebase -i --autosquash` коммит так-же переедет в нужное место.
Этим удобно пользоватья из `gut gui`.
Действительно не дорого. Но опять же, получается это вопрос масштаба. У вас есть возможность делать для себя некую специальную железяку (пусть и на неком более менее стандартном железе), у меня же такой возможности, к сожалению, нет. Вот и приходится, на этом этапе, выбирать из массовых устройств.
> H264 в браузере проигрывается, но для этого его надо упаковать в контейнер.
Да, я об этом и говорю, .ts (для HLS) и .mp4 (для DASH) можно готовить непосредственно на RPi, благо перепаковка не сильно ресурсоемкая задача. Вопрос только в быстродействии дисковой подсистемы. Тем более что если реализовывать выгрузку в DropBox или другие облачные хранилища, перепаковку в любом случае делать придется. Да и гарантированную доставку проще сделать для нескольких мелких файлов, чем для одного большого. Так что HLS для этой задачи очень неплох.
> С малинкой главная и основная проблема: это настольная платка для которой нет массово доступного корпуса.
Тут вопрос масштаба. На первоначальном этапе можно вполне обойтись корпусами отпечатанными на 3d принтере, либо нарезанными из пластика на лазерных станках. А при больших объемах можно и на заводе в китае заказать (но конечно же до этого еще дорасти надо).
А по поводу уличного исполнения — в любом случае камеры будут работать через некий роутер, его же вы не будете на улице крепить, соответственно не проблема рядом еще одну коробочку поставить.
С этим тезисом согласен. Но надеюсь этот недостаток перекрыть более широким функционалом, например из того что забыл упомянуть:
Возможность загрузки видео в облачные хранилища общего назначения, такие как DropBox, Google Drive, Microsoft OneDrive. Да и тот же iVideon в конце концов (если дадут доступ к SDK конечно);
Возможность шифрования видео, через ту же PKI (надеюсь мощности RPi для этого достаточно, еще не проверял);
Опять же, h264 стрим в браузере без костылей не проиграть, поэтому можно проводить конвертацию перед отправкой, например в набор .mp4 файлов;
Реализация гарантированной доставки через медленные/ненадежные каналы (например GSM модем, но тут, возможно, без детектора движения уже не обойтись);
Абсолютно правильные тезисы. Не так давно я сам задумался над решением обозначенной в статье проблемы. Рассматривал разные варианты, в частности установку некоего агента на камеру, но в конечном итоге отказался от этой идеи.
Причины следующие:
Зоопарк камер. Неизвестно с какой камерой придет клиент. Неизвестно какая будет у нее аппаратная ревизия. Неизвестно какая будет ревизия программного обеспечения. Тестировать все варианты — смерти подобно.
Зачастую камеры имеют ограниченные вычислительные возможности. Да и с памятью у них зачастую все печально, как оперативной так и флэш.
Могут встретиться камеры на которых агента подсадить будет проблематично. Тем самым ограничиваем себя и пользователей по ассортименту.
С большой долей вероятности агента на камеры придется ставить самому, т.к. объяснить пользователю как это делать, с большой вероятностью, будет нереально. Для Москвы/Питера/иного-региона-присутствия это может и не сильно большая проблема, но с удалением от столиц проблема становится все острее. В итоге все может вылиться в решение используемое iVideon, а именно работа с производителями камер и предоставлением им некоего sdk. Но опять же, нельзя будет прийти в магазин и купить первую понравившуюся камеру.
… возможно что-то еще о чем подзабыл...;
В конечном итоге я решил идти по иному пути. Взять Raspberry Pi 3, и реализовать агента на нем.
Почему так:
RPi 3 имеет wi-fi на борту, камеры можно подключать через wi-fi;
ARM устройства кушают мало, греются относительно слабо, имеют относительно компактные размеры;
RPi 3 очень хорошо оттестированная железяка, кроме того на начальном этапе нет необходимости заморачиваться с проектированием своего собственного устройства, т.к. это имеет смысл только при больших тиражах;
RPi более производителен чем типовая IP камера (4 ядра все-таки);
RPi относительно дешев;
Можно использовать мощные библиотеки типа GStreamer, и не ограничивать себя только камерами умеющими RTSP;
VPN не обязателен, можно обойтись SSL/TLS;
… возможно что-то еще о чем подзабыл...;
Для упрощения первоначального конфигурирования хочу сделать простенький сервис к которому устройство подключаться при включении и получать всю конфигурацию с него. Соответственно пользователь конфигурирует устройство подключаясь к веб сайту в интернете/интранете, а не непосредственно к устройству.
Может возникнуть вопрос зачем я это все написал — ответ простой, хочу услышать критику.
Ну а если у вас все же возникнут проблемы в этом вопросе, то как говориться «Хочешь написать node.js addon — спроси меня как». Мне волей не волей пришлось съесть собаку на этой теме :)
Хочется поделиться ссылкой на проект который может оказаться весьма полезным для желающих написать свой С++ Addon для Node.js (впрочем как и для NW.js и Electron): cmake-js — данный проект позволяет использовать CMake в качестве системы сборки вместо node-gyp. Проблема в том что для большинства сторонних библиотек .gyp файлы придется писать самостоятельно (а зачем еще может понадобиться написание C/C++ addon кроме как для подключения сторонней библиотеки?), в то время как с CMake шансы избавить себя от дополнительной работы весьма высоки.
Не исключаю такой возможности, в моем случае надписи пока держатся с конца 2012 года (Filco Majestouch 2 Tenkeyless cherry mx brown, куплена в KeyboardCo), клавиатура сначала использовалась дома, и в течении последнего года на работе.
Стоит иметь в виду что, через некоторое время использования, текстура на клавишах сотрется и они станут идеально гладкими (на наиболее используемых участках). Но в то же время, как ни удивительно, надписи при этом не стираются, несмотря на очень интенсивное использование клавиатуры.
А можно немного больше информации о вашем плагине? Я сам являюсь разработчиком одного Open Source браузерного плагина и пользователи с каждым днем все настойчивей и настойчивей спрашивают про перспективы проекта в контексте запрета NPAPI в Chrome. У нас есть некоторые идеи как обойти эту проблему, но все они обладают большим количеством недостатков. В моем случае проблема еще осложняется тем что плагин предназначен для воспроизведения видео, соответственно просто запустить его в фоне и общаться с ним через WebSockets не получится…
> Хорошо, что они отказались от наклеек — они быстро истираются, фиг буквы разберёшь.
Мне понравилось решение на одном из ноутбуков (если не ошибаюсь на HP ProBook) — лицензионная наклейка там находилась под аккумулятором. Согласитесь, шанс уничтожить ее там сопоставим с шансом уничтожить весь ноутбук целиком…
P.S. Есть в активе проект с пятьюстами звездами на гитхабе… и парочка помельче…
Этим удобно пользоватья из `gut gui`.
Но неужели нет конкурентов?
Этого самого роутера
А так подход возможно правильный, другой вопрос что не будут ли пользователи возмущаться ограниченностью выбора.
Да, я об этом и говорю, .ts (для HLS) и .mp4 (для DASH) можно готовить непосредственно на RPi, благо перепаковка не сильно ресурсоемкая задача. Вопрос только в быстродействии дисковой подсистемы. Тем более что если реализовывать выгрузку в DropBox или другие облачные хранилища, перепаковку в любом случае делать придется. Да и гарантированную доставку проще сделать для нескольких мелких файлов, чем для одного большого. Так что HLS для этой задачи очень неплох.
> С малинкой главная и основная проблема: это настольная платка для которой нет массово доступного корпуса.
Тут вопрос масштаба. На первоначальном этапе можно вполне обойтись корпусами отпечатанными на 3d принтере, либо нарезанными из пластика на лазерных станках. А при больших объемах можно и на заводе в китае заказать (но конечно же до этого еще дорасти надо).
А по поводу уличного исполнения — в любом случае камеры будут работать через некий роутер, его же вы не будете на улице крепить, соответственно не проблема рядом еще одну коробочку поставить.
Причины следующие:
В конечном итоге я решил идти по иному пути. Взять Raspberry Pi 3, и реализовать агента на нем.
Почему так:
Для упрощения первоначального конфигурирования хочу сделать простенький сервис к которому устройство подключаться при включении и получать всю конфигурацию с него. Соответственно пользователь конфигурирует устройство подключаясь к веб сайту в интернете/интранете, а не непосредственно к устройству.
Может возникнуть вопрос зачем я это все написал — ответ простой, хочу услышать критику.
Хочется поделиться ссылкой на проект который может оказаться весьма полезным для желающих написать свой С++ Addon для Node.js (впрочем как и для NW.js и Electron): cmake-js — данный проект позволяет использовать CMake в качестве системы сборки вместо node-gyp. Проблема в том что для большинства сторонних библиотек .gyp файлы придется писать самостоятельно (а зачем еще может понадобиться написание C/C++ addon кроме как для подключения сторонней библиотеки?), в то время как с CMake шансы избавить себя от дополнительной работы весьма высоки.
Мне понравилось решение на одном из ноутбуков (если не ошибаюсь на HP ProBook) — лицензионная наклейка там находилась под аккумулятором. Согласитесь, шанс уничтожить ее там сопоставим с шансом уничтожить весь ноутбук целиком…