Pull to refresh

Comments 45

ща, статью откорректирую и на ICO =)
image
К сожалению качеством лучше не нашел, но всё же!
Интересно было бы почитать о проблемах, возникающих при программировании на расте
хорошо, постараюсь написать. Они, конечно, есть.

Мяса, мяса давай! А то сплошные байки из склепа. Так-то все понятно, но со стороны — информации ноль.

а где у них опенсорсная прошивка?

Ух, обещали но так и нет.
Тогда как sigrand :)

да и у сигранда негусто https://github.com/sigrand
Сигранд тут живёт: git://sigrand.ru/sigticam.git
ты прям озадачил. Надо подумать, не будет ли здесь проблем от третьих сторон.

Было бы интересно про опыт использования tokio в более подробном изложении.

хорошо. Там есть некоторые ньюансы, связанные с tokio_io::codec и его обходом.
Rust очень хорош, вот прямо очень. ЛУчший язык придуманный за последние 10 лет.
Не могу назвать его лучшим в принципе, но в нише «плати только за то, что используешь» — таки да. Всё постельные приличные языки, изобретённые за последние 10 лет, требуют «тяжёлого» рантайма — независимо от того, какие фишки этого рантайма ты используешь, какие — нет.
Назовите тогда лучший.

Ну не бывает же чего-то абсолютно лучшего, без контекста. Только в своих нишах, только при таких-то требованиях.

Это как то мешает делать выбор и сравнивать? Есть куча параметров независящих от контекста и требований.

"Лучший" — это же значит что я в любой ситуации этот язык предпочту всем остальным, так?


Лично мне сильно мешает — я на вопрос "назови лучший язык" вообще ничего не могу ответить. Для меня в любом случае контекстно зависимые факторы будут весомей абсолютных. Как бы я не любил ржавчину, все равно на практике я для разных типов проектов могу посчитать на данный момент более подходящими и си, и плюсы, и хаскель, и питон и еще что.

Люди когда придумывают язык, они знают о конкретных ваших ситуациях? Как же они без этого всего решения выбирают?
P.S. так как этот пидорский сайт не дает оставлять комментарии тогда, когдя я хочу, то дискуссию я пожалуй продолжать не буду.

Блог — очень плохой способ структурировать редкую информацию, вроде описанной… Хорошо для апдейтов, плохо для впитывания.

Согласен. Но для тех, кто в такие темы погружается набегами, в качестве хобби, любая информация полезна. Я просто недавно искал замену C++ в для своего маленького проекта на STM32 и без этого блога я бы самостоятельно Rust на голом STM32 не осилил бы.
Очень интересно. Но очень мало :)

Единственный момент который меня озадачил
В большинстве случаев там стоит обычный линукс, причем частенько с дефолтным рутовым паролем,

Впервые слышу про дефолтовый рутовый пароль у линукса.
> дефолтовый рутовый пароль

у данного типа устройства он дефолтный, один на всех.

Ну и про «обычный линукс» это сильное преувеличение.
не, реально это достаточно обычный билдрутовый линукс.

Просто в отличие от достаточно сильно развитого openwrt в котором есть пакеты, тут всё сильно попроще, потому что почти вся система readonly.

если перед вами ssh (чаще telnet) к IP камере, то в 80-95% случаев вам поможет один из примерно 40 известных паролей.

Очень сложно организационно сменить пароль на камере при её установке.
Есть ли шанс заиметь вашу ржавчину чтоб поставить самому? Уж очень печальная там родная прошивка. Приходиться танцы с бубном устраивать чтоб получить вменяемый rtsp/h264
есть такая масса способов превратить вашу камеру в кирпич, что вы должны быть твердо уверены в себе для этого на текущем этапе.

