Подсистема HAL

На этой странице описана подсистема HAL, в том числе запросы, подсистема камеры, последовательность запуска и работы, уровни оборудования и взаимодействия.

Запросы

Фреймворк приложения отправляет запросы на получение результатов съемки в подсистему камеры. Каждый запрос соответствует одному набору результатов. Запрос содержит всю информацию о конфигурации, необходимую для получения и обработки этих результатов. К ним относятся разрешение и формат пикселей, ручное управление датчиком, объективом и вспышкой, режимы работы 3A, управление обработкой RAW в YUV и создание статистики. Это позволяет лучше контролировать результаты и их обработку. Одновременно может выполняться несколько запросов, и отправка запросов не блокирует другие процессы. Запросы всегда обрабатываются в порядке их поступления.

Модель запроса камеры

Рисунок 1. Модель камеры.

HAL и подсистема камеры

Подсистема камеры включает реализации компонентов в конвейере камеры, таких как алгоритм 3A и элементы управления обработкой. HAL камеры предоставляет интерфейсы для реализации ваших версий этих компонентов. Чтобы обеспечить совместимость между платформами разных производителей устройств и поставщиков процессоров обработки изображений (ISP или датчиков камеры), модель конвейера камеры является виртуальной и не соответствует напрямую ни одному реальному ISP. Однако он достаточно похож на реальные конвейеры обработки, чтобы вы могли эффективно сопоставить его со своим оборудованием. Кроме того, он достаточно абстрактен, чтобы допускать несколько различных алгоритмов и порядков операций без ущерба для качества, эффективности или совместимости между устройствами.

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

Уровень абстракции камеры

Рисунок 2. Конвейер камеры.

Обратите внимание, что некоторые блоки обработки изображений, показанные на диаграмме выше, не определены в начальной версии. Конвейер камеры делает следующие предположения:

  • Выходные данные RAW Bayer не обрабатываются внутри ISP.
  • Статистика создается на основе необработанных данных датчиков.
  • Различные блоки обработки, которые преобразуют необработанные данные датчика в формат YUV, расположены в произвольном порядке.
  • Хотя показано несколько единиц масштабирования и обрезки, все единицы масштабирования используют одни и те же элементы управления выходной областью (цифровое масштабирование). Однако у каждого устройства может быть разное выходное разрешение и формат пикселей.

Сводка по использованию API

Ниже приведено краткое описание шагов по использованию Android Camera API. Подробное описание этих шагов, включая вызовы API, приведено в разделе "Запуск и ожидаемая последовательность операций".

  1. Прослушивание и перечисление камер.
  2. Откройте устройство и подключите слушателей.
  3. Настройте выходные данные для целевого варианта использования (например, для съемки фотографий или записи видео).
  4. Создайте запросы для целевого варианта использования.
  5. Захват/повторение запросов и пакетов.
  6. Получать метаданные результатов и данные изображений.
  7. Если вы хотите использовать другой вариант, вернитесь к шагу 3.

Сводка операций HAL

  • Асинхронные запросы на захват поступают из фреймворка.
  • Устройство HAL должно обрабатывать запросы по порядку. Для каждого запроса создаются метаданные результата и один или несколько буферов выходных изображений.
  • Запросы и результаты обрабатываются в порядке поступления, а потоки, на которые ссылаются последующие запросы, – в порядке их создания.
  • Временные метки должны быть одинаковыми для всех выходных данных из определенного запроса, чтобы при необходимости их можно было сопоставить.
  • Все настройки и состояния захвата (кроме процедур 3A) инкапсулируются в запросах и результатах.

Обзор Camera HAL

Рисунок 3. Обзор HAL камеры.

Запуск и ожидаемая последовательность операций

В этом разделе подробно описаны шаги, которые необходимо выполнить при использовании API камеры. Определения интерфейсов HIDL можно найти в каталоге platform/hardware/interfaces/camera/.

Перечисление, открытие камер и создание активного сеанса

  1. После инициализации фреймворк начинает прослушивать все доступные поставщики камер, которые реализуют интерфейс ICameraProvider. Если такой поставщик или поставщики присутствуют, фреймворк пытается установить подключение.
  2. Платформа перечисляет устройства камеры с помощью ICameraProvider::getCameraIdList.
  3. Платформа создает новый объект ICameraDevice, вызывая соответствующий метод ICameraProvider::getCameraDeviceInterface_VX_X.
  4. Фреймворк вызывает ICameraDevice::open, чтобы создать новый активный сеанс захвата ICameraDeviceSession.

