LINUX.ORG.RU

Ламерские вопросы по V4L2.


0

1

Очень интересно узнать, но к сожалению нет времени читать специальные доки на эту тему, т.к. не срочно. Но любопытно. Попробую задать ламерские вопросы в надежде на пробегание мимо специалиста, который будет не прочь объяснить что-то на пальцах.

1) Как в продвинутых приложениях идёт работа с устройствами /dev/video - постоянными вызовами read()? Как быстрее всего, короче говоря, получить данные из /dev/video0 в память приложения? Какими вызовами, способами и т.п.

2) Какие жалобы есть у специалистов на архитектуру V4L2? Допустим, невозможность интеграции туда видео-фильтров из-за отсутствия колл-беков и т.п. (это тупой пример с потолка).

3) Насколько я понимаю, драйвера видео-устройств (веб-камер) должны выдавать через /dev/video* один из нескольких стандартных форматов картинки (JPEG, YUYV, ...) . Существует ли у разработчиков драйверов свобода выхода за рамки списка форматов картинки, определённого стандартом V4L2? Т.е. всегда ли /dev/video* обязан выдавать один из заранее определённых форматов? А если камера какая-то специальная с 14 битами на канал вместо 8?

4) Ну если кто-то хочет сказать «не парься, юзай нужные библиотеки», то отвечу, что требуются шашечки, а вовсе не ехать на данный момент. Ну посоветуйте конкретную либу, если кто хочет. Но это дело десятое пока что. Сейчас хочется понять, как кругло колесо у велосипеда.

Как в продвинутых приложениях идёт работа с устройствами /dev/video - постоянными вызовами read()?

см. тут, один из оптимальных методов «Streaming I/O»

Существует ли у разработчиков драйверов свобода выхода за рамки списка форматов картинки, определённого стандартом V4L2?

V4L2 даёт ровно в таком формате, в котором отдаёт (может отдавать) железо, сами спецификации жёстких ограничений не накладывают.

А если камера какая-то специальная с 14 битами на канал вместо 8?

Набор допустимых форматов расширают в соответствии с поддерживаемыми устройствами. Будут желающие писать дрова для такой экзотики - будет и формат в списках.

Ещё раз напомню, V4L ничего практически с картинкой не делает, его основная задача взять кадр с железа и отдать приложению и наоборот, обработкой или интерпретацией (преобразование в RGB...) кадра в цвета занимается приложение. Список поддерживаемых форматов нужен фактически только для обозначения. В некоторых случаях дравйвер/api может делать простую конвертацию.

Ну посоветуйте конкретную либу, если кто хочет.

Специальной либы для работы с разными форматами скорее всего нет, но много кода можно найти в mplayer и других проигрывателях.

anonymous
()

> 1) Как в продвинутых приложениях идёт работа с устройствами /dev/video - постоянными вызовами read()? Как быстрее всего, короче говоря, получить данные из /dev/video0 в память приложения? Какими вызовами, способами и т.п.

выделили буфер, дали его v4l, запустили конвертацию (read out), дождались окончания конвертации, всё - данные у нас. Пропихивается это всё через ioctl

anonymous
()

5) Если нужно сделать модуль ядра, создающий /dev/video7 и рисующий там картинку, являющуюся результатом обработки картинки из /dev/video0, то наверное лучше сделать умную обработку в юзерспейсе, а в этот модуль скармливать картинку, которую он просто повторяет. Но если бы я хотел сделать обработку внутри этого модуля, мог бы я в нём открыть /dev/video0 и читать данные оттуда?

kiverattes ★☆
() автор топика

>Ламерские вопросы

Действительно ламерские, как и ответы :)
1 Обычный mmap буферов
2 Никакой проблемы нет
3 ты как и большинство напрочь забыли что v4l кроме input поддерживает и output, к тому же как ты себе представляешь поддержку форматов выходящих за стандарты ? каким образом по в юзерспейс сможет понять что может этот модуль ?
4 либу для чего ?

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

>1) Как в продвинутых приложениях идёт работа с устройствами /dev/video - постоянными вызовами read()? Как быстрее всего, короче говоря, получить данные из /dev/video0 в память приложения? Какими вызовами, способами и т.п.

Как уже было сказано выше - стандартно применяемый способ через mmap.
read() же может быть просто не реализован (например как в uvcvideo)

В любом случае нужно смотреть на v4l2_capability

Специальной либы для работы с разными форматами скорее всего нет


libv4l ?

http://people.atrpms.net/~hdegoede/

5) Если нужно сделать модуль ядра, создающий /dev/video7 и рисующий там картинку, являющуюся результатом обработки картинки из /dev/video0, то наверное лучше сделать умную обработку в юзерспейсе, а в этот модуль скармливать картинку, которую он просто повторяет. Но если бы я хотел сделать обработку внутри этого модуля, мог бы я в нём открыть /dev/video0 и читать данные оттуда?


Не надо ничего загонять в кернелспейс :) наоборот все конвертации в V4L2 выпилили из ядра (в V4L1 они происходили в ядре) используй врапперы по ссылке выше

sS ★★★★★
()

Советую на сайте v4l2 почитать примеры. Их там достаточно. Я на основе примеров свои приложения и делал. Например, это.

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