это точно не выйдет - контроллер DMA у tw6869 не поддерживает Blit - вставку прямоугольной области в произвольную позицию другой прямоугольной области памяти.
тут прямой и очевидный путь - написать свой плагин для Gstreamer с нужной обработкой изображения с учетом особенностей gstreamer-imx. Понятно что не имея такого опыта ранее можно встрять надолго, Ноя бы начал именно с этого - не так уж там все страшно.
Понял. То что вставить прямоугольник не получится - предсказуемо.
А в линейной модели памяти? Т.е. слепить кадр за кадром последовательно посредством того что все DMA транзакции пишут в идущие друг за другом куски памяти?
Спасибо за наводку, буду альтернативно смотреть насколько это тяжело.
Подправить драйвер v4l2loopback? Или речь про плагин v4l2sink?
Перефразирую: с учетом входного интерлейсинга это будет кадр вида:
[1 канал нечетное поле] [1 канал четное поле]
[2 канал нечетное поле] [2 канал четное поле]
[3 канал нечетное поле] [3 канал четное поле]
[4 канал нечетное поле] [4 канал четное поле]
Т.е. 4 поля слева, 4 справа. На первый взгляд вполне удобоваримо.
Есть надежда что подав все это в GPU можно будет аппаратно посредством шейдеров сделать деинтерлейсинг в стиле blending, и сразу отрендерить в нужном виде с коррекцией геометрических искажений.
Тем более что как я понимаю сейчас в памяти даже один кадр с TW6869 составлен из отдельных кусков Y и UV, которые вроде как традиционно располагаются друг под другом (поправьте если не так).
мне только непонятно - для чего все это если есть готовый композитор ? под вашу хотелку надо драйвер полностью переписывать причем сути это не поменяет - вам все равно надо писать плагин для коррекции, деинтерлейсинг проще до ума готовый довести - аппаратный на IPU, после композитора один поток и с ним уже можно любой режим использовать.
Кстати, я правильно понимаю что проблема только в том чтобы данные в свое приложение забрать из конвеера Gstreamer ? По-моему вам просто нужен
Да, теперь уже понятно что так проще, спасибо за ценную информацию. Без вас бы не разобрался.
Для чего - лелеял надежду что смогу просто взять поток с этой виртуальной счетверенной камеры как с обычного /dev/video и дальше обрабатывать посредством OpenCV к которой привык. Думаю не одному бы мне это пригодилось - можно было бы умное детектирование движения делать для нескольких камер, обнаружение заданных объектов и т.п.
На той же RaspberryPi данный подход работает на ура и с неплохой производительностью. А вот на iMX получается что адекватной производительности можно добиться только использованием аппаратных средств на всех этапах.
Да, именно через appsink я и подаю поток с камеры в OpenCV (если не использовать стандартный подход с /dev/video, мечты о котором и были выше). Одна из проблем тут в том что перед appsink приходится обязательно втыкать плагин videoconvert. А в gstreamer-imx он как я понимаю работает на основе CPU, и на 4-х каналах все это захлебывается еще только на этапе захвата. А мне еще обработку делать надо. Да и подозреваю что если разбираться как работает appsink то там memcpy внутри. В общем данный вариант отпал.
Еще сразу маленький вопрос в эту тему - а какой ваш драйвер для TW6869 можно считать последним? Тот что на github?
Поясню - я использую драйвер который идет в поставке buildroot-2017.08-sk. Но он дает мне синий экран при отсутствии сигнала (что хорошо).
Однако наткнулся на тему 2016 года http://www.starterkit.ru/html/index.php?name=forum&op=view&id=26029 где есть такой текст:
Еще помню была тема что проблему с четным-нечетным полем предложили решать опросом i2c регистров чипа перед началом захвата, и были патчи драйвера под это без отбивки помогло или нет.
Т.е. какой все же драйвер и с какими патчами следует использовать?
извините но я не верю даже если вы ошиблись с версией (в RPi3 64 битный cortex-a53), opencv продвигает Intel основной продукт которой - десктопные/серверные процессоры с соответствующим потреблением
это суть любой SoC с CPU ARM - чудес не бывает
я думаю по-другому
неправильно думаете - посмотрите пример vcv4.sh (в части imxipuvideotransform) - захват с 4 каналов с отображением на экране и одновременным кодированием и сохранением на носитель - он не "захлёбывается" даже на одноядерном solo
Да, речь о RPi3.
Чтоб не быть голословным - входной кадр 1280 * 1024 (по площади равен обсуждаемому 1440 * 960), обработка - коррекция искажений широкоугольной линзы по всему кадру. Дальше еще один этап обработки по запросу (не realtime) + отображение по HDMI либо трансляция в сеть. На выходе приемлемые под задачу 10fps. Давайте лично вам пришлю код, сами попробуете если такое недоверие. Кстати ничего не оптимизировано под многоядерность, можно сделать быстрее через OpenMP. И захват по USB, по опыту если это делать через CSI то было бы быстрее. Но CSI часть в RPi проприетарна и закрыта. Есть какие-то потуги с реверс-инжинирингом этой части но сейчас речь не об этом.
Имеете полное право так думать.
Но сейчас на iMX6Dual в своем приложении я выжимаю 3-4fps на счетверенном посредством compositor'а и пропущенном через v4l2loopback потоке. Причем заметно тормозит именно этот входной пайплайн в части v4l2loopback и перед ним (по top'у только он ест 30-40% CPU), т.к. голая обработка на статичном кадре без захвата дает требуемые по ТЗ минимальные 10fps.
Зато весь код который понадобилось написать - 30 строк с использованием OpenCV, без vendor-specific решений, в результате он работает без изменений и на обычном ПК.
Я прекрасно понимаю что по сути предлагал "переложить с больной головы на здоровую" - решить проблемы производительности не написанием GST плагина самому, а модификацией драйвера видеозахвата чужими руками. Поэтому эта идея еще несколько постов назад мной же была признана нездоровой.
Но мысль предыдущего поста была в том, что если вдруг не мне одному нужно делать какую-то обработку на борту счетверенного потока и нет квалификации по написанию gst plugin - драйвер со встроенной поддержкой этой функции и работающий без загрузки CPU - имел бы смысл.
Данный скипт как пример harware-based обработки очень показателен и отлично работает. Но мне нужна обработка на CPU, которую загнать в какой-то hardware блок iMX6 очень затруднительно.
Впихнуть imxipuvideotransform (как и imxipuvideotransform и imxpxpvideotransform) вместо videoconvert пробовал неоднократно, не вышло как ни крутил. А videoconvert это 100% CPU-based решение, разве нет?
Дополнительно как я понял если сделать всю обработку на GPU - придется лицензировать у Freescale их реализацию OpenGL, так?
так у вас только одна корррекция нагрузила CPU на 100 % - больше половины кадров дропается, теперь попробуйте туда деинтерлейсинг хотя бы добавить
тут и без кода всё понятно и предсказуемо - я вам написал в предыдущем ответе
тут просто нет слов, при этом вы мне предлгаете переписать драйвер на выходе которого получится такая дичь что ее потом никакими готовыми стандартными средствами тем более аппаратно на imx6 не обработать
ага - очереди выстроятся из желающих
какие форматы приемлемы на входе вашего приложения ?
если вы собираетесь продавать устройства с их проприетарными библиотеками - да, нужны какие-то отчисления, для собственных разработок которые вы сами используете - нет. Если уж на то пошло - для GPU есть драйвер в ванильном ядре и gallium драйвер в майнстримной mesa (etnaviv) на основе reverse engineering, но я не знаю насколько они сейчас работоспособны и полноценны.
Александр, давайте поумерим тон и пыл. Идея переписать драйвер из моих уст изжила себя уже несколько постов назад, давайте ее окончательно похороним на этом сообщении и возвращаться к ней уже не будем.
Защищать здесь адекватность решаемых мной задач embedded machine vision на базе CPU-only решений на ARM чипах тоже не буду, нет ни времени ни желания. В приватной беседе - пожалуйста, есть о чем поговорить, тем более с человеком вашей квалификации.
RGB888, возможно с какими-то дополнительными ограничениями которые мне пока не совсем очевидны.
17.01.2018 11:28 
17.01.2018 11:42
