Сообщество LinuxTV (https://linuxtv.org/), занимающееся разработкой и поддержкой мультимедийных-подсистем в ядре Linux, совместно с некоторыми производителями камер, основало проект libcamera (http://libcamera.org), нацеленный на создание библиотеки для унификации поддержки и упрощения работы с видеокамерами, фотокамерами и TV-тюнерами в Linux, Android и ChromeOS. Предоставляемый библиотекой API со временем может заменить V4L2. Код проекта написан на C++ и распространяется (https://git.linuxtv.org/libcamera.git/tree/) под лицензией LGPLv2.1.В рамках представленного проекта разработчики намерены переломить текущую ситуацию в области поддержки камер для смартфонов и встраиваемых устройств, которые привязаны к проприетарным драйверам. Если в традиционных камерах операции первичной обработки изображений производятся на встроенном в камеру специализированном процессоре (MCU), то во встраиваемых устройствах для сокращения стоимости эти функции выносятся на плечи основного CPU и требуют усложнённого драйвера. Пользователи подобных камер поставлены в зависимость от закрытых драйверов от производителя и специфичных для них программных интерфейсов. Предоставляемый ядром Linux API V4L2 был создан в расчёте на работу с традиционными обособленными web-камерами и плохо адаптирован для появившейся в последнее время тенденции выноса функциональности MCU на плечи CPU.
В рамках проекта libcamera сторонники СПО и производители оборудования попытались создать компромиссное решение, с одной стороны удовлетворяющее потребности разработчиков открытого ПО, а с другой - позволяющее защитить интеллектуальную собственность производителей камер. Для обеспечения совместимости с существующими программными окружениями и приложениями предоставляются прослойки для обеспечения совместимости на уровне API V4L, Gstreamer и Android Camera HAL. В отличие от V4L2 предлагаемый библиотекой libcamera стек реализован целиком в пространстве пользователя.
Специфичные для каждой камеры проприетарные компоненты взаимодействия с оборудованием оформляются в виде модулей, выполняемых в отдельных изолированных окружениях и взаимодействующих с библиотекой через IPC. Модули не имеют прямого доступа к устройству и обращаются к оборудованию через промежуточный 3A API. Запросы через данный API проверяются, фильтруются и ограничиваются только обращением к функциональности, необходимой для управления камерой. В случае эксплуатации уязвимостей в закрытых компонентах камер, атакующие не смогут получить доступ к основной системе.Некоторые особенности (http://libcamera.org/docs.html):
- Предоставление алгоритмов для обработки и улучшения качества изображений и видео (корректировка баланса белого, устранение шума, стабилизация видео). Реализации алгоритмов могут быть как вынесены в проприетарные изолированные модули (например, алгоритмы автофокуса и выбора экспозиции), так и подключаться в виде открытых внешних библиотек;
- Возможности для управления захватом данных с камер на уровне отдельных кадров и синхронизации снимков с работой вспышки;
- Функции раздельной работы с несколькими камерами в системе;
- Возможности захвата одновременно нескольких видеопотоков с одной камеры (например, один с низким разрешением для видеоконференции, а другой с высоким разрешением для архивной записи на диск);
- API для определения списка имеющихся внешних и встроенных камер. Поддержки профилей устройств и обработчиков событий подключения и отключения камер. Предоставление структур с информацией о возможностях каждой камеры;
URL: http://libcamera.org"
Новость: https://www.opennet.dev/opennews/art.shtml?num=49776
Ребята изобрели webcamd из фряшечки :)
Плохо что на плюсах.
Я, конечно, не эксперт, но разве он не обеспечивает функционал только на уровне v4l?
Не совсем.webcamd содержит в себе линуксовые дрова для usb устройств:
- вебкамеры
- DVB тюнеры
- всякие аналоговые тюнеры / платы захвата
- клавы / мышки / джойстики
- мож ещё что то забыл, главное чтобы устройство было USB и другие подсистемы типа алса не юзало.Те webcamd цепляется к юзби девайсу, и "проксирует" в созданное им устройство для данного девайса.
Я им активно пользуюсь, и вебкамеры и джойстики и тюнеры и платы захвата - всё через него юзаю/поюзал.
ну тоесть как и V4L для автономных камер с собственным процессором
> ну тоесть как и V4L для автономных камер с собственным процессоромИ как прочие libinput и ко для устройств ввода в линухе.
Кстати почему webcamd должен с таким названием ДЖОЙСТИКАМИ заниматься - вот это интересно. И эти люди быкуют на системд...
> Кстати почему webcamd должен с таким названием ДЖОЙСТИКАМИ заниматься - вот это интересно. И эти люди быкуют на системд...Потому что системдуны, как обычно, осилили прочитать только название, не вникая в суть:
https://www.freshports.org/multimedia/webcamd
> kernel driver framework ...
> Webcamd is a small daemon that enables about 1500 different USB based webcam, DVB and remote control USB devices
>
> Плохо что на плюсахЭто ещё почему? Наоборот, это плюс
это плюс плюс
Даже два плюса :)
> Наоборот, это плюсдля кого плюс? для любителей напридмывать сложную иерархию классов? а потом на каждый чих эту всю иерархию переписывать занова..
и "улучшать" эту иерархию можно бесконечно -- прям кладезь для тех кому некуда тратить время :-) !
> Это ещё почему?
программы на выходе обычно получаются наколеночное говно -- вот по этой причине :-) .
на C явно более качественные разработки выходят, неговоря уже о том что весь нижележащий стек в GNU/Linux обычно выбирается тоже на C
А тут кто-то говорил о качестве? Работает и ладно.
> для кого плюс? для любителей напридмывать сложную иерархию классов?На C++ можно писать без сложной иерархии классов, это не обязательно.
На С++ все же программировать проще. Посему идеально было бы: Public API на C, внутренности на С++.
Just to notice:int c = something;
int cpp = c++;if (cpp > c)
std::cout << "C++ is better";
else
g_assert (0);-------
only a joke. C is the worst ;)
int something = INT_MAX;
С козырей?
А кто запрещает сесть и подумать над структурой иерархии классов перед тем, как начинать что-то кодить?
Чаще всего это два мужика: Даннинг и Крюгер
А на C люди видимо рефакторингом не занимаются? Не разбивают сложные функции на отдельные функции, не удаляют устаревшие. Они видимо всё пишут сразу. Видимо, типичный программист на C - это экстрасенс, способный видеть будущее. Он точно знает, что будет с его проектом, скажем, через 10 лет. Вы видимо так представляете себе C программистов. Если да, то у меня для вас плохие новости.
У них там есть issue трекер. Напишите им пока не поздно, что все уважаемые конторы пишут API на C,
а C++ дают как обертку над этим всем.Множество инструментов и биндингов пишут именно на C, а использовать сразу C++ для библиотек это отверунть от себя сразу кучу языков программирвоания и майнтайнеров.
Зачем это делать мне не понятно.
Я же не пользуюсь линуксом, уж лучше вы напишите.
> Я же не пользуюсь линуксом, уж лучше вы напишите.Поэтому вы за нами 2 дня бежали, чтобы рассказать что ваш webcamd тоже не решает упомянутых проблем, зато в джойстики умеет? :)
>>> Новость от opennews (ok), 13-Дек-18, 14:47
>> от Ivan_83 (ok), 13-Дек-18, 20:50
>> Я же не пользуюсь линуксом, уж лучше вы напишите.
> Аноним (90), 16-Дек-18, 15:45
> Поэтому вы за нами 2 дня бежали,Не 2, а 3. И не он, совсем не он.
// умилился очередной демонстрации перепончатых тяги к чрезвычайно избирательному восприятию.
> Ребята изобрели webcamd из фряшечки :)Сразу видно бсдшника - лишь бы ляпнуть что-то про свой фетиш. В каком месте d замена lib вообще? Это для начала разные подходы, если кто не заметил. Это раз. Два - а фря вообще с хоть какими-то камерами отличными от web работать вообще умеет? Особенно с той странной фигней которая в смартфонообразных штуках? Ну там MIPI какой, например, или параллельный интерфейс, или чего там еще такого. Это примерно как дисплей, только наоборот: HSYNC и VSYNC выдает камера, она же и данные пишет. При том эти данные могут быть достаточно лобовым дампом матрицы без особой обработки. Вот те попиксельный дамп, чего доброго еще и байеровский - и делай с ним что хошь.
Речь, вообще-то, идёт о подходе - процесс в юзерспейсе берет сырые данные от USB и уже сам достаёт из них картинку и звук, так что устранена необходимость пихать в ядро всё, до чего дойдёт сумрачный гений разработчиков камер.
С другой стороны имеем демон жрущий память и висящий там, вероятно, всегда. Независимо от того понадобится ли оно нам вообще или может юзер в пределах этой загрузки вообще камеру расчехлять не удумает. А lib что, если юзер все же запустит прогу работающую с камерой, ему lib вгрузится в адресное пространство как раз.
> А lib что, если юзер все же запустит прогу работающую с камерой, ему
> lib вгрузится в адресное пространство как раз.И эти проги конечно же не умеют вообще ничего, кроме работы с камерой и запускаются исключительно для работы с ней -- ведь в этой специальной реальности проги, особенно с обилимем мультимедии, до сих пор строго следовуют юниксовой философии "do one thing and do it well"!
> И эти проги конечно же не умеют вообще ничего, кроме работы с
> камерой и запускаются исключительно для работы с нейМистер когда-нибудь видел андроида? Ну так вот, приложение камеры запускается чтобы фоткать и снимать видео. А если это не планируется - тогда не запускается.
А юниксная философия зачастую довольно криво и погано работает в современном мире.
Аналогия в том, что дрова взяли и вытащили в юзерспейс.
В венде тоже так пытались сделать и запили отдельный сервис для этого, уж не знаю насколько подход прижился.
вот так тихо и незаметно функционал из нулевого кольца защиты проца мереезжает на 3-тье пользовательское кольцо...а где же крики о том, что микроядро не нужно?
Разница в том, что переезжает то, что может переехать, а в случае микроядра - можешь, не можешь - вали, и побоку накладные расходы или любые другие соображения.
Так и в случае сабжа будут накладные расходы. Вопрос только какие. А то потом выяснится, что оно поток от высокоскоростной камеры не успевает перехватывать....
...и тогда часть или всё уедет в ядро.
> ...и тогда часть или всё уедет в ядро.Однако ж запихивать в ядро какой-нибудь дебайер, или тем более стабилизацию видео - наверное тоже как-то перебор будет. Это уже явно в юзермод куда-то просится. Зачем крутить такой процессинг данных в ядре?
Это уже частности. Суть в том, что это, к счастью, не микроядро с его фанатизмом, а более прагматичный подход - что удобно держать в ядре - держим в ядре, что неудобно - выносим. И по мере изменения ситуации "удобное/неудобное" могут меняться. Кернельные ФС и FUSE - хороший пример. Кстати, не знаю, как насчёт стабилизации видео, а в дебайере в ядре ничего плохого не вижу. Тихая смирная алгоритмика как алгоритмика, ни на что сторонее не влияющая.Впрочем, судя по всему, здесь основная мотивация для выноса из ядра - желание обойти GPLv2 чтобы "защитить интеллектуальную собственность производителей камер", так что пожелаем смерти такому проекту.
> с его фанатизмом, а более прагматичный подход - что удобно держать
> в ядре - держим в ядре, что неудобно - выносим.Согласен. Поэтому какой-нибудь sshfs даже не выглядит дурно - он все-равно быстрым быть не может как таковой, из-за кучи шифрования, ремотности и вообще. Но вот локальный ФС намного лучше работает в кернеле. Что очень хорошо иллюстрируется ntfs3g, тормозным до икоты.
> в дебайере в ядре ничего плохого не вижу. Тихая смирная алгоритмика
> как алгоритмика, ни на что сторонее не влияющая.Алгоритмика может быть достаточно тяжелой, специфичной для матрицы и иногда требовать пересмотра/улучшений/апдейта. Апдейтить по этому поводу именно кернель - идея довольно дурная.
И кроме всего прочего в каком-нибудь андроиде в результате если можно юзермод либу подтянуть - подтянут, и всем станет хорошо с улучшенным процессингом. А ядро поттягивать могут и зассать, по крайней мере пока инициативы по коммиту всех андроидных фич в майнлайн не завершились. Так что фиг вам, дескать, а не улучшенный и ускоренный дебайер, дорогие пользователи.
> Впрочем, судя по всему, здесь основная мотивация для выноса из ядра -
> желание обойти GPLv2 чтобы "защитить интеллектуальную собственность производителей камер",Ну вот это не находит моего понимания. Да и какая там собственность я честно гря не понял. По крайней мере в V4L. Собственность обычно запихивают в свое приложение камеры, если уж хотели.
>> Впрочем, судя по всему, здесь основная мотивация для выноса из ядра -
>> желание обойти GPLv2 чтобы "защитить интеллектуальную собственность производителей камер",
> Ну вот это не находит моего понимания. Да и какая там собственность
> я честно гря не понял. По крайней мере в V4L. Собственность
> обычно запихивают в свое приложение камеры, если уж хотели.вот они хотят запихнуть в свой драйвер, точнее в "частично свой драйвер"
А fuse разве не такое практикует?
да, конечноно это тоже лишь очередной пример того же микроядерного процесса: перенос кода в на уровень пользователя для большей стабильности и прочих плюшек микроядра (даже если сами разработчики fuse на словах будут и против микроядерной архитектуры)
Однако ж NTFS работающий через это - в разы тормознее файлух в ядре и запросто упирается в ядро проца, а не что-нибудь еще. Что для файлухи как-то не прикольно....по этой причине я в стародавние времена угрохал у себя все NTFSы которые у меня были. Не прикольно, знаете ли, когда запись NTFS на диск 50 мегов в секунду, а ext4 - 120!
> а где же крики о том, что микроядро не нужно?Ну вот там. Одно дело перенести в юзермод то что там нормально работает и так лучше и вообще совсем другое - вообще все и принудительно. Как бы стабилизацию видео в ядре обсчитывать - идея вообще достаточно странная, например, не находите? Это как раз более уместно для какой-нибудь либы или слоя абстракции. И наверное в кернель столько вталкивать все же не надо.
да собсно, а IP пакеты фильтровать тоже обязательно в ядре?
правил ещё большая куча (была), а счас так вообще правила в байткод компилятся и выполнятся в вирт машине... этому всему точно место в 0 кольце обязательно?ну а блочные девайсы в запросы к винтам конвертить - это однозначно для 0 кольца задача... больше ж нигде это не сделать
> да собсно, а IP пакеты фильтровать тоже обязательно в ядре?Ну как бы гейтовать пакеты, особенно мелкие, в юзермод - неэффективно по переключениям контекста. Это тормозит. А в видео 30, ну может 60 крупных чушек в секунду. Совсем другой коленкор. Если б пакеты прилетали по 30 больших кусков в секунду, их тоже можно было бы в юзермод без напряга спихивать. А когда их многие тысячи в секунду прут и это нормальное состояние дел - опачки. При попытке это в юзермод спихивать файрвол/роутер/что там еще превратится в тормозитель прежде всего. А все остальное - потом.
> правил ещё большая куча (была), а счас так вообще правила в байткод
> компилятся и выполнятся в вирт машине... этому всему точно место в
> 0 кольце обязательно?Там проблема в том что гейтовать тысячи пакетов в секунду в юзермод - хреново по переключениям контекста. Если их группировать - загнется латенси. Вот и получается что и так плохо и эдак плохо. А линь о том чтобы работало все же хорошо, а не тормозило везде и всюду.
> ну а блочные девайсы в запросы к винтам конвертить - это однозначно
> для 0 кольца задача... больше ж нигде это не сделатьА там опять же потоки данных большие и скорость этих операций - критична. Если это в юзермод вынести, это сильно просядет и просядут очень многие нагрузки. И такая система внезапно окажется хуже конкурентов.
Но для извращенцев есть BUSE. Это как fuse, только для блочных устройств. Спрашивайте на гитхабе, или где оно там обитает.
да... увы, всё так
знать, дело за более быстрой железной поддержкой переключений контекста
> знать, дело за более быстрой железной поддержкой переключений контекстаКак вы себе это представляете с тем размером контекста который у современных cpu со всеми их плавучками и simd?
>> знать, дело за более быстрой железной поддержкой переключений контекста
> Как вы себе это представляете с тем размером контекста который у современных
> cpu со всеми их плавучками и simd?да хотяб сделать переключение контекста для вызова ринг0 и возврата через память на кристале
> Ну как бы гейтовать пакеты, особенно мелкие, в юзермод - неэффективно по переключениям контекста. Это тормозитуслышали мнение диванного АНАЛитика. А пацаны из dppk / NETMAP - об этом не знают, и пилят свое.
> услышали мнение диванного АНАЛитика. А пацаны из dppk / NETMAP - об
> этом не знают, и пилят свое.Так были б это микроядерщики - b не было бы у нас iptables/ipset/etс. А поскольку это Linux - вот для тех частных случаев когда это работает нормально они его и пилят. Не отбирая однако ж возможность пользоваться ядерного netfilter БЕЗ оптовых переключений контекста и факапов латенси. А не как замену где все дескать с ножом к горлу теперь гейтуют все пакеты в юзермод, и только так, выбирая между ломовыми переключениями контекста и буфферблоатом/факапом латенси.
systemd-webcamd - когда уже*?
soon...
Судя по поверхностному описанию, они умеют в архитектуру. Это обнадёживает.
Тут бы действовать от маркетинга. Например наши встроенные драйверы самые открытые и ссылка на покупки и шильдик на коробке красивый. И всё для Линукс юзаем только правильны производителей.
Расскажите пожалуйста этим поцам про github. От поделки https://git.linuxtv.org/libcamera.git/tree/ вытекают глазки.
Вот я не пойму. У гита самый удобный командный интерфейс. Откуда столько ноющих про вебинтерфейс?
Я не хочу консольку. Я хочу за пару минут пробежаться глазками по проекту с целью оценить масштаб разрушений. У меня лапки.
К ветеринарчику.
> Я не хочу консольку. Я хочу за пару минут пробежаться глазками по
> проекту с целью оценить масштаб разрушений. У меня лапки.Так пробежаться или страдать в веб-междумордие, дєвочка? :)
вот и выросло поколение, неспособное узнать cgit если его просто перекрасили в чорный цвет.
Вырасло мобильное поколение у которых планшеты вот и все,
а Вы продолжайте сидеть за уютными ламповыми шкафчиками
При любом раскладе планшет мозга не заменит.
> При любом раскладе планшет мозга не заменит.как это не заменит? Вот ты комментишь то, что написано экземпляром, у которого вполне заменил - и смотри, он даже может комменты на опеннет!
Програмить он всяко не сможет - поэтому учитывать его не обязательно. И если такой балласт отвалится, проект ничего не потеряет. Ну вот не привнесет ничего в проект тело которое с гитом только через вебморду работать может. Это просто данность. Поэтому с точки зрения проекта на это нытье можно забить и ничего при этом не потерять.
На кой тем, кто только потребляет контент (на планшетиках-то) гит?
> Вырасло мобильное поколение у которых планшеты вот и все,
> а Вы продолжайте сидеть за уютными ламповыми шкафчикамиПотреб-дей с планшетами можно с точки зрения програмизма спокойно слать в пешее эротическое путешествие. Просто потому что они с своих потреб-дских игрушек ничего не напрограммят - и соответственно от их посыла в задницу проект ничего не теряет. А как вы себе представляете занятие програмизмом на планшете в сколь-нибудь вменяемом виде?
> А как вы себе представляете занятие програмизмом на
> планшете в сколь-нибудь вменяемом виде?двигай пальцем формочки по экрану, делов-то!
Ну так пусть они где-нибудь в своей песочнице и двигают, рядом с ведерками и куличиками.
ух.. синий на чёрном.. програмист не дизайнер..
брутально
> ух.. синий на чёрном.. програмист не дизайнер..это не программист.
там кода нет
/* SPDX-License-Identifier: LGPL-2.1-or-later */
/*
* Copyright (C) 2018, Google Inc.
*
* main.cpp - libcamera main class
*/#include <libcamera/libcamera.h>
#include "log.h"
namespace libcamera {
void libcamera::init_lib(void)
{
LOG(Info) << "Lib Camera Init";
}};
этот стиль сайтов называется в народе "Брутальный стиль"
> Расскажите пожалуйста этим поцам про github.Опенсорсники неважно относятся к майкрософту, к тому же после покупки MS'ом гитхап почти наверняка скурвится и испортится. Ну типа как со скайпом было, так что теперь найти желающих использовать скайп еще ухитриться надо.
> http://libcamera.org/
> 2018 годСайт без HTTPS.
Держи фаталити:
http://www.academy.fsb.ru/index_i.html
Есть там https. Принудительного редиректа нет, и для сайта со статическими страницами это правильно.
в гугл пожалуйтесь, пусть им по попке надает
Linux: "А давайте снова выбросим известные API и наворотим новые, и пофигу, что 99% старых программ перестанут работать".// b.
Никуда они не перестанут, не переживайте. Как работали с v4l так и будут работать.
Да, ну и таки посмотрите вовнутрь https://git.linuxtv.org/libcamera.git/tree/include/libcamera...До "выбросим" этим поцам ещё пахать и пахать. Они в общем даже и не начинали. Эдакая РусОс.
Так что слухи о смерти v4l несколько преувеличены.
Сама инициатива, и актуальность подобного начинания показывает превосходство схемы поставки BSD (ядро + базовая система), против Linux (только ядро) для проприетарного вендора. Стандартизация API/ABI на уровне ядра со всякими EXPORT_SYMBOL_GPL не добавила нам открытых драйверов soft-камер, а наоборот усложнила поддержку и обновление софта на смартфонах и энтузиасту и самому вендору.Кстати, архитектура предполагающая вынос из ядра некритичных к производительности подсистем и перифирических драйверов устройств так же не нова, а уже много лет как используется в архитектуре Windows NT.
Сдаётся мне, что после того как Google активно начал вливать ветки Android в ядро, то такие изменения будут всё чаще и чаще. А если ядро на полном серьёзе внедрит kernel level IPC и вытеснит модули или их части в юзерспейс под управление cgroups, то можно переименовываться в Linux NT и начать новую нумерацию. =)
Для тех, кому "лишь бы работало и плевать как" есть винда, туда и катитесь. Хотя БСДшники уже там... А линуксовая схема оказывает хотя бы некоторое давление на производителей чтобы те открывали код.
> Для тех, кому "лишь бы работало и плевать как" есть винда, туда и катитесь.На самом деле это называется docker, и эта технология не от винды.
> А линуксовая схема оказывает хотя бы некоторое давление на производителей чтобы те открывали код.
Это давление существует только в Вашем воображении. Линуксовая схема скорее предоставляет больше возможностей интеграции и упрощении поддержки обновлений при использовании открытого кода, делая открытие кода финансово выгодным. Если же вендор делает на софтовом чипе всю обработку изображения и только в этом ключевое отличие от вендора-конкурента, то ничего он не откроет.
Пока вы рассказываете анонимам куда им там надо катиться, и кто там где, удачные технологии из этой самой ненавистной винды перетекают в линукс и наоборот,.. как будто в этом есть что-то плохое...
Там кода на сотню строчек, от силы, таких проектов "основывается" по десятку каждый день, и забрасывается через месяц.Может стоит на опеннете писать о проектах которые достигли состояния хотя бы пре-пре-тех-альфы?