Используйте активный сеанс камеры

  1. Фреймворк вызывает ICameraDeviceSession::configureStreams со списком входных и выходных потоков для устройства HAL.
  2. Фреймворк запрашивает настройки по умолчанию для некоторых вариантов использования с помощью вызовов ICameraDeviceSession::constructDefaultRequestSettings. Это может произойти в любой момент после того, как ICameraDevice::open создаст ICameraDeviceSession.
  3. Фреймворк создает и отправляет в HAL первый запрос на съемку с настройками, основанными на одном из наборов настроек по умолчанию, и по крайней мере одним выходным потоком, который был зарегистрирован фреймворком ранее. Они отправляются на уровень HAL с помощью ICameraDeviceSession::processCaptureRequest. HAL должен блокировать возврат этого вызова, пока не будет готов к отправке следующего запроса.
  4. Фреймворк продолжает отправлять запросы и вызовы ICameraDeviceSession::constructDefaultRequestSettings, чтобы при необходимости получать буферы настроек по умолчанию для других случаев использования.
  5. Когда начинается захват запроса (сенсор начинает экспонирование для захвата), HAL вызывает ICameraDeviceCallback::notify с сообщением SHUTTER, включая номер кадра и временную метку начала экспонирования. Этот обратный вызов не обязательно должен произойти до первого вызова processCaptureResult для запроса, но результаты захвата не будут переданы в приложение, пока не будет вызван метод notify для этого захвата.
  6. После некоторой задержки HAL начинает возвращать завершенные снимки в фреймворк с помощью ICameraDeviceCallback::processCaptureResult. Они возвращаются в том же порядке, в котором были отправлены запросы. Одновременно может выполняться несколько запросов в зависимости от глубины конвейера устройства HAL камеры.

Через некоторое время произойдет одно из следующих событий:

  • Фреймворк перестает отправлять новые запросы, ожидает завершения существующих захватов (все буферы заполнены, все результаты возвращены), а затем снова вызывает ICameraDeviceSession::configureStreams. Это сбрасывает аппаратное обеспечение камеры и конвейер для нового набора входных/выходных потоков. Некоторые потоки можно использовать повторно из предыдущей конфигурации. Затем фреймворк переходит к первому запросу на захват в HAL, если остался хотя бы один зарегистрированный выходной поток. В противном случае сначала нужно указать ICameraDeviceSession::configureStreams.
  • Чтобы завершить сеанс работы с камерой, фреймворк может вызвать метод ICameraDeviceSession::close. Этот метод можно вызывать в любое время, когда неактивны другие вызовы из фреймворка, хотя вызов может блокироваться до тех пор, пока не будут завершены все выполняемые захваты (возвращены все результаты, заполнены все буферы). После возврата вызова close HAL больше не может вызывать ICameraDeviceCallback. После начала вызова close фреймворк не может вызывать другие функции HAL-устройства.
  • В случае ошибки или другого асинхронного события HAL должен вызвать ICameraDeviceCallback::notify с соответствующим сообщением об ошибке или событии. После возврата из уведомления о критической ошибке на уровне устройства HAL должен действовать так, как будто был вызван метод close. Однако HAL должен отменить или завершить все незавершенные захваты до вызова notify, чтобы после вызова notify с фатальной ошибкой фреймворк не получал дальнейшие обратные вызовы от устройства. Методы, отличные от close, должны возвращать -ENODEV или NULL после того, как метод notify возвращает сообщение о критической ошибке.

Как управлять камерой

Рисунок 4. Рабочий процесс с камерой.

Уровни оборудования

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

Взаимодействие между запросом на захват приложения, управлением 3A и конвейером обработки