Начните с фотографии процессора на камере. Если там что-то типа hi3518 или 3516, то шанс есть, но нужны все буквы. Так например 3516c и 3516a несовместимы вплоть до загрузчика.
наверное лучше даже по-другому: у вас есть оригинальная прошивка от вашей камеры?
Должна где-то быть, у меня две камеры, одна сейчас лежит без дела. А так же, насколько я помню, у меня hi3518e. Ваш cpuinfo очень похож на то, что я видел у себя но надо будет перепроверить
если найдете — попробуем помочь
Сравнил cpuinfo — один в один.
прошивка текущая — V4.02.R12.00006510.10010.140700.00000 / HI3518E_50H10L_S39
Вот такое нашел когда-то на просторах интернета. + есть бинари с прошивкой за июнь 2016 и сентябрь 2014
Только что-то я перемудрил в прошлый раз с их CMS и теперь не могу по телнету на камеру попасть.

И для интересующихся вот много ссылок на всякое разное по этим китайцам.

Какого размера в тоге получились исполняемые бинарники? По умолчанию же они выходят достаточно жирные.

Три года назад работал в компании, предоставляющей набор охранной системы для частников — это набор беспроводных датчиков и базовой станции, которая общается с «центром» через GSM/3G и имеет бекапную батарейку (грабители обычно обесточивают дом, обрезают телефонную линию, разбивают панель ввода пинкода, думая, что он посылает сигнал тревоги). Я разрабатывал для них IP камеру (прошивку на основе hi3518 и Ambarella A5s/S2Lm) и серверную часть. SDK обычно предоставляет высокоуровневый RTSP/RTP стриминг, но я брал с уровня NAL h264 фреймов и запихивал в пропраетный протокол. Общение камеры с клаудом по типу dropcam, основан на TLS соединении (каждая камера имеет свой сертификат с UUID, подписанный единым CA, что авторизует каждую камеру, и сертификат сервера может быть проверен тоже с помощью CA паблика вшитого в камеру), и протокол на основе protobuf. Серверная часть C++ Boost::ASIO позволяет держать десятки тысяч одновременно подключенных камер на один сервер (стриминг происходит по активации со стороны приложения или по срабатыванию датчиков в доме).

Интересная тема с просмотром live и записанном видео в браузере и в мобильных клиентах. На Android и iOS мы можем просто скармливать NAL фреймы фреймворку и сама OS будет проигрывать видео, т.е. транспорт полностью может быть пропраетным. С браузерами не всё так просто, либо flash, либо html video tag. Хотя есть вариант плагинов, типа VLC для браузеров, чтобы проигрывать RTSP/RTP потоки, или какой-нибудь ActiveX — но это уже сильно устарело.

HTML5 video отлично проигрывает HLS и MPEG-DASH во всех современных браузерах, но live video запаздывает на величину 2х-3х сегментов, которые скажем по 2 сек, значит на 4-6 секунд. Мы же хотим видеть live именно live с минимальной задержкой (как в RTSP/RTP). К сожалению, я выбрал вариант Flash и с сервера лил файлы FLV просто потоком, который сразу же проигрывался. FLV формат супер прост, пихаем h264 NAL и AAC фреймы и всё. На мобильных клиентах мы написали простой FLV парсер и скармливали NAL и AAC фреймы системе.
С браузерами не всё так просто, либо flash, либо html video tag.
Вы смотрели в сторону Media Source Extensions? Мне кажется, он отлично подходит для вашего случая.
На википедии такое примечание даже:
Unreal HTML5 player uses MSE for low latency (sub-second) live playback of streams sent via WebSockets by Unreal Media Server
Нет, тогда MSE прошло мимо нашего радара. Да и сам html5 video tag был немного в диковинку, точнее список видео/аудио кодеков и контейнеров, которые поддерживаются тем или иным браузером. Как минимум мобильные браузеры не могли тогда играть html5 video, не знаю как сейчас. Кстати, AAC аудио кодек тоже немного не для нас, мы всё делали в Speex (потом стал opus). Speex хорошо жмёт голос, а не музыку, предоставляя лучший битрейт. FLV может содержать Speex. Ничего такого из html5 video не могло содержать speex.
P.S. Сейчас я мало знаю про техническую сторону того проекта, уже почти два года в другой компании.
Теперь уже OPUS в браузерах поддерживается почти повсеместно, как и webm с VP8/9. YouTube по умолчанию отдает webm VP9 + OPUS разными файлами, объединяя их через Media Source Extensions.
Sign up to leave a comment.