LINUX.ORG.RU

работа с камерами v4l2 (yuyv, mmx)


0

0

Мне надо обрабатывать картинку с 4х камер. Каждый кадр обрабатывается по кой какому алгоритму и в результате этого принимается решение, выдавать или нет управляющее воздействие.
Работу с камерой делал в рукопашную по какому-то примеру. Там всё как обычно, несколько буферов (в конкретном случае 3) и камера их по кольцу заполняет, т.е. пака предыдущий кадр обрабатываешь, камера следующий грабит. На одной камере всё работало сносно, а когда стало 4 стало, то стали заметны задержки. Ну по сути когда доходит дело до обработки кадра, то он устарел на время (3*время обработки кадра). Я пробовал всё в одно место вставить, заказ кадра, ожидание, и обработка. .. Но почему-то время ожидания захвата кадра сильно возросло (тоесть на select стал дольше обычного висеть). Как это заставить быстро работать ума не приложу.
Это одна печаль. Есть еще.
Раньше алгоритм работал с черно-белой картинкой с камеры кадры идут в формате V4L2_PIX_FMT_YUYV, то есть, преобразований вообще никаких нет. Когда понадобился RGB то дела стали хуже. Этот проход по преобразованию стал занимать некоторое время. Вроде это можно оптимизировать с помощью MMX, сам изобретать буду долго, потому прошу ,может кто знает где можно подсмотреть.
Какие будут соображения ?

anonymous

> Но почему-то время ожидания захвата кадра сильно возросло (тоесть на select стал дольше обычного висеть). Как это заставить быстро работать ума не приложу.

Для начала, выбросить чтение. v4l2 умеет писать сразу в память и говорить, какой очередной буфер заполнен.

> Раньше алгоритм работал с черно-белой картинкой с камеры кадры идут в формате V4L2_PIX_FMT_YUYV, то есть, преобразований вообще никаких нет. Когда понадобился RGB то дела стали хуже.

Если видео захватывается с pci'ных тюнеров, то 4 больших картинки в rgb по шине не пролезут. Даже 3 штуки vga'шного разрешения не факт, что на всех материнках - будут dma-пересылки выбиваться, на экране горизонтальные полосы появятся.

А чем вариации yuv не устраивают? Тем более, что, допустим, старые bt'шные чипы нормального rgb не умеют - конвертится из yuv с меньшей цветностью, чем rgb вмещает.

> Вроде это можно оптимизировать с помощью MMX, сам изобретать буду долго, потому прошу ,может кто знает где можно подсмотреть.

Это - это что? :) Что за алгоритм? Детектор движения какой-нибудь? :)

mv ★★★★★
()

>> Вроде это можно оптимизировать с помощью MMX, сам изобретать буду долго, потому прошу ,может кто знает где можно подсмотреть.

http://liboil.freedesktop.org/

Deleted
()

Получение картинки сделано через mmap. Но ведь ждать окончания захвата всё равно нужно. И делается с помощью select. А патом уже узнаем в каком буфере кадр и его обрабатываем.

Камеры обычные WEB подключенные по усб. Про это дело я кстати совсем забыл :) НО. Та же самая программа с теми же самыми камерами работает в пределах допуска если брать картинку черно-белую (то есть размер пересылаемых данных с камеры такойже , только в rgb не переконвертируем).

Оптимизировать я хотел yuv2rgb. Похоже Liboil именно то что мне нужно. Спасибо mironov_ivan.

anonymous
()
Ответ на: комментарий от anonymous

> НО. Та же самая программа с теми же самыми камерами работает в пределах допуска если брать картинку черно-белую (то есть размер пересылаемых данных с камеры такойже , только в rgb не переконвертируем).

В ч/б режиме с камеры тоже идёт физически в rgb?

> Оптимизировать я хотел yuv2rgb. Похоже Liboil именно то что мне нужно. Спасибо mironov_ivan.

libavformat (или libavutil?) из ffmpeg посмотри, там такие преобразования жутко заоптимизированы.

mv ★★★★★
()
Ответ на: комментарий от mv

> В ч/б режиме с камеры тоже идёт физически в rgb?
с камеры всё всегда идет в yuv. из него ч/б чтобы получить нада просто брать y0 y1, а чтобы в rgb нада много калькуляций...

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.