В зависимости от настроек в блоке управления 3A конвейер камеры игнорирует некоторые параметры в запросе на съемку от приложения и использует значения, предоставленные процедурами управления 3A. Например, если включена автоматическая экспозиция, время экспозиции, длительность кадра и параметры чувствительности датчика контролируются алгоритмом 3A платформы, а все значения, заданные в приложении, игнорируются. Значения, выбранные для кадра процедурами 3A, должны быть указаны в выходных метаданных. В таблице ниже описаны различные режимы блока управления 3A и свойства, которыми управляют эти режимы. Определения этих свойств можно найти в файле platform/system/media/camera/docs/docs.html.

Параметр Штат Контролируемые свойства
android.control.aeMode OFF Нет.
ON android.sensor.exposureTime, android.sensor.frameDuration, android.sensor.sensitivity, android.lens.aperture (если поддерживается) и android.lens.filterDensity (если поддерживается).
ON_AUTO_FLASH Все, что есть в ON, а также android.flash.firingPower, android.flash.firingTime и android.flash.mode.
ON_ALWAYS_FLASH Как в ON_AUTO_FLASH.
ON_AUTO_FLASH_RED_EYE Как в ON_AUTO_FLASH.
android.control.awbMode OFF Нет.
WHITE_BALANCE_* android.colorCorrection.transform – корректировки для определенной платформы, если android.colorCorrection.mode имеет значение FAST или HIGH_QUALITY.
android.control.afMode OFF Нет
FOCUS_MODE_* android.lens.focusDistance
android.control.videoStabilization OFF Нет.
ON Можно настроить android.scaler.cropRegion, чтобы реализовать стабилизацию видео.
android.control.mode OFF Автоэкспозиция, автоматический баланс белого и автофокус отключены.
AUTO Используются отдельные настройки автоэкспозиции, автоматического баланса белого и автофокуса.
SCENE_MODE_* Может переопределять все перечисленные выше параметры. Отдельные элементы управления 3A отключены.

Все элементы управления в блоке обработки изображений на рисунке 2 работают по схожему принципу. У каждого блока три режима:

  • OFF: этот блок обработки отключен. Блоки дебайеризации, коррекции цвета и настройки тоновой кривой отключить нельзя.
  • FAST: в этом режиме блок обработки может не замедлять частоту кадров по сравнению с режимом OFF, но должен обеспечивать наилучшее качество выходных данных с учетом этого ограничения. Обычно это используется для режимов предварительного просмотра или видеозаписи, а также для серийной съемки неподвижных изображений. На некоторых устройствах этот режим может быть эквивалентен режиму OFF (обработка невозможна без снижения частоты кадров), а на других – режиму HIGH_QUALITY (наилучшее качество не приводит к снижению частоты кадров).
  • HIGH_QUALITY: в этом режиме блок обработки должен обеспечивать наилучшее качество, при необходимости снижая частоту кадров. Обычно этот режим используется для съемки высококачественных фотографий. В некоторых блоках можно выбрать ручное управление вместо FAST или HIGH_QUALITY. Например, блок коррекции цвета поддерживает матрицу преобразования цвета, а блок коррекции тональной кривой – произвольную глобальную кривую сопоставления тонов.

Максимальная частота кадров, поддерживаемая подсистемой камеры, зависит от многих факторов:

  • Запрошенные разрешения выходных видеопотоков.
  • Доступность режимов объединения/пропуска пикселей на датчике изображения
  • Пропускная способность интерфейса камеры
  • Пропускная способность различных блоков обработки интернет-провайдера.

Эти факторы могут сильно различаться у разных ISP и датчиков, поэтому интерфейс HAL камеры пытается абстрагировать ограничения пропускной способности в максимально простую модель. Представленная модель имеет следующие характеристики:

  • Матрица всегда настроена на вывод наименьшего возможного разрешения с учетом размеров выходного потока, запрошенных приложением. Минимальное разрешение должно быть не меньше, чем наибольший запрошенный размер выходного потока.
  • В любом запросе можно использовать все настроенные выходные потоки или их часть, поэтому датчик и ISP должны быть настроены так, чтобы поддерживать масштабирование одного захвата на все потоки одновременно.
  • Потоки JPEG действуют как обработанные потоки YUV для запросов, в которые они не включены. В запросах, в которых на них есть прямые ссылки, они действуют как потоки JPEG.
  • Процессор JPEG может работать одновременно с остальной частью конвейера камеры, но не может обрабатывать более одного захвата за раз.